Проблемы с запросом данных Cassandra с PDI 5.3

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

У меня довольно много проблем с запросом данных с использованием PDI 5.3 (последняя версия). Я постоянно теряю память на стороне Кассандры.

Учитывая, что сервер, на котором я установил Cassandra, не самый лучший, 4 ГБ ОЗУ и всего 2 ядра, я все равно ожидаю, что эта простая задача будет выполнена без проблем.

В кассандре /conf/cassandra-env.sh я настроил:

MAX_HEAP_SIZE="4G"
HEAP_NEWSIZE="200M"

и теперь максимальное количество строк, которые я могу запросить, составляет 80 тыс. В документации предлагается установить MAX_HEAP_SIZE на 1/4 оперативной памяти машины. Но для меня это означало 1G и всего около 20 тысяч строк для запроса.

Я могу сказать, сколько строк я могу запросить, ограничив выбор ключевым словом limit внутри шага Cassandra input в PDI.

Есть ли какие-либо другие параметры, которые я могу настроить для повышения производительности? Это сервер разработки, на производстве я буду ожидать запросов с более чем 1 млн строк.

Сервер, на котором установлена ​​Cassandra: Red Hat Enterprise Linux Server версии 6.6 (Сантьяго)

Версия Cassandra: apache-cassandra-2.1.2

Изменить: версии обновлены.


cassandra pdi
person bioShark    schedule 26.02.2015    source источник
comment
Какую версию C* вы используете? Кроме того, почему вы запрашиваете такие большие объемы данных? Выбор 1 млн строк — отличный способ увеличить масштаб, на этом этапе вы должны разбить на страницы. Однако нам нужны журналы ошибок, я плохо опубликую ответ, но это скорее предложение, чем решение.   -  person Lyuben Todorov    schedule 28.02.2015

Ответы (1)


arrow_upward
2
arrow_downward

Пожертвуйте IO для памяти (поскольку память вас убивает):

  • нижние кэши ключей/строк, если они включены (кэш ключей включен по умолчанию)
  • если вы выполняете много удалений, вы можете уменьшить gc_grace_seconds, чтобы удалить надгробия быстрее (при условии, что вы много сканируете диапазон, который вы делаете, если вы получаете 80 тыс. строк, это может помочь)

Некоторые другие идеи:

В этой теме предлагается уменьшить размер журнала фиксации, но журнал фиксации был сильно переработан и перемещен из кучи в 2.1 и больше не должен быть такой проблемой.

person Lyuben Todorov    schedule 28.02.2015
comment
Спасибо за Ваш ответ. Я запрашиваю большой объем данных, потому что у меня много данных. На самом деле мне понадобится около 1 миллиона записей при каждом запуске. Я знаю, что разбиение на страницы должно быть решением, но PDI, инструмент Pentaho ETL, который я использую для запроса данных, не поддерживает его (насколько я вижу). Я сейчас связываюсь с их службой поддержки, чтобы узнать, как обрабатывать запросы к большим данным. Я опубликую здесь обновление, если и когда решу эту проблему. Я обновлю версии в вопросе. - person bioShark; 02.03.2015
comment
Взгляните на пример приложения twissandra, в котором реализована ручная нумерация страниц. Это на временной шкале, однако есть способы обойти модель данных, которые позволяют патинировать вручную. - person Lyuben Todorov; 02.03.2015