Какой может быть самый масштабный подход к загрузке функционала?

Question

В настоящее время мы разрабатываем систему посещаемости (на основе журналов IN и OUT), где клиент может загрузить данные своих сотрудников за последние 6 месяцев. В настоящее время мы сталкиваемся с проблемой, когда набор данных очень большой. В настоящее время мы используем Mon go в качестве основной базы данных для обслуживания загрузки. И извлечение, и написание его в Excel - тяжелая операция. Я знаю определенные способы решения этой проблемы. Я перечисляю все это и хочу, чтобы вы помогли мне выбрать наиболее масштабируемый вариант.

a) Увеличьте конфигурацию сервера.

b) Переместите все данные в предварительно обработанном формате в какую-либо другую базу данных (например, поиск elasti c) в отдельном микро-сервисе. Это сократит мое время выборки данных.

c) Поскольку запись данных в Excel для 5-10 миллионов записей сама по себе является процессом, потребляющим память. Должны ли мы реализовать запись данных в Excel через очередь (Kafka или rabbitmq) с несколькими пакетами Kubernetes с одним или ограниченным количеством запросов одновременно?

d) комбинация опции b и опции c.

Пожалуйста, помогите мне с вашим предложением и дайте мне знать, если есть какое-то другое масштабируемое решение.

Answer 1

Прямо сейчас вы используете MongoDB для извлечения и фильтрации данных, которые, как вы упомянули, не в предварительно обработанном формате.

MongoDB или другой основанный на документе номер SQL, такой как DynamoDB, очень хорош, когда вы сохраняете данные в денормализованном формате и затем получаете их на основе идентификатора или с помощью нескольких фильтров , даже для эффективной фильтрации данных вам необходимо создать индекс (аналогично MySQL index), который занимает дополнительное пространство и по умолчанию не кэшируется.

При правильном использовании выше отображается страница сведений о продукте. на сайтах электронной коммерции, где эти данные обычно хранятся в нормализованном формате для поддержки ACID, но также и в denormalized format in NoSQL для поддержки более быстрого чтения, и там вы не выполняете поиск, но поиск в электронной коммерции по-прежнему осуществляется только через инвертированный индекс *.

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

Elasticsearch автоматически кэширует часто используемые фильтры для повышения производительности.

Это решит вашу проблему o Для извлечения миллиона документов , и после этого, как вы уже упоминали, вы должны использовать механизм очереди для записи этих огромных данных, и Kafka очень популярен и отлично подходит для этого варианта использования.

PS: - Нет необходимости увеличивать конфигурации сервера, правильный дизайн решит проблему, и добавление большего количества оборудования - это просто борьба с симптомом, а не устранение причины root.