Проблемы с записью cassandra. (5ms - 80ms)

Question

При сохранении данных в cassandra производительность 70% сохранения занимает около 4-8 мс. Но 30% запросов занимают около 80-90 мс. Поэтому, пытаясь понять, почему некоторые из запросов занимают много времени. Мое подозреваемое, возможно, это будет проходить через центр обработки данных для этих запросов, но не могу подтвердить это.

Также при использовании astyanax мы привязываемся к локальному хосту, что поможет подключиться к локальному координатору кассандры. Первичный ключ, используемый здесь, - это сгенерированный UUID.

Я был бы очень признателен, если кто-то может помочь в решении этой проблемы.

Write Consistency: CL_ONE 
Read Consistency: CL_LOCAL_QUORUM 

using Astyanax for java client: 1.56.37 
Cassandra version: 1.2.5 

Heres ключевого пространства информация:

CREATE KEYSPACE grd WITH replication = { 
    'class': 'NetworkTopologyStrategy', 
    'HYWRCA02': '2', 
    'CHRLNCUN': '2' 
}; 

CREATE TABLE route (
    routeid uuid PRIMARY KEY, 
    allowdynamicstickyness boolean, 
    businesskey uuid, 
    createdby text, 
    createdtimestamp timestamp, 
    datapartitionkeyselectorref text, 
    deletedby text, 
    deletedtimestamp timestamp, 
    envcontext text, 
    lockedbyuser text, 
    partner text, 
    routelocationlatitudeselector double, 
    routelocationlongitudeselector double, 
    routelocationmaxdistanceselector double, 
    routename text, 
    sequence int, 
    serviceidentifier text, 
    stalenessinmins int, 
    status text, 
    stickykeyselector text, 
    tags set<text>, 
    type text, 
    updatedby text, 
    updatedtimestamp timestamp, 
    versionmapnameref text, 
    versionselector text 
) WITH 
    bloom_filter_fp_chance=0.010000 AND 
    caching='ALL' AND 
    comment='' AND 
    dclocal_read_repair_chance=0.000000 AND 
    gc_grace_seconds=864000 AND 
    read_repair_chance=0.100000 AND 
    replicate_on_write='true' AND 
    populate_io_cache_on_flush='false' AND 
    compaction={'class': 'LeveledCompactionStrategy'} AND 
    compression={'sstable_compression': 'SnappyCompressor'}; 

спасибо.

Answer 1

Попробуйте войти в один из узлов кластера и выполнить cqlsh и выбрать пространство ключей с помощью USE:

[root@yournode ~]# cqlsh 
Connected to YourCluster at localhost:9160. 
[cqlsh 3.1.2 | Cassandra 1.2.6 | CQL spec 3.0.0 | Thrift protocol 19.36.0] 
Use HELP for help. 
cqlsh> use yourkeyspacehere ; 

После этого выполнить трассировку по команде на cqlsh:

cqlsh:yourkeyspacehere> tracing on 
Now tracing requests. 

И затем попробуйте запустить различные запросы в своей таблице с помощью разных ключей и проверить время и IP-адреса узлов, участвующих в запросе, чтобы проверить, существует ли соединение между данными. Примерный вывод может выглядеть так:

select * from your_table_name_is_here limit 1; 

Tracing session: 1ab19ff0-2fa3-11e3-a9aa-2face31554b7 

activity                      | timestamp | source   | source_elapsed 
-------------------------------------------------------------------------------------------------+--------------+----------------+---------------- 
                       execute_cql3_query | 22:52:12,528 | XXX.XX.XXX.XXX |    0 
              Parsing select * from your_table_name_is_here limit 1; | 22:52:12,529 | XXX.XX.XXX.XXX |   1108 
                       Peparing statement | 22:52:12,530 | XXX.XX.XXX.XXX |   1555 
                    Determining replicas to query | 22:52:12,530 | XXX.XX.XXX.XXX |   1643 
                  Message received from /XXX.XX.XXX.XXX | 22:52:12,534 | YYY.YY.YYY.YYY |    34 
                  Enqueuing request to /YYY.YY.YYY.YYY | 22:52:12,536 | XXX.XX.XXX.XXX |   7549 
                   Sending message to /YYY.YY.YYY.YYY | 22:52:12,536 | XXX.XX.XXX.XXX |   7812 
Executing seq scan across 9 sstables for [min(-9223372036854775808), max(-8721075978151533877)] | 22:52:12,538 | YYY.YY.YYY.YYY |   3609 
                    Scanned 1 rows and matched 1 | 22:52:12,550 | YYY.YY.YYY.YYY |   15977 
                  Enqueuing response to /XXX.XX.XXX.XXX | 22:52:12,550 | YYY.YY.YYY.YYY |   16035 
                   Sending message to /XXX.XX.XXX.XXX | 22:52:12,550 | YYY.YY.YYY.YYY |   16202 
                  Message received from /YYY.YY.YYY.YYY | 22:52:12,557 | XXX.XX.XXX.XXX |   28494 
                 Processing response from /YYY.YY.YYY.YYY | 22:52:12,557 | XXX.XX.XXX.XXX |   28647 
                       Request complete | 22:52:12,556 | XXX.XX.XXX.XXX |   28884 

Надеюсь, это поможет!