Оптимизация скорости MySQL для таблицы с множеством строк: как лучше всего справиться с этим?

Question

Я разрабатываю приложение для чата. Я хочу, чтобы все записывалось в таблицу (т. Е. Кто сказал, что и когда). Надеюсь, что в ближайшее время у меня будут тысячи строк. Мне было интересно: как лучше оптимизировать таблицу, зная, что я буду часто вставлять строки, а иногда и читать в группах (т.е. показывать весь разговор от пользователя (посмотрите, когда он / она вошел в систему / начал общаться, затем посмотрите когда он / она уйдет, покажите весь разговор)).

Эта таблица должна обрабатывать (хотя я надеюсь!) Много строк. (15000 / день => 4,5 млн. В месяц => 54 млн. Строк на конец года).

Разговоры старше 15 дней могут быть внесены в историю (но я не знаю, как мне поступить, чтобы сделать это правильно).

Есть идеи?

Answer 1

У меня есть два совета для вас:

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

Answer 2

Mysql на удивление хорошо справляется с очень большими наборами данных, чуть больше, чем стандартная настройка базы данных и индексы. Я запустил сайт с миллионами строк в базе данных и смог нормально запустить его на mysql.

Mysql имеет опцию «архивный» механизм обработки таблиц для обработки множества строк, но отсутствие поддержки индекса делает его не лучшим вариантом для вас, за исключением, возможно, исторических данных.

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

Если вы просто запрашиваете свой «пользовательский» столбец идентификатора, с индексом проблем не возникнет, но если вы хотите выполнять полнотекстовые запросы к сообщениям, вы можете рассмотреть возможность только индексирования пользовательского столбца. в mysql и использовании чего-то вроде sphynx или lucene для полнотекстового поиска, поскольку полнотекстовый поиск в mysql не самый быстрый и значительно замедляет время вставки.

Answer 3

54 миллиона строк - это не так много, особенно за год.

Если вы собираетесь периодически выводить много данных, я бы порекомендовал использовать таблицы MyISAM и MERGE. Поскольку вы не будете удалять или редактировать записи, у вас не будет проблем с блокировкой, если для параллелизма задано значение 1. Вставки всегда будут добавляться в конец таблицы, поэтому операции SELECT и INSERT могут происходить одновременно. Поэтому вам не нужно использовать таблицы на основе InnoDB (которые могут использовать таблицы MERGE).

У вас может быть 1 таблица в месяц, которая будет называться как data200905, data200904 и т. Д. Ваша таблица слияния будет включать все базовые таблицы, по которым вам нужно искать. Вставки выполняются в таблице слияния, поэтому вам не нужно беспокоиться об изменении имен. Когда пришло время свернуть данные и создать новую таблицу, просто повторно объявите таблицу MERGE.

Можно даже создать несколько таблиц MERGE на основе квартала, года и т. Д. Одна таблица может использоваться в нескольких таблицах MERGE.

Я сделал эту настройку для баз данных, которые добавляли 30 миллионов записей в месяц.

Answer 4

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

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

Для запросов типа "что сказал x в прошлом месяце" вы будете запрашивать таблицу архива, и это займет немного больше времени, но это нормально, поскольку таких запросов будет не так много, и если кто-то выполнит поиск вот так он будет готов подождать еще пару секунд.

В зависимости от ваших вариантов использования вы можете расширить этот принцип - если в течение последних 6 месяцев будет много запросов к сообщениям чата - сохраняйте их также в отдельной таблице.

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