Блог

Таким образом, на нашем веб-сайте растет объем данных, и мы обычно используем представления mysql для списков записей, чтобы упростить запрос select в наших кодах. С тех пор это стало практикой, но со временем требования ввели множество сложностей в представления SQL, таких как сумма, количество и т. Д. Таким образом, большинство наших взглядов относительно медленнее.

Чтобы сохранить логику, созданную в представлениях MySQL (поскольку это предпочтения нашего клиента), мы попробовали следующее:

Вариант 1 заключается в том, чтобы:

1. Раскрутил RDS 2
2. Выберите * из списка на нашем RDS 1
3. Вставьте во все результаты в RDS 2
4. Подключите API списков для извлечения данных из RDS 2

С #4 он возвращается быстро, потому что база данных больше не будет повторно оценивать сумму, подсчитывать, нам просто нужно получить результат. #2 amp; #3:

• Наш сервер API работает под управлением nodejs, и он подключается к этим 2 базам данных.
• Я сохраняю только 1000 на список/таблицу. Итак, если у меня 6 представлений = создается 6 плоских таблиц.
• Такое случается по крайней мере каждую минуту. Мы внедрили флаг, чтобы проверить, идет ли процесс, прежде чем повторять весь процесс.

Проблема с этой опцией: это напрягает наш сервер RDS 1 и API.

Вариант 2 заключается в том, чтобы:

1. Создайте другую таблицу на том же RDS 1
2. Вставить в представление выбрать из sql
3. Подключите API списка для извлечения данных из созданной плоской таблицы

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

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

Заранее спасибо.

«сумма, количество и т. Д.» — Это похоже на «отчет» по сравнению с большой таблицей «Фактов» в хранилище данных.

План А-Сводные таблицы

Если данные статичны (после их вставки), то создавайте и поддерживайте сводные таблицы. Это будет намного быстрее и эффективнее во всем. Вы все еще можете поставить VIEW или Stored Proc перед нужными «выборками».

Такие сводные таблицы будут храниться в одном экземпляре и могут занимать всего 20% дополнительного дискового пространства. И, поскольку они работают намного быстрее, нет необходимости настраивать другой сервер. http://mysql.rjweb.org/doc.php/summarytables

VIEWs являются синтаксическим сахаром. Они никогда(?) не быстрее , чем базовые SELECT , а иногда и медленнее. Они, как говорит ваш клиент, облегчают запросы.

План Б — Репликация

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

(И A, и B можно сделать.)