cassandra wide row column slice performance

Я тестирую cql/cassandra 1.2 и библиотеку python-cql на vm с 2GB RAM. У меня есть таблица с составным индексом (широкая строка). При выполнении запросов к одному узлу я получаю примерно 10-кратное снижение производительности, чем mysql. Запросы серийны без параллелизма, но меня интересует скорость одного запроса.cassandra wide row column slice performance

Самое главное, могу ли я что-нибудь сделать, чтобы оптимизировать запросы по широким строкам (в частности, этот запрос)?
Являются ли эти цифры отражающими производительность cassandra против mysql в ситуации с одним запросом?
Может ли мой ограниченный ram/vm сделать это большой разницей?
Будет ли многоузловая кассандра/разбитая mysql быть ближе, чем 10x?
Я делаю что-то ужасно неправильно? Код

Тест:

""" 
CREATE TABLE foo_bars (
    foo_id text, 
    bar_id bigint, 
    content text, 
    PRIMARY KEY (foo_id, bar_id) 
) 
WITH CLUSTERING ORDER BY (bar_id DESC); 
""" 

#content is up to 64k text and te number of bar columns in a foo row will be ever growing but will probably never reach over 2million 


t1 = time.time() 
for i in range(1, 1000): 
    sql_query = "SELECT * FROM foo_bars WHERE foo_id IN(%s) ORDER BY id DESC LIMIT 40" % random_foo_ids 
    result = db_cursor.execute(sql_query) 
t2 = time.time() 
print "Sql time = %s" % str(t2 - t1) 


t1 = time.time() 
for i in range(1, 1000): 
    cql_query = "SELECT * FROM foo_bars WHERE foo_id IN(%s) LIMIT 40" % radom_foo_ids 
    result = cassandra_cursor.execute(cql_query) 
t2 = time.time() 
print "Cql time = %s" % str(t2 - t1) 

Sql time = 4.2 
Cql time = 58.7

Заранее спасибо!

источник

2013-07-01 user2537952

Насколько велика ваша семейство колонок? Наилучшим показателем является выход используемого пространства памяти nodetool cfstats (live). – Richard

* Пространство, используемое (живой): 31749778 * Пространство, используемое (всего): 31749778 * Уплотненная строка Минимального размер: 447 \t \t * Уплотненный строк Максимального размер: 654949 \t \t * Уплотненные строки среднего размера: 68740 – user2537952

Это 31 МБ, поэтому он легко вписывается в кеш. Тогда это не может быть связано с памятью. Это может быть просто, что латентность чтения Кассандры выше, чем для MySQL. Однако пропускная способность может быть выше, но для этого вам потребуется параллелизм. – Richard

Вы можете получить его немного быстрее, включив кеш строк. Установите row_cache_size_in_mb в cassandra.yaml на что-то большее, чем ваш размер CF - так 100 будут работать. Затем установите для вашего семейства столбцов значение caching = 'all'. Когда вы читаете, вы должны увидеть увеличение скорости атаки, как сообщается nodetool info.

Однако, я сомневаюсь, что вы получите что-то вроде 10-кратного ускорения.

Проблема в том, что Cassandra (в частности, чтение) построена с высокой пропускной способностью, а не с низкой задержкой. Там есть много очередей внутри Кассандры, которые добавляют к латентности. Добавление большего количества узлов еще больше увеличит задержку (но увеличение количества узлов, значительно превышающих коэффициент репликации, не должно увеличивать латентность дальше), но дает приблизительно линейное улучшение пропускной способности.

Решение состоит в использовании параллелизма: либо очередей, потоков и нескольких подключений в одном клиенте, либо нескольких клиентов. Но если это невозможно для вашего случая использования, я ожидаю, что MySQL будет быстрее для такого типа чтения. Действительно, если вы только ожидаете иметь 31 МБ данных MySQL, вероятно, лучше для вашего случая использования в любом случае.

источник

2013-07-01 15:25:35 Richard

Привет, спасибо за информацию. Производственные данные будут в тысячи раз больше. Это было просто проверить латентность одного запроса. – user2537952

cassandra wide row column slice performance

ответ

Смежные вопросы