Вытягивать внешние данные по каждому запросу или хранить локально?

Question

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

Данные хранятся в JSON и центральном источнике, работающем на Nodejs и MongoDB. Клиентские сайты в основном являются Wordpress (несколько других сторонних CMS) и поэтому работают на PHP и MySQL.

Способ, которым мы это настроили, состоит в том, чтобы вытащить данные (списки недвижимости) из центрального db по каждому запросу и отобразить как обычный HTML.

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

Мой вопрос: это идеальное решение? Что было бы лучше?

Моя первая мысль заключалась в создании решений push/store, где центральный источник выдавал данные по мере их сбора и хранили их локально на каждом клиентском сайте. Но для каждого клиента, очевидно, потребуется какая-то инфраструктура базы данных, что, вероятно, сделает ее более сложной, чем нужно.

Мысли?

Answer 1

Центральный источник данных не является плохим, если его в той же сети и не представляет много накладных расходов. Вам нужно будет запустить некоторый тест, чтобы убедиться, что вызовы большинства клиентов имеют одинаковое время отклика. Если доступ не является проблемой, центральный db оснащен так, чтобы обрабатывать так много клиентов параллельно, а затем иметь центральную БД имеет смысл.

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

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

У меня была аналогичная ситуация, когда моя команда использовала БД для репликации БД через пакетное задание, которое выполняется каждый день в нерабочее время (мы принимаем только измененные/добавленные записи для репликации, чтобы уменьшить размер обновления данных, вы можете реализовать аналогичную логика на основе вашего набора данных).

Поскольку клиент становится сложным, я не думаю, что он сильно изменит сложность с точки зрения кодирования. Ваш внешний интерфейс не изменится, только вызов данных (возможно, веб-сервис) будет получать данные из БД вместо центрального хранилища данных.

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

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