PostgreSQL - одна из самых мощных и удобных систем управления базами данных. Она активно поддерживается сообществом и ежегодно получает новые релизы. PostgreSQL поддерживает самые продвинутые функции SQL-стандарта. Также предоставляет возможности NoSQL, богатый набор типов данных и расширений, что делает PostgreSQL привлекательным решением для программных систем.
В этом курсе мы рассматриваем задачу создания масштабируемых решений на основе PostgreSQL, используя ресурсы нескольких серверов. Существует естественное ограничение для таких систем - всегда приходится идти на компромисс между производительностью, надежностью и согласованностью. Можно улучшить один аспект, но при этом пострадают другие. На этом курсе мы увидим, как найти лучший баланс для наших задач, чтобы точно понять, какие аспекты требуют масштабирования и как избежать типичных компромиссов в распределенных системах.
Масштабирование PostgreSQL - это путь. После этого курса вы сможете лучше оценивать потребности в масштабировании, поймете, как масштабировать чтение и как масштабировать запись.
Каждое решение, представленное в этом курсе, улучшит определенный аспект масштабируемости, но каждое из них добавит и сложность, а возможно, и некоторые ограничения.
Для начала важно правильно поставить вопросы, чтобы понять требования к системе, и именно поэтому мы посвятили отдельное занятие тому, чтобы разобрать, какие вопросы мы должны задать себе перед началом пути к масштабированию.
После этого курса вы будете лучше подготовлены и поймете, как масштабировать чтение.
У нас есть несколько вариантов репликации, в зависимости от того, что для нас важнее - производительность или гибкость.
Репликация может быть использована как резервное копирование или в качестве резервного решения, которое активируется в случае сбоя основного сервера.
Также репликация может повысить производительность системы, поскольку позволяет распределить нагрузку на несколько серверов базы данных.
Далее, если одна из форм репликации настроена, можно подумать о том, чтобы несколько компьютеров обслуживали одни и те же данные.
Для этого нужен механизм для распределения запросов. Мы рассмотрим здесь два из самых популярных доступных вариантов.
Далее, если число подключений к базе данных велико, вам, вероятно, понадобится пул соединений. Мы также рассмотрим здесь два варианта.
Мы также изучим, как масштабировать записи и сделать рост трафика более предсказуемым, добавив очереди в архитектуру.
После этого мы рассмотрим партиционирование для случаев, когда необходимо работать с большими таблицами.
Также мы изучим шардирование для масштабирования записи и все сложные решения, которые с этим связаны.
Наконец, мы кратко рассмотрим мульти-мастер решение, которое является относительно новой концепцией, но выглядит многообещающе.
Если наша цель заключается только в высокой доступности (HA) или способности продолжать работу даже в случае сбоя одного из серверов кластера, можно рассмотреть только те решения, которые подходят для этих задач.
Для обеспечения высокой доступности необходимо настроить стратегию репликации.
Затем можно использовать инструменты, позволяющие резервному серверу быстро принять на себя нагрузку, если основной сервер выйдет из строя.
