Блог

Мы изучаем возможность использования CitusDB. После прочтения всей документации нам неясны некоторые основы. Надеюсь, кто-нибудь может дать несколько указаний.

В Citus вы указываете a shard_count и a shard_max_size , эти настройки устанавливаются для координатора в соответствии с документами (но, как ни странно, они также могут быть установлены на узле).

Что происходит, когда вы указываете 1000 сегментов и распространяете 10 таблиц со 100 клиентами?

1. Создает ли он сегмент для каждой таблицы (users_1, users_2, shops_1 и т. Д.) (Так эффективно используя все 1000 сегментов.

2. Если вы хотите расширить число клиентов еще на 100, мы уже достигли предела в 1000, как разделяются эти таблицы?

3. Значение shard_max_size по умолчанию равно 1 ГБ. Если сегмент> 1 ГБ, создается новый сегмент, но что происходит, когда shard_count уже достигнут?

4. Наконец, целесообразно ли использовать 3000 осколков? Мы читаем в документах, что 128 рекомендуется для saas. Но это мало, если у вас 100 клиентов * 10 таблиц. (Я знаю, что это зависит … но ..)

Бывший сотрудник Citus / нынешний сотрудник Microsoft здесь, присоединяюсь к некоторым советам.

Сегменты Citus основаны на целочисленных диапазонах хэшей ключа распространения. Когда вставляется строка, значение ключа распространения хэшируется, планировщик просматривает, какому сегменту был присвоен диапазон хэш-значений, в который попадает этот ключ, затем просматривает, на каком работнике находится сегмент, а затем запускает вставку для этого работника. Это означает, что клиенты распределяются по сегментам примерно равномерно, и когда вы добавляете нового клиента, он просто переходит в существующий сегмент.

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

Если у вас очень большой клиент (в 100 раз больше данных, чем у вашего среднего клиента, — это достойная эвристика), я бы заранее использовал функции изоляции арендаторов, чтобы предоставить им собственный сегмент. Это значительно упростит их перенос на выделенное оборудование, если вы решите сделать это в будущем.

Этот shard_max_size параметр не влияет на таблицы с распределенным хэшем. Сегменты будут расти без ограничений по мере того, как вы продолжаете вставлять данные, а таблицы с распределением хэшей никогда не увеличат количество сегментов при обычных операциях. Этот параметр применяется только к дистрибутиву append, который в наши дни используется довольно редко (я могу вспомнить одну или две компании, использующие его, но это все).

Я бы настоятельно не советовал менять citus.значение shard_count равно 3000 для описанного вами варианта использования. 64 или 128, вероятно, верны, и я бы рассмотрел 256, если вы просматриваете> 100 ТБ данных. Это прекрасно, если в итоге у вас будут тысячи распределенных таблиц, и каждая из них будет иметь 128 сегментов, но лучше поддерживать разумное количество сегментов на таблицу.