Запрос о производительности базы данных и надежности программного обеспечения - PullRequest
Новая
       24

Запрос о производительности базы данных и надежности программного обеспечения

0 голосов
/ 05 сентября 2018

Suituation: Клиент использует финансовое веб-приложение, в котором основные функции включают в себя огромный объем финансовых транзакций как внутри, так и снаружи. Процессы автоматизированы. В полночь мы выполняем несколько рабочих задач cron, чтобы разделить платежи для соответствующих клиентов. Ежемесячно в среднем у нас появляется от 2000 до 3000 новых клиентов, а в настоящее время их насчитывается 30 000. Наши транзакционные таблицы на данный момент насчитывают почти 900 000 записей и ожидают резкого увеличения в ближайшие месяцы.

Технологии: Изначально мы использовали среду LAMP, с каркасом Codeignitor, Laravel elequont ORM для запросов и Mysql. Хостинг: размещен в AWS, небольшой экземпляр T2, балансировщик нагрузки не реализован. ** Это приложение было разработано три года назад.

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

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

Технологии: Узел (Sails.js), Angular 5, AWS с балансировщиком нагрузки, AWS RDS (Mysql)

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

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

Запросы:

  1. Хорошо ли разбивать готовые таблицы только на отдельные базы данных или мы можем иметь их в одной базе данных.
  2. Чем буферный кэш Mysql отличается от Redis / memcache. Есть ли проблемы с использованием памяти при увеличении трафика?
  3. Каков наилучший подход к усечению нескольких таблиц в конце каждого месяца (как я уже говорил о файле журнала)?
  4. Я двигаюсь в правильном направлении?

1 Ответ

0 голосов
/ 20 сентября 2018

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

  1. Узнайте, какие запросы вызывают наибольшую проблему. См. this для предложений по использованию mysqldumpslow -s t или pt-query-digest для их поиска.
  2. Предоставьте SHOW CREATE TABLE и EXPLAIN SELECT ... для обсуждения того, как их улучшить. Это может быть так же просто, как добавление «составного» индекса.

Другим возможным узким местом производительности может быть многократное суммирование старых данных. Если дело обстоит именно так, рассмотрите метод хранения данных _создание и ведение сводных таблиц .

Что касается ваших 4 вопросов, я предварительно говорю «нет» каждому.

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

AWS и т. Д. Обеспечивают высокую надежность и считывание масштабирование. Но, повторяю, вероятнее всего, вам стоит поискать медленные запросы, а не различные идеи, которые вы представили.

Что касается периодического усечения, давайте обсудим это, посмотрев, как выглядят данные и каковы бизнес-требования для хранения данных.

...