Использование памяти сервера Meteor для тысяч одновременных пользователей

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

Соответствующая часть связанного ответа (акцент мой):

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

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

В качестве расчета вне манжеты, если приложение имело около 100 КБ кэша на одного клиента, тогда 10 000 одновременных пользователей будут использовать до 1 ГБ памяти на сервере, а 100 000 пользователей - колоссальные 10 ГБ! Это было бы правдой, даже если бы каждый клиент просматривал практически идентичные данные. Кажется правдоподобным, что приложение использует гораздо больше данных, чем для каждого клиента, что еще больше усугубит проблему.

Есть ли эта проблема в текущей версии Meteor? Если да, то какие методы можно использовать для ограничения объема памяти, которую сервер должен использовать для управления всеми подписками клиентов?

Ответ 1

Взгляните на это сообщение от Arunoda на своем блоге meteorhacks.com:
http://meteorhacks.com/making-meteor-500-faster-with-smart-collections.html

который рассказывает о его странице "Умные коллекции":
http://meteorhacks.com/introducing-smart-collections.html

Он создал альтернативный стек Collection, который преуспел в достижении целей для скорости, эффективности (памяти и процессора) и масштабируемости (вы можете увидеть сопоставленное сравнение в сообщении). Разумеется, в его тестах использование ОЗУ было небрежным с обоими типами коллекций, хотя способ, которым он реализовал вещи, должен иметь очень очевидное отличие от типа используемого вами случая.

Кроме того, вы можете видеть в этом сообщении о метеорном ядре:
https://groups.google.com/d/msg/meteor-core/jG1KLObX1bM/39aP4kxqWZUJ
что разработчики Meteor знают о своей работе и сотрудничают в реализации некоторых улучшений в самом Метеор (но до тех пор его интеллектуальный пакет отлично работает).

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