1.2. Область применения #
Postgres Pro Shardman обеспечивает горизонтальное масштабирование со всеми преимуществами единой базы данных. Приложения могут использовать любой узел для доступа к распределённой базе данных и работать в основном так же, как и с одним экземпляром PostgreSQL. Тем не менее, по сути это распределённая система, в которой существуют определённые правила проектирования схемы и написания запросов. Основное направление внедрения — локализация данных и вычислений.
Следующие свойства базы данных или рабочей нагрузки указывают на потенциальную необходимость перехода на распределённую систему:
Рабочий набор данных не помещается в оперативную память одного сервера. В распределённых системах общий объём оперативной памяти может быть гораздо больше.
Операции технического обслуживания, например очистка, занимают слишком много времени. Shardman сразу использует секционированные таблицы, поэтому операции обслуживания можно распараллеливать по узлам и секциям таблиц.
Слишком большое количество сеансов чтения для одного экземпляра PostgreSQL. Shardman позволяет распределять сеансы чтения по кластеру и очень эффективно обрабатывать внутренние соединения с помощью мультиплексирующего транспорта.
Интенсивные операции записи. Распределённые системы могут работать со значительно большим общим количеством дисковых операций ввода-вывода в секунду.
Запросы с интенсивной вычислительной нагрузкой на процессор. Shardman позволяет распределить вычисления по узлам и сократить время выполнения сложных запросов.
Использовать Postgres Pro Shardman нецелесообразно в следующих случаях:
Вертикальное масштабирование экономически и технически возможно.
Модель данных и рабочая нагрузка требуют большого количества межсегментных транзакций.
Сложная аналитика, в частности объединение сегментированных таблиц в условиях отсутствия ключа сегментирования.
Развёртывание кластера типа Multi-DC/Multi-region.
1.2. When to use #
Postgres Pro Shardman provides horizontal scalability with a view and consistency of a single database. Applications can use every node to access the distributed database and operate mostly the same way as with a single PostgreSQL instance. Still internally it is a distributed system that imposes certain rules on designing schema and writing queries. The main direction of adoption is to localize the data and the computations.
The following properties of a database or workload should be marks to consider a distributed system:
The working set of data does not fit in RAM of one server. Distributed systems can have much bigger total size of RAM.
Maintenance operations such as vacuum take too long. Shardman utilizes partitioned tables under the hood. Maintenance operations can be parallelized by nodes and partitions of tables.
Number of read sessions is too large for one instance of PostgreSQL. Shardman allows to distribute read sessions across the cluster and handle internal connections very efficiently with multiplexing transport.
Intensive write operations. Distributed systems can have much bigger total number of disk IOPS.
CPU intensive queries. Shardman allows to distribute calculations by nodes and reduce execution time for complex queries.
When Postgres Pro Shardman is not appropriate:
Vertical scaling is economically and technically possible.
Data model and workload require a lot of cross-shard transactions.
Complex analytics, in particular joins of sharded tables when conditions don't include the sharding key.
Multi-DC/Multi-region deployments.
