Логика работы с MongoDB в сервере на Node.JS?

Question

[Антон Крюков]

Вопрос довольно банальный, но, кажется, нигде детально не рассматривается: как правильно организовать работу с БД, учитывая асинхронную природу node.js?

То есть когда коннектиться и закрывать соединение с БД — при каждом реквесте или один раз при запуске/остановке приложения?

Стоит ли кэшировать интерфейсные объекты коллекций и курсоры, которые можно переиспользовать?

И если держать соединение открытым, то как обрабатывать возможные разрывы?


Если вам известен хороший пример приложения, в котором всё это грамотно реализовано — поделитесь ссылкой на исходники. А то все примеры в документации сводятся к примитивной цепочке db.open() -> db.collection() -> collection.crud() -> db.close()

Comments

[Антон Крюков]

UPD: Спасибо за ответы!
Придётся покопаться в коде драйвера и понять насколько он «умный».
В крайнем случае написать свой пулл. Или использовать какой-нибудь из ODM (до сих пор их не рассматривал, надеясь обойтись минимумом).

Answer 1

[Yuri Shikanov]

Насколько я понимаю, адаптер берет эту работу на себя. Т.е. в приложении об этом не нужно беспокоится, создал соединение один раз и пользуешься. А все остальное происходит за кулисами. Думаю об этом подробнее можно почитать в документации к адаптеру mongodb.

Comments

[Yuri Shikanov]

И чего мы минусуем? Вообще-то в адаптере уже есть встроенный пул, размер пула задается параметром poolSize.

Answer 2

[Артур Заяц]

Я использую mongoosejs, пример хорошей архитектуры для него — github.com/madhums/node-express-mongoose-demo
В монгусе автоматом создается пул соединений (по умолчанию из 5 штук), есть опция — автореконнект.

Схматично работает так: при запуске приложения делаешь коннект с нужными тебе опциями — и все, во всех остальных модулях, просто require('mongoose') и делаешь с базой все, что угодно (так как модуль подтягивается закешированный с установленным соединением)

Answer 3

[napa3um]

При инициализации приложения однократно подключайся к базе данных с помощью MongoClient. Объект MongoClient создаёт пул соединений к БД, и сам восстановит соединение в случае разрыва. Также при инициализации рекомендую получить все необходимые коллекции для дальнейшей работы с ними, т.к. помимо оверхеда на создание JS-объектов в режиме strict получение коллекции вызывает проверку существования коллекции в базе данных. При этом закэшированные объекты коллекций будут использовать вышеописанные преимущества объекта MongoClient - пул соединений и переподключение в случае разрыва. Самостоятельно закрывать соединения не нужно, контекста и блокировок у соединения нет. Т.е., логика примерно такая (очень условно, без учёта архитектуры приложения):

// init db:
MongoClient.connect('mongodb://localhost:27017/dbName', function(err, db){
    cached.db = db;
    // init collection:
    db.collection('collName', { strict: true }, function(err, coll){
        cached.coll = coll;
    });
});
// usage in request:
cached.coll.insert(...);

Answer 4

[Stdit]

При использовании одного соединения с БД есть серьёзный риск перегрузить сокет базы настолько, что именно он станет узким тормозящим местом всего проекта. Это довольно подлый нюанс, который не заметен на этапе тестирования и ввода в эксплуатацию (как и проблема гонок в mongo, но это отдельный разговор). У меня такое было, правда не на mongo, а на pg, но суть от этого не меняется: пока сокет базы занят перекачиванием больших объемов данных на специфических страницах, сайт будет заблокирован. Но и открывать соединение с базой на каждый запрос тоже не самая лучшая идея, так как на открытие, настройку и содержание соединения нужно несоразмерно много ресурсов (в том числе и на сервере БД). Поэтому должен быть пул соединений с БД. Драйверы mysql и pg такой пул имеют, насчет mongodb не уверен, так как не копал устройство драйверов mongo для nodejs.

Answer 5

[Илья Севостьянов]

Разные драйверы по разному решают эту задачу, нативный например вот так
github.com/mongodb/node-mongodb-native/blob/master/docs/articles/MongoClient.md
В исходниках можно посмотреть что-же на самом деле происходит.

Но в общем случае — правильным будет: открыть коннект -> записать/прочитать -> закрыть коннект

Есть исключительные случаи, когда такое поведение накладно, например у меня была задача, еогда очень маленькие порции данных приходили очень часто, настолько, что открытие/закрытие коннекта на фоне общего цикла «получили-записали» было просто неприлично большим.
Но в таком случае необходимо обязательно предусматривать сброс при первом существенном простое.
У монги как-то плоховато с длинными коннектами, ну по крайней мере так было раньше…

Answer 6

[Аркадий]

Ноду не использовал, но в том-же твистед писал пулл соединений, который сам заботится обо всем.

Comments

[Аркадий]

Я думаю вам стоит так-же копать в этом направлении. Так-как:

1. открывать соединение при каждом запросе — это не правильно.
2. открывать соединение при старте приложения — это не правильно (может потерять сеть)