​​Как и зачем делить базы данных по отдельным установкам СУБД

В комментариях также спрашивали, как и по каким принципам делить базы по установкам экземпляров сервера БД и сколько памяти кому выделять.

Если брать конкретные цифры, то дать тут общие рекомендации сложно, нужно смотреть на сценарии применения, объемы данных, интенсивность и характер обращения к СУБД, в общем – требуется индивидуальный подход.

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

Описывая модель нами сознательно предельна упрощена и не требует каких-либо специфических знаний, а также применима к любым СУБД, а не только PostgreSQL.

Одной из задач СУБД – является быстрое и эффективное предоставление прикладному ПО доступа к хранящихся в базе данных. А получить мы их можем одним единственным образом – прочитать с диска.

Но чтение с диска – процесс дорогой и достаточно медленный. Поэтому, чтобы избежать повторного чтения СУБД помещает поднятые с диска данные в оперативную память. И делать так она будет до тех пор, пока будет иметь доступную память.

Именно этим объясняется известное всем стремление SQL-серверов занять всю доступную память. В простейших случаях, когда база по размеру гораздо меньше, чем размер оперативной памяти, то она будет закеширована практически вся.

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

При достаточном количестве памяти через некоторое время будет достигнут некоторый баланс и все горячие данные будут в кеше. Иначе одни будут постоянно вытеснять другие и СУБД будет вынуждена постоянно прибегать к дисковому чтению.

Хотя это не всегда плохо, с появлением быстрых дисков, таких как NVMe, иногда более оптимально будет читать данные с диска, нежели тратить на их хранение достаточно ограниченный ресурс оперативной памяти.
А теперь про то, зачем делить базы по разным экземплярах СУБД. Представим, что у нас есть некоторый единый сервер, где находятся базы торгового подразделения и бухгалтерии.

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

Но вот наступает конец месяца, и бухгалтерия начинает закрывать месяц, готовить отчетность, начислять зарплату, считать налоги, формировать регламентированные отчеты.

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

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

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

Какой выход? В лоб – добавить память. Но опять-таки мы не можем гарантировать, что кто-то не перетянет на себя все одеяло, разве что памяти с запасом хватит на всех. Но это не про современные объемы данных.

Поэтому просто делим один экземпляр СУБД на два и каждому выделяем свое количество памяти. Да, в итоге каждый получит меньше, чем мог бы откусить из общей кучи и может начать работать немного медленнее.

Но это будет гарантированная производительность, особенно после того, как вы определите достаточный объем памяти для хранения всего горячего кеша. Соседи могут делать все, что угодно. Равно как и вы.

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

При этом накладные расходы на дублирование экземпляров СУБД минимальные, особенно если мы используем контейнеры.