Производительность чтения кассандры для большого количества ключей
Вот ситуация
Я пытаюсь получить около 10 тысяч ключей от CF. Размер кластера: 10 узлов. Данные на узле: 250 ГБ. Куча выделена: 12 ГБ. Используется Snitch: свойство Snitch с двумя стойками в одном центре обработки данных. нет. sstables для cf на узел: около 8 до 10
Я использую суперколонку. Каждая строка содержит около 300 суперколонок, которые в терминах содержат 5-10 столбцов. Я запускаю мультисет с 10k ключами строки и 1 суперколонкой.
При первом вызове требуется около 30-50 секунд, чтобы вернуть результат. После этого Кассандра передает данные из кеша ключей. Затем он возвращает результат через 2-4 секунды.
Так что производительность чтения cassandra мешает нашему проекту. Я использую phpcassa. Есть ли способ настроить серверы cassandra так, чтобы я мог быстрее получить результат?
Влияет ли подход с использованием суперколонок на производительность чтения?
3 ответа
Использование суперколонок лучше всего подходит для случаев использования, когда число подколонок является относительно небольшим. Подробнее читайте здесь: http://www.datastax.com/docs/0.8/ddl/column_family
На тот случай, если вы еще этого не сделали, поскольку вы используете библиотеку phpcassa, убедитесь, что вы скомпилировали библиотеку Thrift. В соответствии с текстовым файлом "УСТАНОВКА" в папке библиотеки phpcassa:
Использование расширения C
Расширение C имеет решающее значение для производительности phpcassa.
Вам нужно настроить и сделать так, чтобы можно было использовать расширение C.
cd thrift/ext/thrift_protocol
phpize
./configure
make
sudo make install
Добавьте следующую строку в ваш файл php.ini:
extension=thrift_protocol.so
После того, как мы проделали большую часть RND по поводу этих вещей, мы решили, что вы не сможете добиться оптимальной работы. Когда Кассандра выбирает эти 10 тыс. Строк в первый раз, это займет время, и оптимизировать это невозможно.
1) Однако на практике вероятность того, что люди получат доступ к одним и тем же записям, больше. Таким образом, мы максимально используем преимущество кэша ключей. Значение по умолчанию для кэша ключей составляет 2 МБ. Таким образом, мы можем позволить себе увеличить его до 128 МБ без проблем с памятью. После загрузки данных запустите ожидаемые запросы для разогрева кеша ключей.
2) JVM работает оптимально на 8-10 ГБ (не иметь чисел, чтобы доказать это. Просто наблюдение).
3) Наиболее важно, если вы используете физические машины (не облачные ИЛИ виртуальные машины), тогда проверьте планировщик диска, который вы используете. Установите NOOP, который хорош для cassandra, поскольку он считывает все ключи из одного раздела, уменьшая перемещение заголовка диска.
Вышеуказанные изменения помогли сократить время выполнения запросов в допустимых пределах.
Наряду с вышеуказанными изменениями, если у вас есть CF, которые имеют небольшой размер, но часто доступны, включите для них кэширование строк.
Надеюсь, выше информация полезна.