Пул баз данных, когда его использовать, а когда нет - PullRequest
0 голосов
/ 16 октября 2018

Я исследовал весь интернет о пуле баз данных, но до сих пор не понимаю нескольких вещей, на которые я надеюсь найти ответ от более опытных разработчиков.

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

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

Не могли бы вы также дать мне сценарий, в котором следует использовать пул баз данных, а когда нет?

Спасибо за разъяснение любого моего сомнения.

Ответы [ 2 ]

0 голосов
/ 16 октября 2018

Пулы соединений обрабатываются по-разному в разных сценариях приложений и на разных платформах / языках.

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

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

Во-вторых, управление соединениями является проблемой - существует множество различных сценариев обработки ошибок, параметров конфигурации и т. Д .;это хорошая идея, чтобы централизовать это.Конечно, вы можете сделать это без пула соединений.

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

0 голосов
/ 16 октября 2018

В .Net пул соединений обрабатывается автоматически, а не непосредственно вашим приложением.

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

https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-connection-pooling

Если вы говорите о другой платформе, механика другая, хотя цель одна и та же.

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

Объединение в пул сохраняет соединения открытыми и сокращает накладные расходы на их открытие для каждого запроса.

Также не могли бы вы дать мнесценарий, в котором следует использовать пул баз данных, а когда нет?

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

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

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

Если у вас есть приложение, которое открывает соединение и оставляет его открытым, то теоретическое объединение не поможет.С практической точки зрения, полезно периодически уничтожать и воссоздавать различные ресурсы, такие как соединения, дескрипторы, сокеты и т. Д., Поскольку программное обеспечение не идеально, а некоторый код содержит утечки ресурсов.

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

...