Вопрос о последовательности Кассандры?

Question

У нас есть кластер кассандры в трех разных центрах обработки данных (DC1, DC2 и DC3), и у нас есть 10 машин в каждом центре данных. У нас есть несколько таблиц в Кассандре, в которых у нас менее 100 записей.

Что мы видим - некоторые таблицы не синхронизированы между машинами в DC3 по сравнению с DC1 или DC2, когда мы выбираем count(*) для него.

В качестве примера мы выбрали count(*) при подключении к одной машине cassandra в центре обработки данных dc3 по сравнению с одной машиной cassandra в центре обработки данных dc1, и результаты были другими.

root@machineA:/home/david/apache-cassandra/bin# python cqlsh dc3114.dc3.host.com
Connected to TestCluster at dc3114.dc3.host.com:9160.
[cqlsh 2.3.0 | Cassandra 1.2.9 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh> use testingkeyspace ;
cqlsh:testingkeyspace> select count(*) from test_metadata ;

count
-------
    12

cqlsh:testingkeyspace> exit
root@machineA:/home/david/apache-cassandra/bin# python cqlsh dc18b0c.dc1.host.com
Connected to TestCluster at dc18b0c.dc1.host.com:9160.
[cqlsh 2.3.0 | Cassandra 1.2.9 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh> use testingkeyspace ;
cqlsh:testingkeyspace> select count(*) from test_metadata ;

count
-------
    16

Что может быть причиной этой проблемы синхронизации? Это должно случиться когда-нибудь? Может кто-нибудь пролить некоторый свет на это?

Поскольку наш код драйвера java и код драйвера datastax C++ используют эти таблицы с ONSISTENCY LEVEL ONE.

Answer 1

В связи с этим вы можете делать запросы с разными уровнями согласованности из cqlsh. Просто беги:

CONSISTENCY EACH_QUORUM;

или же

ПОСТОЯННО ВСЕ;

и т.п.

Параметр будет сохраняться в течение всего сеанса cqlsh или до тех пор, пока вы не замените его другим оператором CONSISTENCY.

EACH_QUORUM или ALL должны гарантировать вам одинаковый ответ независимо от вашего координатора. Хотя производительность примет удар. Смотрите пункт Ашика на счет (*) в целом. Если это общий запрос, другой вариант - сохранить счет в отдельной таблице.

Answer 2

Какая у вас стратегия репликации? Для кросс-центра обработки данных вы должны обратить внимание на NetowrokTopologyStrategy с коэффициентами репликации, указанными для каждого центра обработки данных. Затем во время ваших запросов вы можете указать кворум / локальный кворум и т. Д. Однако подумайте об этом на минуту:

• У вас есть распределенный кластер с несколькими центрами обработки данных. Если вы хотите каждый_кворум, подумайте о том, что просит ваша кассандра - для чтения или записи, попросите его сохранить кворум в обоих центрах данных по отдельности, прежде чем возвращать успех. Подумайте о задержках и обрыве сетевых подключений. Для чтения запрашиваемый клиентский узел становится координатором. Он отправляет запись в локальные реплики центра обработки данных и в один узел для удаленных центров обработки данных. Получатель там координирует свой местный кворум. После этого он возвращает результаты, а когда первоначальный координатор получает достаточно ответов, он возвращает. Все хорошо. Медленно, но хорошо. Теперь для записей происходит нечто подобное, но если координатор не знает, что узел не работает, он все равно отправляет узлы. Запись завершается, когда узел возвращается в исходное состояние, но клиент может получить тайм-аут записи (обратите внимание, не сбой - запись в конечном итоге будет успешной). Это может происходить чаще между несколькими центрами обработки данных.

• Вы ищете для подсчета (*) запросов. Это вообще ужасная идея. Это должно ударить каждый раздел для таблицы. Кассандре нравятся запросы, которые попадают в один раздел или хотя бы небольшое количество разделов (через фильтр IN).

• Подумайте, что делает select count(*) в распределенной системе. Что означает результат? Результат может устареть мгновение спустя. Во время обработки результата запроса может быть другая вставка в каком-то другом центре обработки данных.

Если вы хотите производить агрегацию по лотам или всем разделам, рассмотрите возможность объединения cassandra с искрой, а не пытайтесь выбрать select(*) для центров обработки данных. И чтобы вернуться к более раннему моменту, не предполагайте (или не зависите) перекрестную согласованность центра обработки данных. Примите непротиворечивую согласованность и разработайте приложения для этого.

Надеюсь, это поможет.