Я изменил целую базу кода от Thrift
до CQL
, используя datastax java driver 1.0.1
и cassandra 1.2.6..
с осторожностью я получал частые тайм-ауты с самого начала, я не смог продолжить... Принятие CQL, таблицы, разработанные в соответствии с тем, что я получил успех и меньше тайм-аутов....
С этим я смог вставить огромные данные, которые не работали с бережливостью... Но после этапа, папка с данными около 3,5 ГБ. Я получаю частые исключения таймаута записи. даже я делаю то же самое предыдущее рабочее прецедентом снова, которое также выдает исключение времени ожидания. СЛУЧАЙНАЯ РАБОТА СЛУЧАЙНАЯ РАБОТА НЕ РАБОТАЕТ, ДАЖЕ ПОСЛЕ СВЕЖЕЙ НАСТРОЙКИ.
ЛОГИСТИКА СЕРИИ СЕРИИ CASSADNRA
это частичный режим log-сервера cassandra в режиме DEBUG, после чего я получил ошибку:
Клиентское исключение:
Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:54)
at com.datastax.driver.core.ResultSetFuture.extractCauseFromExecutionException(ResultSetFuture.java:214)
at com.datastax.driver.core.ResultSetFuture.getUninterruptibly(ResultSetFuture.java:169)
at com.datastax.driver.core.Session.execute(Session.java:107)
at com.datastax.driver.core.Session.execute(Session.java:76)
Инфраструктура: 16GB машина с 8-гигабайтной кучей, предоставленная cassandra, процессор i7. Я использую SINGLE node cassandra с этим yaml, настроенным на время ожидания, все остальное по умолчанию:
- read_request_timeout_in_ms: 30000
- range_request_timeout_in_ms: 30000
- write_request_timeout_in_ms: 30000
- truncate_request_timeout_in_ms: 60000
- request_timeout_in_ms: 30000
ИСПОЛЬЗОВАНИЕ CASE: Я запускаю usecase, в котором хранятся комбинации (моя терминология проекта) в cassandra.... В настоящее время тестирование хранит 250 000 комбинаций с 100 параллельными потоками. Каждая нить хранит одну комбинацию... реальный случай мне нужно поддерживать десятки миллионов, но для чего потребуется другое аппаратное обеспечение и кластер node...
При сохранении ONE комбинация занимает около 2 секунд и включает в себя:
- 527 Запросы INSERT INTO
- 506 Запросы UPDATE
- 954 SELECT-запросы
100 параллельных потоков параллельно хранят 100 комбинаций.
Я нашел поведение WRITE TIMEOUTS случайным, когда он работает до 200 000, затем перебрасывает таймауты и иногда не работает даже для 10k комбинаций. СЛУЧАЙНОЕ ПОВЕДЕНИЕ.