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

Мы все еще оцениваем 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 запросов в секунду, и мой диск перестает сходить с ума.

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

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

ColumnPath cp = новый ColumnPath(); cp.Column_family = "Стандарт1"; cp.Column = utf8Encoding.GetBytes («сайт»); строковый ключ = (1+sRand.Next(9)) + "." + (1+sRand.След.(1000000)); ColumnOrSuperColumn logline = client.get("Keyspace1", key, cp, ConsistencyLevel.ONE);

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


person Jody Powlette    schedule 17.06.2010    source источник


Ответы (4)


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

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

person jbellis    schedule 17.06.2010
comment
К сожалению, у нас будут случайные посетители, приходящие на наш сайт через случайные промежутки времени - нет распределения, о котором мы знали бы заранее, чтобы получить больше попаданий в кеш. В этом случае мы просто ограничены скоростью диска? - person Jody Powlette; 17.06.2010
comment
Ничто не является действительно случайным. Ваша реальная производительность, скорее всего, будет лучше, чем ваши тесты. При этом Кассандра действительно использует всю память на коробке? 60 чтений в секунду настолько ужасны для вашего оборудования, что, вероятно, у вас проблема с настройкой (ну, в зависимости от того, насколько ужасны ваши диски). Кроме того, убедитесь, что Cassandra не использует подкачку, как если бы это была физическая память — это создает патологическую проблему с производительностью, поскольку Cassandra и ОС независимо друг от друга пытаются оптимизировать страницы в памяти конкурирующими способами. - person Nick Bastin; 18.06.2010

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

person Todd    schedule 17.06.2010

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

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

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

person the_void    schedule 17.06.2010
comment
Мы определенно не можем уместить их все в памяти, но 10 миллионов записей — это не так уж много. Как люди справляются с миллиардами записей?? - person Jody Powlette; 17.06.2010
comment
Ключ в том, чтобы хранить как можно больше в оперативной памяти, а не на диске. Чтобы обрабатывать миллиарды записей, вы должны распределить их по нескольким машинам и использовать как единое целое. Вот очень хорошая статья [1] о том, как это достигается в Riak, другом популярном решении NoSQL. Многие аспекты, рассмотренные в статье, применимы и к Cassandra, поскольку они основаны на тех же фундаментальных идеях. [1]: wiki.basho.com/display/RIAK/An+ Введение+к+Риаку - person the_void; 17.06.2010

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

person tmcallaghan    schedule 01.07.2010