Кассандра: поиск ключей разделов

В настоящее время мы тестируем Cassandra со следующей схемой таблицы:

CREATE TABLE coreglead_v2.stats_by_site_user (
    d_tally text, -- ex.: '2016-01', '2016-02', etc..
    site_id int,
    d_date timestamp,
    site_user_id int,
    accepted counter,
    error counter,
    impressions_negative counter,
    impressions_positive counter,
    rejected counter,
    revenue counter,
    reversals_rejected counter,
    reversals_revenue counter,
    PRIMARY KEY (d_tally, site_id, d_date, site_user_id)
) WITH CLUSTERING ORDER BY (site_id ASC, d_date ASC, site_user_id ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

Для наших тестовых целей мы написали скрипт python, который рандомизирует данные по календарю 2016 года (всего 12 месяцев), мы ожидаем, что нашим ключом раздела будет столбец d_tally, в то же время мы ожидаем наше количество ключей должно быть 12 (от «2016-01» до «2016-12»).

Однако запуск nodetool cfstats показывает нам следующее:

Table: stats_by_site_user
        SSTable count: 4
        Space used (live): 131977793
        Space used (total): 131977793
        Space used by snapshots (total): 0
        Off heap memory used (total): 89116
        SSTable Compression Ratio: 0.18667406304929424
        Number of keys (estimate): 24
        Memtable cell count: 120353
        Memtable data size: 23228804
        Memtable off heap memory used: 0
        Memtable switch count: 10
        Local read count: 169
        Local read latency: 1.938 ms
        Local write count: 4912464
        Local write latency: 0.066 ms
        Pending flushes: 0
        Bloom filter false positives: 0
        Bloom filter false ratio: 0.00000
        Bloom filter space used: 128
        Bloom filter off heap memory used: 96
        Index summary off heap memory used: 76
        Compression metadata off heap memory used: 88944
        Compacted partition minimum bytes: 5839589
        Compacted partition maximum bytes: 43388628
        Compacted partition mean bytes: 16102786
        Average live cells per slice (last five minutes): 102.91627247589237
        Maximum live cells per slice (last five minutes): 103
        Average tombstones per slice (last five minutes): 1.0
        Maximum tombstones per slice (last five minutes): 1

Что нас смущает, так это часть «Количество ключей (оценка): 24». Глядя на нашу схему и предполагая, что наши тестовые данные (более 5 миллионов записей) состоят только из данных за 2016 год, откуда взялась оценка 24 ключей?

Вот пример наших данных:

d_tally | site_id | d_date                   | site_user_id | accepted | error | impressions_negative | impressions_positive | rejected | revenue | reversals_rejected | reversals_revenue
---------+---------+--------------------------+--------------+----------+-------+----------------------+----------------------+----------+---------+--------------------+-------------------
 2016-01 |       1 | 2016-01-01 00:00:00+0000 |       240054 |        1 |  null |                 null |                    1 |     null |     553 |               null |              null
 2016-01 |       1 | 2016-01-01 00:00:00+0000 |      1263968 |        1 |  null |                 null |                    1 |     null |    1093 |               null |              null
 2016-01 |       1 | 2016-01-01 00:00:00+0000 |      1267841 |        1 |  null |                 null |                    1 |     null |     861 |               null |              null
 2016-01 |       1 | 2016-01-01 00:00:00+0000 |      1728725 |        1 |  null |                 null |                    1 |     null |     425 |               null |              null

person joao    schedule 02.02.2016    source источник
comment
stackoverflow.com/questions/27963951 /   -  person undefined_variable    schedule 02.02.2016


Ответы (1)


Количество ключей является приблизительным (хотя должно быть очень близко). Он берет набросок данных из каждой стабильной таблицы и объединяет их вместе, чтобы оценить количество элементов (hyperloglog ).

К сожалению, эквивалент не существует в memtable, поэтому он добавляет мощность memtable к оценке sstable. Это означает, что данные как в memtables, так и в sstables учитываются дважды. Вот почему вы видите 24 вместо 12.

person Chris Lohfink    schedule 02.02.2016