Вы не должны использовать ограниченную коллекцию для этого. Я предполагаю, что вы делаете это, потому что вы хотите сохранить небольшой объем «горячих» данных и перенести устаревшие данные в постоянную коллекцию. Тем не менее, это то, что происходит в любом случае, когда вы используете MongoDB. Данные, к которым часто обращаются, будут храниться в памяти, а данные, которые используются реже, не будут. То же самое касается ваших индексов, если они остаются сбалансированными. Я думаю, что вы делаете преждевременную оптимизацию или, по крайней мере, имеете неоптимальную схему или индексную стратегию для вашей проблемы. Если вы опубликуете, что именно вы пытаетесь достичь, и где ваша производительность пикирует, я могу посмотреть.
Чтобы ответить на ваш актуальный вопрос; MongoDB не имеет обратных вызовов или триггеров. Однако есть несколько открытых запросов к ним.
РЕДАКТИРОВАТЬ (Небольшая разработка по технической реализации): MongoDB построен поверх файлов с отображенной памятью для своего механизма хранения. По сути, это означает, что это кэш «горячих» данных на основе LRU, где данные в этом случае могут быть как фактическими данными, так и индексными данными. В результате данные и связанные с ними индексные данные, к которым вы часто обращаетесь (в вашем случае данные, которые вы обычно имеете в своей закрытой коллекции), будут в памяти и, следовательно, будут очень быстро запрашивать. В типичных случаях использования разница в производительности между «активной» коллекцией и «архивной» коллекцией и только одной большой коллекцией должна быть небольшой. Как вы можете себе представить, если для процесса mongod доступно больше памяти, это означает, что в памяти может остаться больше данных, и в результате производительность улучшится. На mongodb.org есть несколько хороших презентаций от 10gen, в которых более подробно рассказывается, как правильно сбалансировать индексы и т. Д.