Коллеги, добрый день! Подскажите по кейсу. Был один маленький кластер, возникла

потребность в сегментировании.

Можно ли сделать без даунтайма?

Хмм... а подробнее (что есть, что должно получиться и т.п.)? Ну и зачем (почему прямо-таки "потребность"), ради любопытства?

Проектирование архитектуры. Одно из требований данные хранить вечно. Хочу предложить, когда БД будет >1 ТБ применить сегментирование. serverIndex =hash(key)%N, N количество серверов. Применить согласованное хэширование Тут предлагают альтернативные БД рассмотреть (Cockroach DB, Yugabyte DB, SPQR, Shardman) https://pgconf.ru/2023/347233

Ах, ещё и шардирование, а не секцыонирование. Мда. Пока что выглядит как "забудьте, вы потратите много времени, чтобы потом потерять ещё денег и времени".

Про секцыонирование в принцыпе можно подумать... Но, ревльно лимит на основную часть таблицы у нас 32TB. Ужэ явно надо секцыонировать, чтобы не было проблем — когда 15TB. Пора думать о секцыонировании — когдо ну 7TB. Ну 5TB. Вашы >1... Отложыте лучшэ на потом. Ах, да, мне сейчас ещё напомнят, что секцыонирование можэт быть полезно когда есть проблемы с maintainance или когда часть данных хочется выкинуть на дешёвые носители. Но до первого вы вроде не дошли, а второе на вашых объёмах неактуально. И да, по сути вопроса о малом downtime — можно, конечно. Можно создать триггер, заполняющий новые таблицы новыми данными — после этого постепенно перенести туда все старые данные. А потом очень быстро поменять старую структуру таблиц на новую. (Одно переименование таблиц).

Илья, благодарю. Вы из команды разработки Postgres Pro?

Нет.

> Хочу предложить, когда БД будет >1 ТБ применить сегментирование. Почему бы не применить вертикальное масштабирование и репликацию, казалось бы... > Тут предлагают альтернативные БД рассмотреть Кто ж Вам помешает-то. ;) Только всё это чего-то [очень даже] стоит, понимаете (усилий в разработке и поддержке — как минимум)?

1.Время выполнения полного бэкап БД 12TB около 20 часов; 2.Однопоточный процесс резервного копирования 3.Есть требование работать на дешевом железе 4.В любом случае ограничение 32ТБ на таблицу 5.Репликации для чтения есть в любом случае 6.На запись 50+k QPS

1. У вас там шпиндельный диск что ли?

поддержка так говорит

> 1.Время выполнения полного бэкап БД 12TB около 20 часов; > SELECT pg_size_pretty( (12.0 * 1024 * 1024 * 1024 * 1024) / (20.0 * 60 * 60) ); 175 MB (в секунду). Это HDD, что ли? > 2.Однопоточный процесс резервного копирования pgBackRest и т.п. не смотрели? > 3.Есть требование работать на дешевом железе А, теперь понятнее... а шарды как помогут времени выполнения restore (кроме снижения надёжности в разы), если не секрет? ;) Или там данные очень походят под шардирование? > 4.В любом случае ограничение 32ТБ на таблицу Partitioning (уже писали выше). > 5.Репликации для чтения есть в любом случае В этом случае они должны бы быть для High Availability, нет? > 6.На запись 50+k QPS Это в TPS нужно считать... И, опять-таки, сработает только если схема такая, что позволяет иметь достаточно много независимых шардов (а остальное уже определяется исключительно "железом" — у любой ACID СУБД ровно та же прямая зависимость maximum commit rate от IOPS).

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

Это не входит в скоуп моих задач, заказчик сказал mid-range+ СХД покупать сложно и дорого

Нда. Как говорит известная народная мудрость — "скупой платит 25%" (или как-то так). ;)