Максимальное количество строк MySQL, прежде чем производительность серьезно ухудшается - PullRequest
Новая
       8

Максимальное количество строк MySQL, прежде чем производительность серьезно ухудшается

0 голосов
/ 24 августа 2018

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

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

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

Я покопался в документации MySQL, касающейся ограничений таблицы InnoDB (https://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html)), и определил, что верхний предел 64 ТБ в настоящее время не имеет значения.

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

Есть ли у кого-нибудь опыт или документация, которая помогла бы мне определить, сколько у нас есть времени, пока у нас не возникнет серьезная проблема с производительностью?

В настоящее время я беспокоюсь о следующих вещах:

  • В какой момент у нас возникнет проблема с продолжительными действиями вставок
  • Существует ли сценарий, при котором размер индекса становится слишком большим, что приведет к серьезным проблемам с производительностью
  • Есть ли другие проблемы с красным флагом, о которых мне следует беспокоиться?

Ответы [ 2 ]

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

Вероятные способы помочь:

  • Избегайте запросов, которые должны касаться большого количества строк.Подумайте об использовании «Сводных таблиц» для хранения ежедневных (или ежечасных, или любых других) промежуточных итогов.
  • 3 индексов является частью проблемы;Сводная таблица (таблицы) может помочь устранить некоторые из них.Но держите PRIMARY KEY.Различные индексы могут помочь.
  • Сократить типы данных для уменьшения числа операций ввода-вывода, следовательно, медленнее.
  • Если поля часто повторяются, нормализуйте и используйте JOINs;это может значительно помочь.

Вероятные способы не помочь:

  • Разделение не поможет, если через некоторое время вам не понадобится очистить «старые» данные.

Сколько времени до проблем?

  • Зависит от столбцов
  • Зависит от объема оперативной памяти
  • Зависит от сложности запросов
  • Зависит от других вещей.
  • INSERTs вряд ли будет проблематичным, если вы не используете UUID.
  • Но - сводные таблицы обычно могут откладывать катастрофу на длительное время - возможно, 10 раз как долго.

Подробности.Без более подробной информации, я не могу помочь вам больше.

  • SHOW CREATE TABLE
  • Некоторая статистика по скорости приема пищи и т. Д.
  • Типичные запросы
  • И т. Д.

Полезное правило ... Типичное InnoDB BTree (данные или индекс) имеет разветвление 100. То есть каждый узел имеет 100 «строк» ​​под ним.Следовательно, ваша таблица (вероятно) будет иметь глубину около 5 уровней.То же самое для индексов. Обычно глубина BTree составляет , а не , что критично для любого обсуждения производительности.

Полезное правило ... Установите для innodb_buffer_pool_size около 70% оперативной памяти.

0 голосов
/ 25 августа 2018

Когда обычно используемые части индекса (ов) больше не могут находиться в пуле буферов innodb, запросы начнут использовать намного больше ввода-вывода.

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

Так что в целом следите за соотношением Innodb_buffer_pool_read_requests и Innodb_buffer_pool_reads для переменных состояния, а когда оно начнет падать, рассмотрите больше ОЗУ.

...