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

Question

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

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

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

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

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

Answer 1

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

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

2) Большая доступность - потому, что выход из строя одного осколка не оказывает влияния на другие осколки

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

Answer 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 - выберите ваш яд) t даже знаю о JDBC, TCP и т. д. и т. д. oh, подождите, у Google есть это - GAE ...