Архитектура шардинга NodeJS со многими подходами к базам данных MondoDB

Question

У нас проблема с архитектурой в нашем проекте.Этот проект требует шардинга, как только нам понадобится практически неограниченная масштабируемость для части сервисов.В настоящее время мы используем Node.js + MongoDb (Mongoose) и MySQL (TypeORM).Данные разделяются базами данных через простой «БД Локатор»Таким образом, процесс узла нуждается в подключении ко многим БД (до 1000).

Пример запроса:

• HTTP-запрос от клиента с идентификатором магазина;
• Получить БДIP-адрес / учетные данные в сервисе «DB Locator» по идентификатору магазина;
• Создание соединения с конкретной базой данных с данными магазина;
• Выполнение запросов в БД.

Мы пыталисьреализовать его двумя способами:

1. Создать соединение для каждого запроса, закрыть его при ответе.Проблемы:
   • мы не можем использовать соединение после ответа (это главная проблема, потому что иногда нам нужны некоторые асинхронные действия);
   • это работает медленнее;
2. Держите все соединения открытыми.Проблемы:
   • достигают лимита одновременных подключений или каких-то других ограничений;
   • утечки памяти.

Какой способ лучше?Как избежать описанных проблем?Может быть, есть лучшее решение?Решение № 1 отлично сработало для нас на php, так как оно запускает один процесс по запросу и легко сбрасывает соединения при завершении процесса.Как мы знаем, Express - это чистый код JS, работающий в v8 и не основанный на процессах.Было бы здорово автоматически закрыть неиспользуемые соединения, но не могу найти варианты для этого.

Answer 1

Краткий ответ : прекратить использование MongoDB с Mongoose ?

Более длинный ответ:

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

Здесь стоит Mongoose.Это библиотека, которая заставляет вас чувствовать, что ваш мусорный ящик - это прекрасный мир с отношениями, виртуальными полями и множеством вещей, которых не должно быть в DODBMS.Кроме того, существует много устаревшего кода из предыдущих версий, что также создает некоторые проблемы с управлением соединениями.

Вы уже используете TypeORM, который может работать вместо Mongoose.С некоторыми ограничениями, конечно.Он работает точно так же, как и управление подключениями MySQL.

Вот еще несколько данных: https://github.com/typeorm/typeorm/blob/master/docs/mongodb.md#defining-entities-and-columns

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