Стратегия пула соединения: хороший, плохой или ужасный?

Если у вас одна база данных и два пула соединений, по 5 соединений в каждом, у вас будет 10 соединений с базой данных. Если у вас есть 5 пулов подключений по 2 подключения в каждом, у вас будет 10 подключений к базе данных. В итоге у вас есть 10 подключений к базе данных. База данных не знает, что ваш пул существует, нет информации.

Любые метаданные, которыми обмениваются пул и БД, будут происходить при каждом соединении. Когда соединение запускается, когда соединение разрывается и т. Д. Итак, если у вас 10 соединений, этот трафик будет происходить 10 раз (как минимум, при условии, что все они остаются исправными в течение всего срока службы пула). Это произойдет независимо от того, есть ли у вас 1 пул или 10 пулов.

Что касается «1 БД на приложение», если вы не разговариваете с отдельным экземпляром базы данных для каждой БД, тогда это в основном не имеет значения.

Если у вас есть сервер БД, на котором размещено 5 баз данных, и у вас есть соединения с каждой базой данных (скажем, 2 соединения на каждую), это потребует больше накладных расходов и памяти, чем та же БД, на которой размещена одна база данных. Но эти накладные расходы в лучшем случае незначительны и совершенно незначительны на современных машинах с буферами данных размером ГБ. После определенного момента все, о чем заботится база данных, - это отображение и копирование страниц данных с диска в ОЗУ и обратно.

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

Наконец, когда я использую слово «база данных», я имею в виду логический объект, который сервер использует для объединения таблиц. Например, Oracle действительно любит иметь одну «базу данных» на сервере, разбитую на «схемы». Postgres имеет несколько БД, каждая из которых может иметь схемы. Но в любом случае все современные серверы имеют логические границы данных, которые они могут использовать. Я просто использую здесь слово «база данных».

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

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

База данных и накладные расходы, 1 пул с 30 подключениями и 3 пула с 10 подключениями в основном одинаковы, если предположить, что нагрузка одинакова в обоих случаях.

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

Дизайн, архитектура, планы и великие идеи терпят неудачу, если за ними нет здравого смысла или простой математики. Еще немного практики и / или опыта помогут ... Вот простая математика того, почему 10 пулов с 5 подключениями не то же самое, что 1 пул с 50 подключениями: каждый пул настроен с минимальным и максимальным количеством открытых подключений, факт в том, что он обычно будет использовать (99% времени) 50% минимального числа (2-3 в случае 5 минут), если он использует больше, чем этот пул неправильно настроен, так как он постоянно открывает и закрывает соединения (дорого) ... поэтому мы 10 пулов с 5-минутными соединениями каждый = 50 открытых соединений ... означает 50 TCP-соединений; 50 соединений JDBC поверх них ... (вы отлаживали соединение JDBC? Вы удивитесь, сколько метаданных передается в обе стороны ...) Если у нас есть 1 пул (обслуживающий ту же инфраструктуру, что и выше), мы можем установить min 30 simple, потому что он сможет более эффективно сбалансировать дополнительные функции ... это означает, что на 20 подключений JDBS меньше. Не знаю, как вы, но для меня это много ... Дьявол кроется в деталях - 2-3 соединения, которые вы оставляете в каждом пуле, чтобы он не открывался / не закрывался все время ... Не хочу даже тратить лишние деньги на управление 10 пулами ... (Я не хочу поддерживать 10 пулов, каждый из которых сильно отличается от другого, не так ли?) Теперь, когда вы начали меня с этого, если бы это был я, я бы "обернул" БД (источник данных) одним приложением (уровень обслуживания кто угодно?), Который предоставил бы службы различий (REST / SOAP / WS / JSON - выберите свой яд), а мои приложения даже не узнают о JDBC, TCP и т. д. и т. д. о, подождите, это есть у Google - GAE ...

Что ж, отличный вопрос, но его нелегко обсудить, используя подход с использованием нескольких баз данных (A) или большой (B):

1. Это зависит от самой базы данных. Oracle, например, ведет себя иначе, чем Sybase ASE в отношении стратегии LOG (и, следовательно, LOCK). Возможно, было бы лучше использовать несколько различных и небольших баз данных, чтобы поддерживать низкий уровень конкуренции за блокировку, если имеется много параллельных операций записи и БД использует стратегию пессимистической блокировки (Sybase).
2. Если табличное пространство маленького базы данных не распределены по нескольким дискам, возможно, лучше использовать одну большую базу данных для использования (буферной / кеш-памяти) памяти только для одного. Я думаю, что это редко бывает.
3. Использование (A) лучше масштабируется по другой причине, чем производительность. Вы' Возможность переноса базы данных горячих точек на другое (более новое / быстрое) оборудование, когда это необходимо, не затрагивая другие базы данных. В моей бывшей компании этот подход всегда был дешевле варианта (B) (без новых лицензий).

Лично я предпочитаю (A) по причине 3.