#node.js #mongodb #express #architecture #mern
#node.js #mongodb #экспресс #архитектура #мерн
Вопрос:
Я работаю над приложением с высокой интенсивностью ввода-вывода (выбор основан на наличии мест) с использованием стека MERN. Ожидается, что приложение получит 2000 одновременных пользователей. Я хочу знать, разумно ли использовать два экземпляра MongoDB, один в ОЗУ (в памяти), а другой на жестком диске.
ОЗУ, которое будет использоваться для хранения доступных мест. И жесткого диска для резервного копирования данных через регулярные промежутки времени. Но в то же время я знаю, что при сбое сервера мои данные MongoDB в оперативной памяти будут потеряны.
Не мог бы кто-нибудь подсказать мне, пожалуйста?
Я использую Socket IO вместо AJAX…
Комментарии:
1. Если вы собираетесь запускать несколько экземпляров Mongo, вы должны разделить их, вот как вы масштабируете. Нужно ли вам масштабировать или нет, это то, на что можете ответить только вы, предпочтительно после выполнения тестов или фактического запуска чего-то, что вызывает проблемы со слишком большим количеством пользователей.
Ответ №1:
Я не думаю, что вам это нужно. Вы можете получить хороший сервер с хорошим объемом оперативной памяти, и если вы правильно создадите свои индексы, все должно работать нормально.
Кроме того, Mongo 3 не будет блокировать всю базу данных при каждом обновлении, как это делал Mongo 2.
Я считаю, что лучшим подходом было бы использовать что-то вроде Memcached для улучшения чтения. Кроме того, для повышения производительности базы данных и автоматического перехода на другой ресурс используйте сегменты и наборы реплик.
Учтите также, что у вас будут головные боли при перезапуске вашего сервера и потере ваших данных…
Ответ №2:
Это кажется ненужным, потому что MongoDB уже ведет себя точно так же, как готовый.
Старый движок (MMAPv1) использовал файлы с отображением в память, что означает, что если у вас столько оперативной памяти, сколько у вас данных, он практически ведет себя как база данных в памяти с автоматическим резервированием на жесткий диск.
Новый движок (проводной Tiger) работает немного по-другому в деталях, но в целом тот же. Это позволяет вам установить размер кэша (хранилище ключей конфигурации.WiredTiger.engineConfig.cacheSizeGB). Когда размер кэша будет достаточно большим, у вас снова будет база данных в памяти с автоматическим зеркальным отображением на жестком диске.
Подробнее об этом в FAQ по хранилищу.
Комментарии:
1. Некорректное сравнение MMAP и WiredTiger с механизмом in-memory. Совершенно другое поведение, даже если все данные помещаются в память. Механизм in-memory имел отличные характеристики с точки зрения задержки, производительности и предсказуемости во всех ваших тестах производительности просто потому, что ему никогда не нужно записывать или читать с диска. Поэтому ошибочно говорить, что MMAP / WiredTiger ведут себя так же, как движок в памяти.
2. @AminJ некорректное возражение . И MMAPv1, и WT пытаются сохранить как можно больше данных в дополнение к индексам в ОЗУ. Этот набор данных называется рабочим набором. В зависимости от вашей конфигурации этот набор данных может быть или не быть «синхронизирован» с диском, в дополнение к поведению, определяемому выбранной проблемой записи. До этого момента поведение (не реализация!) идентичен с точки зрения высокого уровня. И точка Phillips, насколько я вижу, заключалась в том, чтобы не запускать как выделенную базу данных в памяти, поскольку MongoDB в любом случае хранит столько данных в ОЗУ, и ручное управление может укусить вас в шею.
3. Правильное замечание о рабочем наборе, но чтение здесь не главное. Проблемы с записью влияют на то, как ваш клиент получает подтверждения, но в конечном итоге mongo сбросит данные на диск (либо журналы, которые вы можете отключить, либо, например, контрольные точки wiredtiger). И это сильно влияет на предсказуемость и задержку вашего mongod. Я все еще думаю, что упрощать, говоря, что вы можете имитировать движок в памяти с помощью MMAP или WiredTiger.
Ответ №3:
То, о чем вы говорите, — это проблема масштабирования. Когда дело доходит до масштабирования, у вас есть два варианта: добавить ресурсы, вызывающие узкое место в вашей существующей настройке (обычно больше оперативной памяти и более быстрые диски) или расширить вашу настройку. Сначала вы должны добавить ресурсы, почти до того момента, когда добавление ресурсов не даст вам соответствующей отдачи.
В какой-то момент это «масштабирование» больше не будет возможным, и вам придется распределять нагрузку между большим количеством узлов.
MongoDB поставляется с функцией распределения нагрузки между (логическими) узлами: сегментирование.
В принципе, это работает следующим образом: несколько наборов реплик, каждый из которых формирует логический узел, называемый сегментом. Каждый сегмент, в свою очередь, содержит только подмножество ваших данных. Вместо прямого подключения к сегментам вы обрабатываете свои данные через mongos маршрутизатор запросов, который знает, в каком сегменте хранятся данные для ответа на запрос и куда записывать новые данные.
При тщательном выборе ключа сегментов ваши операции чтения и записи должны быть равномерно распределены между сегментами.
Примечание: размещение производственных данных в отдельном экземпляре вместо набора реплик пересекает границу небрежности в моей книге. Учитывая цены на сегодняшнее (арендованное) оборудование, устранить единственную точку отказа никогда не было проще, чем с набором реплик MongoDB.