In-App шардирование PostgresDB. Практическое велосипедостроение

Для иллюстрации разницы хватит вот такого тела запроса.

{
    "group_id" : 123,
    "group_name" : "foo",
    "sub_group_id" : 42
} 

В случае, когда shard key - явное поле, берем, group_id и его прогоняем через хэширование.

Когда shard key - вычисляемое поле, например, складываем group_id и sub_group_id и прогоняем через хэширование сумму.

Или, например, делаем запрос куда-то еще, чтобы получить по sub_group_id shard key для этого запроса.

Описанное решение совершенно никак не ограничивает, откуда берется shard key. Его может вообще в запросе не быть.

In-App шардирование PostgresDB. Практическое велосипедостроение

У нас нет прохода по кольцу далее, если не найден сервер, отвечающий за диапазон.

In-App шардирование PostgresDB. Практическое велосипедостроение

1. Пришел запрос, который нужно боработать, сходив в базу за данными. Например возьмем простой select из базы

2. Получили из запроса shardKey (в зависимости от запроса может быть либо явным полем, либо вычисляемым). Например считаем, что это явное поле типа айдишника, какой-нибудь группы сущностей

3. Вычислили hash(shardkey) % 65536, это значение и есть номер бакета, где лежат данные для данного shardKey - bucket_index.

4. Теперь нужно понять, какой сервер отвечает за диапазон бакетов, в который попадает вычисленный шагом выше

5. Сходили в интервальное дерево, построенное поверх выбранной из master шарда конфигураци шардированного кластера. Взяли тот узел этого дерева, который отвечает за диапазон, в который попадает вычисленный на шаге 3 бакет.

   1. Если убрать интервальное дерево из рассмотрения, то на базе это будет (в псевдо-SQL) выглядеть как SELECT * FROM shards where bucket_index_start <= bucket_index <= bucket_index_end LIMIT 1

6. Из узла взяли connection string к серверу

In-App шардирование PostgresDB. Практическое велосипедостроение

Данному решению неважно, какой load balancing алгоритм используется в кластере, куда задеплоен сервис, оно находится уровнем ниже - на data access level. Потому я про load balancing на уровне k8s в этой статье и не писал.

В разных частях наших k8s кластеров используются различные алгоритмы банасировки, не только round robin, но и он тоже присутствует. Подробнее ответить вам не могу, могу только сказать, что ничего самописного в этой области у нас нет - выезжаем на стандартных механизмах k8s.

In-App шардирование PostgresDB. Практическое велосипедостроение

Что касается гибридных решений для Postgres — большинство из них основаны на технологии PG FDW. FDW (foreign data wrapper) — это функциональность сервера Postgres, которая позволяет ему рассматривать данные на удаленном сервере как часть большего набора и интерпретировать этот разделенный на несколько серверов набор данных как единое целое. У этой технологии есть свои проблемы, но самая большая из них — доступ к данным через FDW чрезвычайно медленный.

Это выдержка из статьи.

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

In-App шардирование PostgresDB. Практическое велосипедостроение

1. Да, стандарнтый k8s load balancer.

2. Да.

3. "Приложение" в этом контексте - это back-end сервис, а не мобильное приложение. Мобильное приложение вообще в базы напрямую не ходит, только в back-end сервисы.

In-App шардирование PostgresDB. Практическое велосипедостроение

Нет, мы сейчас в обсуждении находимся на ноде k8s, в каком-нибудь поде с нашим back-end сервисом. Мобильное приложение оперирует back-end сервисами, выставляющими для него свои API.

Так вот, мы в back-end сервисе. К нему прилетает запрос. Мы понимаем, что этот запрос нужно обслужить, сходив в шардированную базу.

Из запроса берется значение ключа шардирования (обычно это одно из полей запроса, но не всегда), оно прогоняется через преобразование (в том числе - хэширование), из него получается номер бакета. Дальше мы идем в in-memory cache сервиса, где лежит интервальное дерево с диапазонами бакетов и конфигурацией обслуживающих эти диапазоны шардов. Из дерева выбираем узел, который нам подходит по диапазону, в этом узле есть конфигурация соответсвующей ноды кластера, в том числе со строкой подключения.

Далее мы идем в еще один in-memory cache и смотрим, есть ли у нас свободный коннект с такими же параметрами подключения. Если да - берем его. Если нет - создаем новое подключение, которое мы, по завершении работы с ним, положим в этот самый in-memory cache.

In-App шардирование PostgresDB. Практическое велосипедостроение

У приложения по сути есть вся конфигурация кластера - где какой шард лежит, какой диапазон бакетов обслуживает и прочее. Приложение эту конфигурацию получило, единожды сходив в master шард.

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

In-App шардирование PostgresDB. Практическое велосипедостроение

Два нюанса.

Первый. Мы не ходим в master на каждый запрос конфигурации кластера, а храним ее в in-memory кэше.

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

В остальном вы все абсолютно верно поняли.

In-App шардирование PostgresDB. Практическое велосипедостроение

Всегда пожалуйста! Рад, что понравилось и (или) было полезно!

Данные самые разные - таблицы от сотен мегабайт (такие обычно кладем в solid шард, так как шардировать их не имеет смысла) до нескольких терабайт.
Структура таблиц также различнавя - от пары-тройки полей до десятков.

In-App шардирование PostgresDB. Практическое велосипедостроение

1. Нет. Правильность разрешения шарда многократно тестировалась и проблем обнаружено не было. По вопросам по поиску, пожалуйста, обращайтесь через форму обратной связи в приложении.

2. Можно, но мы не храним ключ шардирования (только диапазон бакетов, в которые попадает это значение), и от кольца отказались.

In-App шардирование PostgresDB. Практическое велосипедостроение

Текущее решение получилось именно таким как раз потому, что мы закладывались на потенциальный автоматический решардинг. Плюс готовим решение по группам микрокластеров на основе описанного в статье, где BucketNumber будет не жестко прибит гвоздями.

In-App шардирование PostgresDB. Практическое велосипедостроение

Спасибо за уточнение и совет, отразим этот момент в статье.

In-App шардирование PostgresDB. Практическое велосипедостроение

Пока не выкладывали, но если выложим - обязательно расскажем об этом.

In-App шардирование PostgresDB. Практическое велосипедостроение

Изобрели, называется CitusDB. Но нам это решение, увы, не подошло.