Cassandra: оптимизация пакетной записи

Я получаю массовый запрос на запись, скажем, около 20 ключей от клиента. Я могу либо написать их на C* в одной партии, либо написать их по отдельности асинхронным способом и ждать будущего, чтобы завершить их.

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

есть ли способ в драйвере Java datastax, с помощью которого я могу группировать ключи который может принадлежать к тому же разделу, а затем клуб их в маленький пакеты, а затем сделать invidual unlogged пакетной записи в асинхронном режиме. в том как я делаю меньше вызовов RPC сервер при этом координатор будет нужно писать локально. Я буду использовать политику token aware.

11
cassandra cassandra-3.0 datastax datastax-java-driver

2 ответов

ваша идея правильная, но нет встроенного способа, вы обычно делаете это вручную.

главное правило здесь-использовать TokenAwarePolicy, поэтому некоторая координация произойдет на стороне водителя. Затем вы можете сгруппировать свои запросы по равенству ключа раздела, что, вероятно, будет достаточно, в зависимости от вашей рабочей нагрузки.

что я имею в виду под "группированием по равенству ключа раздела", например, у вас есть некоторые данные, которые выглядят как 

MyData { partitioningKey, clusteringKey, otherValue, andAnotherOne }

затем при вставке нескольких такие объекты, вы группируете их по MyData.partitioningKey. Это, для всех existsing paritioningKey значения, вы берете все объекты с теми же partitioningKey, и завернуть их в BatchStatement. Теперь у вас есть несколько BatchStatements, так что просто выполните их.

если вы хотите пойти дальше и имитировать хеширование Кассандры, то вы должны посмотреть метаданные кластера через getMetadata метод com.datastax.driver.core.Cluster класс, есть способ getTokenRanges и сравните их с результатом Murmur3Partitioner.getToken или любой другой разделитель, настроенный в cassandra.yaml. Я никогда не пробовал хотя это я сам.

Итак, я бы рекомендовал реализовать первый подход,а затем проверить ваше приложение. Я сам использую этот подход, и в моей рабочей нагрузке он работает намного лучше, чем без пакетов, не говоря уже о пакетах без группировки.

9

вход партии следует использовать осторожно в Кассандре, потому что они накладывают дополнительные накладные расходы. Это также зависит от распределения ключей разделов. Если ваша массовая запись нацелена на один раздел, используйте Unlogged пакетное результаты в одной операции вставки.

В общем, писать их invidually в асинхронной манере, кажется, хороший подход, как указал здесь: https://medium.com/@foundev/cassandra-batch-loading-without-the-batch-the-nuanced-edition-dd78d61e9885

вы можете найти пример кода на вышеуказанном сайте, Как обрабатывать несколько асинхронных записей: https://gist.github.com/rssvihla/26271f351bdd679553d55368171407be#file-bulkloader-java https://gist.github.com/rssvihla/4b62b8e5625a805583c1ce39b1260ff4#file-bulkloader-java

изменить:
пожалуйста, прочитайте это также: https://inoio.de/blog/2016/01/13/cassandra-to-batch-or-not-to-batch/#14

сколько стоит одна партия разделов?

нет пакетного журнала, написанного для отдельных пакетов разделов. Этот координатор не имеет никакой дополнительной работы (как для multi раздела пишет), потому что все идет в один раздел. Одиночный пакеты разделов оптимизированы: они применяются с одним RowMutation [10].

в нескольких словах: одиночные пакеты раздела не кладут гораздо больше нагрузки на сервер чем обычно пишет.


сколько стоит пакет с несколькими разделами?

позвольте мне просто процитировать Кристофера Бейти, потому что он суммировал это очень хорошо в своем посте "Cassandra anti-pattern: Logged batches" [3]:

Cassandra [сначала] записывает все операторы в журнал пакетов. Что пакетный журнал реплицируется на два других узла в случае, если координатор неудачи. Если координатор терпит неудачу, то другая реплика для пакетного журнала возьму на себя. [..] Координатор должен делать гораздо больше работы, чем любой другой узел в кластере.

опять же, в пулях, что нужно сделать:

  1. сериализация инструкций пакета
  2. запишите сериализованный пакет в системную таблицу журнала пакетов
  3. повторить этого сериализованный пакет на 2 узла
  4. координатная запись в узлы, содержащие различные разделы
  5. при успешном удалении сериализованного пакета из журнала пакетов (также на 2 репликах)

помните, что незаполненные пакеты для нескольких разделов устарели с Cassandra 2.1.6

0