Стратегия пула подключений: хорошо, плохо или безобразно?

Question

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

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

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

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

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

Answer 1

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

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

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

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

Предложение вашего коллеги перемещает вас к настройке единой точки отказа.

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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