Задержка чтения типа карты

Прежде всего спасибо всем, кто отвечает на все наши вопросы.

Я застрял в одном из пунктов, я надеюсь, что люди могут избавить меня от моей проблемы.

У меня есть кластер Apache 2.1 с 6 узлами, и я создал таблицу с 3 столбцами. 1-й столбец - текстовый, а другие 2 - тип карты. Когда я вставляю данные в таблицу и читаю данные... для выборки 1 строки требуется около 20 миллисекунд, но если я создаю таблицу с текстовым типом для всех трех столбцов, то это занимает всего 5 мс. Пожалуйста, предложите мне, если я пропал ... почему это занимает время, если это тип карты ?? Я смущен, чтобы начать задержку чтения типа карты.

Ниже приведены cfstats и запрос:

Таблица:

PRODUCT_TYPE
SSTable count: 1
SSTables in each level: [1, 0, 0, 0, 0, 0, 0, 0, 0]
Space used (live): 81458
Space used (total): 81458
Space used by snapshots (total): 0
Off heap memory used (total): 87
SSTable Compression Ratio: 0.15090414689301526
Number of keys (estimate): 6
Memtable cell count: 0
Memtable data size: 0
Memtable off heap memory used: 0
Memtable switch count: 0
Local read count: 5
Local read latency: 22.494 ms
Local write count: 0
Local write latency: NaN ms
Pending flushes: 0
Bloom filter false positives: 0
Bloom filter false ratio: 0.00000
Bloom filter space used: 16
Bloom filter off heap memory used: 8
Index summary off heap memory used: 15
Compression metadata off heap memory used: 64
Compacted partition minimum bytes: 73458
Compacted partition maximum bytes: 105778
Compacted partition mean bytes: 91087
Average live cells per slice (last five minutes): 1.0
Maximum live cells per slice (last five minutes): 1.0
Average tombstones per slice (last five minutes): 0.0
Maximum tombstones per slice (last five minutes): 0.0

CREATE TABLE TEST.PRODUCT_TYPE (
type text PRIMARY KEY,
col1 map<int, boolean>,
timestamp_map map<int, timestamp>
) WITH bloom_filter_fp_chance = 0.1
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class':                       'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 'max_threshold': '32'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
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 = '99.0PERCENTILE';


 activity                                                                                                              | timestamp                  | source        | source_elapsed
 -----------------------------------------------------------------------------------------------------------------------+----------------------------+---------------+----------------
                                                                                                    Execute CQL3 query | 2015-06-03 21:57:36.841000 | 10.65.133.202 |              0
                                            Parsing SELECT * from location_eligibility_by_type5; [SharedPool-Worker-1] | 2015-06-03 21:57:36.842000 | 10.65.133.202 |             54
                                                                             Preparing statement [SharedPool-Worker-1] | 2015-06-03 21:57:36.842000 | 10.65.133.202 |             86
                                                                       Computing ranges to query [SharedPool-Worker-1] | 2015-06-03 21:57:36.842000 | 10.65.133.202 |            165
  Submitting range requests on 1537 ranges with a concurrency of 1 (0.0 rows per range expected) [SharedPool-Worker-1] | 2015-06-03 21:57:36.842000 | 10.65.133.202 |            410
                                                             Enqueuing request to /10.65.137.191 [SharedPool-Worker-1] | 2015-06-03 21:57:36.849000 | 10.65.133.202 |           7448
                                                                      Message received from /10.65.133.202 [Thread-15] | 2015-06-03 21:57:36.849000 | 10.65.137.191 |             15
                                      Submitted 1 concurrent range requests covering 1537 ranges [SharedPool-Worker-1] | 2015-06-03 21:57:36.849000 | 10.65.133.202 |           7488
                                                              Sending message to /10.65.137.191 [WRITE-/10.65.137.191] | 2015-06-03 21:57:36.849000 | 10.65.133.202 |           7515
 Executing seq scan across 0 sstables for [min(-9223372036854775808), min(-9223372036854775808)] [SharedPool-Worker-1] | 2015-06-03 21:57:36.850000 | 10.65.137.191 |            105
                                                              Read 1 live and 0 tombstoned cells [SharedPool-Worker-1] | 2015-06-03 21:57:36.866000 | 10.65.137.191 |          16851
                                                              Read 1 live and 0 tombstoned cells [SharedPool-Worker-1] | 2015-06-03 21:57:36.882000 | 10.65.137.191 |          33542
                                                              Read 1 live and 0 tombstoned cells [SharedPool-Worker-1] | 2015-06-03 21:57:36.899000 | 10.65.137.191 |          50206
                                                              Read 1 live and 0 tombstoned cells [SharedPool-Worker-1] | 2015-06-03 21:57:36.915000 | 10.65.137.191 |          66556
                                                              Read 1 live and 0 tombstoned cells [SharedPool-Worker-1] | 2015-06-03 21:57:36.932000 | 10.65.137.191 |          82814
                                                                    Scanned 5 rows and matched 5 [SharedPool-Worker-1] | 2015-06-03 21:57:36.932000 | 10.65.137.191 |          82839
                                                            Enqueuing response to /10.65.133.202 [SharedPool-Worker-1] | 2015-06-03 21:57:36.933000 | 10.65.137.191 |          82878
                                                              Sending message to /10.65.133.202 [WRITE-/10.65.133.202] | 2015-06-03 21:57:36.933000 | 10.65.137.191 |          83054
                                                                     Message received from /10.65.137.191 [Thread-151] | 2015-06-03 21:57:36.944000 | 10.65.133.202 |         102134
                                                         Processing response from /10.65.137.191 [SharedPool-Worker-2] | 2015-06-03 21:57:36.944000 | 10.65.133.202 |         102191
                                                                                                      Request complete | 2015-06-03 21:57:36.948916 | 10.65.133.202 |         107916

Заранее спасибо за вашу поддержку и ответы.

Спасибо, Джон

cassandra cassandra-2.0 cassandra-2.1

john cena 03.06.2015 источник

Ответы (1)

arrow_upward
3
arrow_downward

Типы коллекций в Cassandra под капотом реализованы в виде больших двоичных объектов, здесь нет настоящей магии.

Чтобы измерить разницу, вы можете включить трассировку в C* и увидеть разницу самостоятельно:

create table no_collections(id int, value text, primary key (id));
create table with_collections(id int, value set<text>, primary key (id));

cqlsh:stackoverflow> select * from no_collections ;

 id | value
----+-------------
  1 | foo,bar,baz
  2 | xxx,yyy,zzz
  3 | aaa,bbb,ccc

(3 rows)
cqlsh:stackoverflow> select * from with_collections ;

 id | value
----+-----------------------
  1 | {'bar', 'baz', 'foo'}
  2 | {'xxx', 'yyy', 'zzz'}
  3 | {'aaa', 'bbb', 'ccc'}

(3 rows)

Теперь давайте включим трассировку, чтобы увидеть, что происходит:

cqlsh:stackoverflow> TRACING ON ;
Now Tracing is enabled
cqlsh:stackoverflow> select * from with_collections where id=3;

 id | value
----+-----------------------
  3 | {'aaa', 'bbb', 'ccc'}

(1 rows)

Tracing session: 7c3d4ed0-09c8-11e5-b4cd-2988e70b20cb

activity                                                                                            | timestamp                  | source    | source_elapsed
-------------------------------------------------------------------------------------------------+----------------------------+-----------+----------------
                                                                              Execute CQL3 query | 2015-06-03 11:13:58.717000 | 127.0.0.1 |              0
                        Parsing select * from with_collections where id=3; [SharedPool-Worker-1] | 2015-06-03 11:13:58.718000 | 127.0.0.1 |             72
                                                       Preparing statement [SharedPool-Worker-1] | 2015-06-03 11:13:58.718000 | 127.0.0.1 |            218
                      Executing single-partition query on with_collections [SharedPool-Worker-3] | 2015-06-03 11:13:58.718000 | 127.0.0.1 |            547
                                              Acquiring sstable references [SharedPool-Worker-3] | 2015-06-03 11:13:58.718000 | 127.0.0.1 |            556
                                               Merging memtable tombstones [SharedPool-Worker-3] | 2015-06-03 11:13:58.719000 | 127.0.0.1 |            574
 Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-3] | 2015-06-03 11:13:58.719000 | 127.0.0.1 |            636
                                Merging data from memtables and 0 sstables [SharedPool-Worker-3] | 2015-06-03 11:13:58.719000 | 127.0.0.1 |            644
                                        Read 1 live and 0 tombstoned cells [SharedPool-Worker-3] | 2015-06-03 11:13:58.719000 | 127.0.0.1 |            673
                                                                                Request complete | 2015-06-03 11:13:58.717847 | 127.0.0.1 |            847

Как видите, для разбора и выполнения запроса, использующего коллекцию, потребовалось всего ~800 нс. Без коллекций ситуация выглядит примерно так же:

cqlsh:stackoverflow> select * from no_collections where id=3;

 id | value
----+-------------
  3 | aaa,bbb,ccc

(1 rows)

Tracing session: 7e9ac6d0-09c8-11e5-b4cd-2988e70b20cb

 activity                                                                                        | timestamp                  | source    | source_elapsed
-------------------------------------------------------------------------------------------------+----------------------------+-----------+----------------
                                                                              Execute CQL3 query | 2015-06-03 11:14:02.685000 | 127.0.0.1 |              0
                          Parsing select * from no_collections where id=3; [SharedPool-Worker-1] | 2015-06-03 11:14:02.686000 | 127.0.0.1 |             77
                                                       Preparing statement [SharedPool-Worker-1] | 2015-06-03 11:14:02.686000 | 127.0.0.1 |            209
                        Executing single-partition query on no_collections [SharedPool-Worker-3] | 2015-06-03 11:14:02.686000 | 127.0.0.1 |            525
                                              Acquiring sstable references [SharedPool-Worker-3] | 2015-06-03 11:14:02.686000 | 127.0.0.1 |            534
                                               Merging memtable tombstones [SharedPool-Worker-3] | 2015-06-03 11:14:02.687000 | 127.0.0.1 |            553
 Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-3] | 2015-06-03 11:14:02.687000 | 127.0.0.1 |            598
                                Merging data from memtables and 0 sstables [SharedPool-Worker-3] | 2015-06-03 11:14:02.688000 | 127.0.0.1 |            606
                                        Read 1 live and 0 tombstoned cells [SharedPool-Worker-3] | 2015-06-03 11:14:02.688000 | 127.0.0.1 |            630
                                                                                Request complete | 2015-06-03 11:14:02.685789 | 127.0.0.1 |            789

Так что особой разницы здесь я не вижу.

Время, показанное трассировкой cqlsh, является приблизительным и не совсем статистически точным. Чтобы изучить разницу, вам нужно провести как минимум несколько десятков экспериментов, а затем сравнить их результаты. Но результаты могут зависеть от разных вещей:

сетевая задержка между узлами. Это может быть причиной всех проблем с задержкой в общей инфраструктуре, такой как AWS.
нагрузка на кластер. Если ваш кластер не простаивает, он может выполнять некоторую фоновую работу, которая может мешать вашим измерениям.
фоновые рабочие места. Если у вас есть набор данных с частыми обновлениями/удалениями, C* может выполнять некоторые задачи уплотнения под капотом, а также может мешать другим запросам.
тяжелые обновления/удаления, мало памяти. Если у вас есть (или была в прошлом) большая рабочая нагрузка по обновлению/удалению, ваши данные могут быть распределены между несколькими небольшими SSTables, которые еще не были сжаты. C* должен прочитать большинство из них для вашей строки, что приведет к высокой задержке запросов.

Поэтому я предлагаю вам запускать ваши запросы с включенной трассировкой, чтобы увидеть проблему, но я уверен, что она вообще не связана с коллекциями.

shutty 03.06.2015

comment

Спасибо за ответ. Я обновил несколько отчетов cfstats, не могли бы вы увидеть и сказать мне, происходит ли что-то не так, из-за чего задержка чтения составляет около 22 мс. Спасибо. - john cena; 03.06.2015

comment

Ничего подозрительного в ваших cfstats не вижу. И я снова предлагаю вам запустить ваши запросы с включенной трассировкой, чтобы увидеть, что происходит внутри. - shutty; 04.06.2015

comment

я обновил статистику запросов после отслеживания. не могли бы вы сказать мне, если видите что-то не так? большое спасибо. - john cena; 04.06.2015

Задержка чтения типа карты

Ответы (1)

Похожие вопросы