Поддерживают ли какие-либо базы данных автоматическое / временное закрытие баз данных?

Вы убедились, что это действительно проблема? Я только упомянул, что, поскольку стоимость открытой базы данных, вероятно, довольно мала, в частности, «открытие», скорее всего, состоит из синхронизации любых невыполненных транзакций, ожидающих базу данных, и выполнения базовой проверки согласованности (в частности, загрузки пары страниц сохраненных данных на диске).

Как только это будет сделано, без активности, на сервере будет не так много данных, которые нужно поддерживать.

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

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

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

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

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

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

В конце концов, все (ВСЕ) данные в базе данных хранятся «одинаково», таблица - это таблица, это таблица, индекс - это индекс, это индекс, особенно на центральном сервере, где все страницы данных управляются как единый большой "суп" данных.

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

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

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

Я бы проверил вашу выбранную базу данных, чтобы убедиться, что это проблема. Например, вы можете создать 1 миллион баз данных, максимально уменьшить объем памяти для базы данных, а затем просто начать циклически просматривать их, открывая столько, сколько считаете нужным (10, 100, 1000 и т. Д.), И посмотреть, если у вас какие-то проблемы.

Наконец, я не «знаю» ничего из этого для какой-либо конкретной базы данных, это просто инстинкт о том, как исторически реализованы базы данных.

У меня есть эта идея, и предполагаю, что вы используете Windows:

1. Ваша база данных будет работать как служба, и у каждого клиента будет свое уникальное имя службы.
2. Вы пишете командный файл, который запускает / останавливает эту службу.
3. командный файл будет вызываться с вашего сервера в любое время.

Я понимаю, что у вас может быть достаточно клиентов, чтобы процессу не хватало дескрипторов файлов. Как насчет пула подключений к БД?

Когда поступит запрос пользователя, посмотрите, открыта ли БД этого пользователя. Если да, используйте соединение и сбросьте флаг времени последнего доступа.

Если БД этого пользователя не открыта, откройте соединение, установите время последнего доступа и используйте соединение (если нет доступного соединения, выдайте ошибку). Кроме того, разветвите процесс / поток / легкий процесс / как вы его называете в своей среде, который проверяет:

Если в пуле достаточно неиспользуемых соединений, поток завершен.

Если нет, просканируйте самые старые из последних 5% -25%, к которым обращались, или те, которые не использовались в последнюю минуту / час / день (в зависимости от того, что подходит для вашего шаблона запроса пользователя) и закройте их, перейдя в неиспользуемый пул

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

mySql с заданием cron.

Кроме того, mySql занимает очень мало места (по сравнению с Sql Server) ... один из примеров: он не потребляет память (и да, я знаю, что можно ограничить использование памяти Sql Server).

mySql также имеет пул соединений, который очень эффективен и полезен.

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

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

PostgreSQL изначально использует кеш операционной системы как кеш второго уровня; в то время как кеш первого уровня (shared_buffers) по-прежнему постоянно потребляет память, его обычно устанавливают только на 10-25% вашей памяти даже на серверах, критичных к производительности. Остальное бесплатно для кэширования на уровне ОС и будет выделено базе данных, когда это необходимо, и будет доступно другим приложениям, когда им это нужно.