Как определить количество разделов при настройке временного кластера?
В не-СУБД, где увеличение количества разделов может ускорить запись и чтение за счет параллелизма, в чем обратная сторона наличия слишком большого количества разделов?
Допустим, в Cassandra ключ раздела для каждой строки уникален. В чем обратная сторона этого? С другой стороны, что, если вы выбрали очень небольшое количество разделов с фиксированным количеством?
Например, в Temporal (который использует Cassandra) при настройке Temporal кластера необходимо указать фиксированное количество разделов. Если у вас слишком мало разделов, производительность чтения/записи будет низкой при более высоких нагрузках. Но если вы увеличите количество разделов до очень большого значения, потребление ресурсов увеличится. Почему потребление ресурсов увеличивается с увеличением количества разделов? (в общем смысле, не ограничиваясь Временным)
Обновлено: Связь с очисткой памяти. Будет ли большее количество разделов вызывать частую очистку таблицы memtable в SSTable и, следовательно, вызывать гораздо большее сжатие и увеличение использования ресурсов? Если да, то почему количество разделов связано с частотой очистки памяти?
Ответы 2
Теперь давайте начнем с того, что разделы имеют много разных определений, и в некоторых случаях это может легко сбить с толку. Особенно, если Temporal использует разделы для разделения разделов Cassandra. Но давайте предположим, что мы имеем в виду разделы, такие как разделы Cassandra. Все разделено по первичному ключу, а остальные столбцы образуют строки под каждым разделом.
Cassandra хорошо масштабируется по количеству разделов, но не по размеру строк. То есть, если у вас небольшое количество разделов и вы добавляете строки в каждый раздел, вы в конечном итоге столкнетесь с проблемами.
Самая распространенная проблема здесь заключается в том, что Cassandra считывает весь раздел в память при его чтении, поэтому чем больше раздел, тем больше давление на сборщик мусора, которое вы испытываете, и тем дольше задержка при этом чтении.
Промывка имеет только прямое отношение к количеству операций записи. В этом случае не имеет значения, меньше или больше у вас разделов.
Однако все это становится намного сложнее, когда речь идет об удалениях/надгробиях, но это уже совсем другая проблема с червями.
Я не слишком знаком с тем, как Temporal использует Cassandra, но я предполагаю, что он использует «корзины», распределяя один «рабочий процесс или очередь» по нескольким разделам Cassandra, чтобы поддерживать разумный размер строк.
Если ваши разделы слишком велики, это повлияет на производительность чтения, поскольку для поиска внутри раздела потребуется большое чтение. С другой стороны, если вы разделите свой «рабочий процесс или очередь» на слишком много разделов, вам нужно будет прочитать все разные разделы, чтобы получить свою очередь, что повлияет на ресурсы сервера.
В случае с Temporal проблема, похоже, больше связана с параллелизмом, а не с большими операциями чтения. Поскольку Temporal предъявляет высокие требования к согласованности, он сериализует все запросы на каждый сегмент и использует блокировку, чтобы гарантировать обработку этих сегментов только одним узлом. Это означает, что шарды становятся единицей параллелизма. Чем больше у вас шардов, тем больше параллельных запусков. Небольшое количество сегментов означает, что ваша пропускная способность будет ограничена задержкой базы данных, но слишком большое количество сегментов приведет к конкуренции за ресурсы между потоками.
Точно. Это именно то, что я нашел в документах Temporal: «Осколки — это единица параллелизма». Но не мог ответить, почему. Не могли бы вы поделиться некоторыми ресурсами по этому образцу использования Кассандры? В частности: зачем ограничивать параллелизм количеством сегментов? Предположим, что N рабочих процессов в данном сегменте не имеют абсолютно никакой связи друг с другом, за исключением того факта, что их идентификаторы рабочих процессов хэшированы с одним и тем же идентификатором сегмента. Какая польза от сериализации записей в один сегмент, если вместо этого вы можете распараллеливать ВНУТРИ сегмента? (один поток на рабочий процесс)
Слишком много осколков — и между потоками возникнет борьба за ресурсы. Потоки в БД или потоки на клиенте (здесь, временный сервер)? И под утверждением вы имеете в виду накладные расходы на переключение контекста?
Я только что понял, что Кассандра не имеет лидера, и модель «один лидер на осколок» здесь не применима. Тогда как это обеспечит большую согласованность внутри осколка? AFAIK, одиночный лидер помогает упорядочить записи перед их применением на узле и реплицировать записи на последователях.
В Temporal все запросы к шарду выполняются последовательно, тем самым гарантируя согласованность этого шарда. Данные сортируются по сегментам, благодаря чему с разделом работает только один клиент.
Похоже, вы объединили две разные концепции Temporal и Cassandra.
В Temporal служба истории, которая сохраняет состояния выполнения рабочего процесса, разделяет нагрузку на «осколки истории» или «разделы», которые можно запускать одновременно для масштабируемости. Думайте об этих разделах как очередях записи базы данных, где каждая очередь может обрабатывать несколько запросов для сохранения состояния выполнения временных рабочих процессов.
количество сегментов истории (numHistoryShards) нельзя изменить после запуска службы, поскольку каждому сегменту соответствует соответствующее хешированное целое число, используемое для назначения очередей. Temporal использует алгоритм, который хэширует метаданные каждого выполнения рабочего процесса, чтобы назначить их сегменту истории. Если количество шардов изменится, хеш-значения также изменятся, поэтому ранее назначенные хэши станут недействительными.
Важно отметить, что разделы службы истории (осколки) — это совершенно отдельная концепция от разделов Cassandra. В Cassandra вы можете иметь столько разделов, сколько захотите.
Кроме того, количество разделов Cassandra в кластере не имеет никакого отношения к сбросу memtables на диск. Объем очистки памяти прямо пропорционален объему операций записи в базу данных. Если ваш кластер постоянно записывает много данных, таблица памяти будет регулярно заполняться, вызывая сбросы, но если записи не происходит, то и сбросов не будет. Ваше здоровье!
Если оставить в стороне временные аспекты, на уровне базы данных, подобной Cassandra, есть ли какие-либо недостатки в наличии слишком большого количества разделов?
Что касается Temporal, есть ли у вас какие-либо указания на то, почему такое приложение, как Temporal, захочет реализовать секционирование поверх секционирования, предлагаемого базовой БД? Выбор идентификатора рабочего процесса в качестве ключа раздела гарантирует, что все записи в данный рабочий процесс будут сериализованы внутри раздела (БД), верно?
Нет этому - «Если оставить в стороне временные аспекты, на уровне БД, подобной Кассандре, есть ли какие-либо недостатки в наличии слишком большого количества разделов?» Cassandra предназначена для обработки огромных объемов данных с практически неограниченным количеством разделов.
«...почему такое приложение, как Temporal, захочет реализовать секционирование поверх секционирования...» Как я уже сказал, одно не имеет ничего общего с другим. Это не разбиение разделов — один представляет собой очередь для обработки событий, другой используется для распределения данных по сотням или тысячам узлов кластера. Ваше здоровье!
Temporal, вероятно, использует Synthetic Sharding поверх осколков Кассандры lossechies.com/ryansvihla/2016/03/15/…. Во время настройки временного кластера он запрашивает фиксированное число = количество временных сегментов, и я заметил, что каждая строка имеет PK = shardId. Рабочий процесс гарантированно находится внутри данного раздела Cassandra, IMO, при условии, что его хэш (workflowID)%NumTotalShards = shardID (PK) остается прежним. Не могли бы вы рассказать, почему слишком много осколков требуют большого чтения для поиска внутри раздела?