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

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

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

2) Большая доступность — потому что сбой одного сегмента не влияет на другие сегменты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн, архитектура, планы и отличные идеи терпят неудачу, когда за ними нет здравого смысла или простой математики. Еще немного практики и/или опыта… Вот простая математика того, почему 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 пулов, каждый из которых настолько отличается от другого, не так ли?) Теперь, когда вы меня начнете, если это на моем месте я бы «обернул» БД (источник данных) одним приложением (каким-нибудь сервисным уровнем?), которое предоставило бы службы сравнения (REST/SOAP/WS/JSON — выберите свой яд), и мои приложения даже не узнают про JDBC, TCP и т.д. и т.п. о, подождите, в гугле есть - GAE...