Скорость случайной скорости Cassandra

Question

Мы по-прежнему оцениваем Cassandra для нашего хранилища данных. В качестве простого теста я вставил значение для 4 столбцов в семейство столбцов Keyspace1/Standard1 на моем локальном компьютере, составив около 100 байт данных. Затем я читал его так быстро, как мог, по строке. Я могу прочитать его обратно на 160 000 в секунду. Отлично.

Тогда я поставил миллион похожих записей с ключами в виде X.Y, где X в (1..10) и Y в (1..100.000), и я запросил случайную запись. Производительность упала до 26 000 запросов в секунду. Это все еще намного превышает число запросов, которые нам нужны для поддержки (около 1500/сек).

Наконец, я поставил десять миллионов записей с 1.1 до 10.1000000 и случайным образом запросил один из 10 миллионов записей. Производительность огромна при 60 запросах в секунду, и мой диск обмахивается, как сумасшедший.

Я также подтвердил, что если я попрошу подмножество данных, скажем, 1000 записей между 3 000 000 и 3 001 000, он медленно возвращается сначала, а затем, когда они кэшируют, он ускоряет до 20 000 запросов в секунду, а мой диск перестает сходить с ума.

Я читал все, что люди хранят миллиарды записей в Кассандре и получают их со скоростью 5-6 тыс. В секунду, но я не могу приблизиться к этому только с 10-миллиметровыми записями. Любая идея, что я делаю неправильно? Есть ли какая-то настройка, которую мне нужно изменить от значений по умолчанию? Я на разогнанном ядре Core i7 с 6 гигабайтами, поэтому я не думаю, что это машина.

Вот мой код, чтобы принести записи, которые я в нерест 8 потоков задать для одного значения из одного столбца с помощью строки ключа:

ColumnPath сра = нового ColumnPath(); cp.Column_family = "Standard1"; cp.Column = utf8Encoding.GetBytes ("сайт"); string key = (1 + sRand.Next (9)) + "." + (1 + sRand.Next (1000000)); ColumnOrSuperColumn logline = client.get («Keyspace1», key, cp, ConsistencyLevel.ONE);

Спасибо за любые идеи

Answer 1

Похоже, у вас нет достаточно оперативной памяти для хранения всех записей в памяти.

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

Вы также можете попробовать сравнить другие популярные альтернативы, например Redis или VoltDB.

Answer 2

чисто случайные чтения - это худшее поведение для кэширования, которое пытается сделать ваша ОС (и Cassandra, если вы настроили кеш ключей или строк).

Если вы посмотрите на contrib/py_stress в дистрибутиве источника Cassandra, у него есть конфигурируемый stdev для выполнения случайных чтений, но с некоторыми клавишами горячее, чем другие. это будет более характерным для большинства реальных рабочих нагрузок.

Answer 3

Добавить больше узлов Cassandra и предоставить им много памяти (-Xms/-Xmx). Чем больше у вас экземпляров Cassandra, данные будут разбиты по узлам и, скорее всего, будут в памяти или более легко доступны с диска. Вы будете очень ограничены, пытаясь масштабировать один процессор класса рабочей станции. Также проверьте настройку по умолчанию -Xms/-Xmx. Я думаю, что по умолчанию 1 ГБ.

Answer 4

VoltDB может, безусловно, справиться с этим уровнем производительности чтения, а также писать и работать с использованием кластера серверов. В качестве решения в памяти вам нужно создать достаточно большой кластер для хранения всех ваших данных в ОЗУ.