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

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

Сотрудник полагает, что эта стратегия не будет масштабироваться, потому что так много разных пулов подключений не будут масштабируемыми и что мы должны реорганизовать базу данных, чтобы все разные приложения использовали единую центральную базу данных и что любые изменения которые могут быть уникальными для системы, должны быть отражены от одной базы данных, а затем использовать один пул, работающий от Tomcat. Он полагает, что существует множество "метаданных", которые идут по сети и поддерживают пул соединений.

Мое понимание заключается в том, что при правильной настройке использовать только столько подключений, сколько необходимо, в разных пулах (приложения с низким объемом, которые получают меньше соединений, приложения с большими объемами объема и т.д.), что количество пулов не имеет значения по сравнению с количество подключений или более формально, что разница в накладных расходах, необходимых для поддержания 3 пулов из 10 соединений, незначительна по сравнению с 1 пулом из 30 соединений.

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

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

Ответ 1

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

1) Большая масштабируемость - потому что каждый осколок может жить на отдельном оборудовании, если это необходимо.

2) Большая доступность - поскольку сбой одного осколка не влияет на другие осколки.

3) Большая производительность - поскольку поиск таблиц имеет меньше строк и, следовательно, меньшие индексы, которые позволяют быстрее выполнять поиск.

Ваше предложение коллеги переводит вас в одну точку сбоя.

Что касается вашего вопроса о 3 пулах соединений размером 10 против 1 пула соединений размером 30, лучший способ решить эту дискуссию - это тест. Настройте приложение в любом случае, затем выполните стресс-тестирование с помощью ab (BenQ) и посмотрите, какой способ лучше работает. Я подозреваю, что не будет существенной разницы, но сделать тест, чтобы доказать это.

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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