Насколько большой слишком большой для таблицы MySQL?

Question

Я был окончательно убежден, что мои меньшие таблицы должны быть объединены в одну большую, но какой именно размер слишком велик для таблицы MySQL?

У меня есть таблица с 18 полями.Некоторые из них TEXT, некоторые короткие VARCHAR(16), другие более длинные VARCHAR(100).

Сейчас мы получаем около 200 000 строк в день, что составляет 6 миллионов + в месяц.Насколько большой слишком большой?Имеет ли значение, сколько у вас полей или только строк?

Answer 1

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

Есть некоторыефундаментальные ограничения на размеры стола.Вы не можете иметь более 1000 столбцов.Ваши записи не могут быть больше 8 КБ каждый.Эти ограничения меняются в зависимости от базы данных.(Это для InnoDB.)

Похоже, вы объединили несколько разных наборов данных в одну таблицу.Возможно, у вас есть несколько полей, которые сообщают вам, к какому набору данных относится эта запись, а также некоторые поля данных и некоторая информация о метках времени.Это не очень широкая запись (если вы не регистрируете, скажем, все входные параметры каждого запроса.) Ваша главная проблема будет с селективностью .Индексирование этой таблицы значимым образом будет проблемой.Если ваши общие поля могут быть достаточно избирательными, чтобы вы могли использовать их для доступа к нужным записям, не обращаясь к таблице, это будет огромным плюсом.(См. Таблицу сканирования)

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

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

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

Answer 2

У меня есть таблица с ~ 98M строк и вставки / удаления происходят в течение всего дня.Мы ведем записи в течение 90 дней ... Я ожидаю, что эта таблица будет ~ 100 миллионов строк в этом месяце.Лично я разработал бы схему базы данных по-другому, но она была приобретена, и мы должны сохранить ее нетронутой, чтобы мы не аннулировали поддержку любого поставщика.

Мы используем репликацию mysql (MASTER-MASTER) ивыполнение вставки / удаления на одном и выполнение запросов на другом.Это действительно помогло с производительностью, поскольку удаления блокировали бы таблицу и блокировали запросы, прежде чем мы переключились на использование репликации.

Мы не испытываем никаких проблем с производительностью при использовании этой реализации.

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

Answer 3

Я думаю, это зависит, в основном. Какую версию MySQL вы используете, какую ОС и используете ли вы таблицы MyISAM или innoDB? Он также отличается от 32-разрядного и 64-разрядного и зависит от настроек ведения журнала. Руководство MySQL гласит:

Эффективный максимальный размер стола для MySQL базы данных обычно определяется по ограничениям операционной системы на размеры файлов, а не внутренние MySQL Пределы

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

Answer 4

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

Я был в той же ситуации, когда объем данных не позволил мне изменитьСтруктура базы данных.Что вы должны сделать ПРЯМО СЕЙЧАС - попросить кого-нибудь создать базу данных на компьютере (например, экземпляр EC2) с объемом данных, который вы ожидаете получить за два года.Просто попросите их создать фиктивные данные в том же формате таблицы.Попробуйте поработать с этой таблицей и решить, является ли производительность приемлемой.Если это неприемлемо, вам нужно как можно скорее изменить ситуацию.

На вашем месте я бы рассмотрел тестирование Greenplum или (GridSQL, если у вас нет денег, чтобы тратить).Оба основаны на PostgreSQL и используют много компьютеров для совместной работы.

Answer 5

Не ответ на точный вопрос ...

Почему вы были убеждены, что ваши маленькие столы должны быть объединены в один большой? То, что вы делали, называется «вертикальное разбиение» и может быть очень полезным, в зависимости от вашей ситуации. Со многими большими полями TEXT или BLOB вертикальный раздел может физически хранить ваши запрашиваемые данные и быстрее получать к ним доступ.

См .: http://en.wikipedia.org/wiki/Partition_(database)

Вертикальное разбиение включает создание таблиц с меньшим количеством столбцов и использование дополнительных таблиц для хранения оставшихся столбцов. Нормализация также включает в себя это разделение столбцов по таблицам, но вертикальное разделение выходит за рамки этого и разделяет столбцы, даже если они уже нормализованы. Различное физическое хранилище может быть использовано для реализации вертикального разделения; хранение редко используемых или очень широких столбцов на другом устройстве, например, является методом вертикального разделения. Сделанный явно или неявно, этот тип разделения называется «разделением строк» ​​(строка разделяется по столбцам). Распространенной формой вертикального разделения является разделение (медленное нахождение) динамических данных (быстрое нахождение) статических данных в таблице, где динамические данные используются не так часто, как статические. Создание представления для двух вновь созданных таблиц восстанавливает исходную таблицу с ухудшением производительности, однако производительность будет увеличиваться при доступе к статическим данным, например. для статистического анализа

Смотри также: http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

Answer 6

Выбор количества столбцов в одной таблице также зависит от типа представляемых данных и от того, насколько вы заботитесь о нормализации.Некоторые отношения могут быть легко представлены одной таблицей;другие должны выполняться в нескольких небольших таблицах, особенно если в вашем наборе данных есть сочетание типов типа «один к одному», «один ко многим» и «многие ко многим».http://en.wikipedia.org/wiki/Database_normalization