Мы все еще оцениваем Cassandra для нашего хранилища данных. Как очень простой тест, я вставил значение для 4 столбцов в семейство столбцов Keyspace1/Standard1 на моей локальной машине, составляющей приблизительно 100 байтов данных. Затем я считал его назад с такой скоростью, как я мог ключом строки. Я могу считать его назад в 160,000/второй.Отлично.
Затем я вставил миллион подобных записей все с ключами в форме X.Y где X в (1.. 10) и Y в (1.. 100,000), и я запросил для случайной записи. Производительность упала на 26 000 запросов в секунду. Это все еще много больше количества запросов, которые мы должны поддерживать (приблизительно 1,500/секунд)
Наконец я вставил десять миллионов записей от 1,1 до 10,1000000 и случайным образом запросил для одной из 10 миллионов записей. Производительность плачевна в 60 запросах в секунду, и мой диск мечется как сумасшедший.
Я также проверил, что, если я прошу подмножество данных, сказать 1 000 записей между 3,000,000 и 3,001,000, они возвращаются медленно сначала и затем поскольку они кэшируются, они ускоряют право, до 20 000 запросов в секунду и мой диск прекращают сходить с ума.
Я читал на всем протяжении этого, люди хранят миллиарды записей в Cassandra и выбирают их в 5-6k в секунду, но я не могу получить в какой-либо степени это с записями только на 10 миллиметров. Какая-либо идея, что я делаю неправильно? Разве существуют ли некоторые настройки, которые я должен изменить от значений по умолчанию? Я нахожусь на разогнанном поле Core i7 с 6gigs поршня, таким образом, я не думаю, что это - машина.
Вот мой код для выборки записей, которые я порождаю в 8 потоков для просьбы одно значение из одного столбца через ключ строки:
ColumnPath cp = новый ColumnPath (); CP. Column_family = "Standard1"; CP. Столбец = utf8Encoding. GetBytes ("сайт"); строковый ключ = (1+sRand. Затем (9)) +"." + (1+sRand. Затем (1000000)); ColumnOrSuperColumn logline = client.get ("Keyspace1", ключ, CP, ConsistencyLevel. ОДИН);
Спасибо за любое понимание
Похоже, у вас недостаточно оперативной памяти для хранения всех записей в памяти.
Если вы переключаетесь на диск, то у вас проблемы, и ожидается, что производительность значительно упадет, особенно при случайном чтении.
Вы также можете попробовать протестировать некоторые другие популярные альтернативы, например Redis или VoltDB .
Добавьте больше узлов Cassandra и дайте им много памяти (-Xms / -Xmx). Чем больше у вас экземпляров Cassandra, тем данные будут разделены по узлам, и с большей вероятностью они будут находиться в памяти или к ним будет легче получить доступ с диска. Вы будете очень ограничены в попытках масштабировать ЦП класса одной рабочей станции. Также проверьте настройку -Xms / -Xmx по умолчанию. Думаю, по умолчанию 1ГБ.
чисто случайное чтение - это наихудшее поведение для кэширования, которое ваша ОС (и Cassandra, если вы настроили кэш ключей или строк) пытается выполнить.
Если вы посмотрите на contrib / py_stress в дистрибутиве исходного кода Cassandra, он имеет настраиваемый stdev для выполнения случайных чтений, но с некоторыми ключами более горячими, чем другие. это будет более репрезентативно для большинства реальных рабочих нагрузок.
VoltDB , безусловно, может справиться с таким уровнем производительности чтения, как а также пишет и работает с использованием кластера серверов. В качестве решения в памяти вам необходимо построить достаточно большой кластер, чтобы хранить все ваши данные в ОЗУ.