mysql - Создание производительности строк и столбцов

Question

Я построил аналитический движок, который извлекает из моей базы данных 50-100 строк необработанных данных (назовем это raw_table), выполняет кучу статистических измерений на нем в PHP, а затем предлагает ровно 140 точек данных, которые мне тогда нужны хранить в другой таблице (назовем это results_table). Все эти точки данных представляют собой очень маленькие целые числа («40», «2.23», «- 1024» являются хорошими примерами типов данных).

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

Итак, несколько вопросов о лучших методах работы:

1) Если точнее, 140 точек данных можно разбить на 20 строк по 7 точек данных с одинаковым «experiment_id», если меньше столбцов лучше. ОДНАКО мне всегда нужно вытягивать ВСЕ 20 строк (по 7 столбцов в каждом, плюс идентификатор и т. Д.), Поэтому я не думаю, что это будет лучшей производительностью, чем вытягивание 1 строки из 140 столбцов. Таким образом, вопрос: лучше ли хранить 20 строк по 7-9 столбцов (которые все должны быть извлечены сразу) или 1 ряд из 140-143 столбцов?

2) Учитывая мои примеры данных («40», «2.23», «- 1024» являются хорошими примерами того, что будет сохранено), я думаю smallint для типа структуры. Есть ли какие-либо отзывы, связанные с производительностью или нет?

3) Любые другие отзывы о проблемах производительности MySQL или советы приветствуются.

Заранее спасибо за ваш вклад.

Answer 1

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

Кроме того, если 140 столбцов имеют одинаковое значение или если они различаются в эксперименте- правильное моделирование данных в соответствии с правилами нормализации, т. е. как данные связаны с ключом-кандидатом.

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

Если у вас много NULL, возможно, удастся исключить строки в нормализованном проектеи это сэкономит место.Я не знаю, есть ли в MySQL поддержка концепции разреженных таблиц, которая могла бы там сыграть.

Answer 2

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

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

Эти очень широкие строки займут больше места в вашем innodb_buffer_pool, поэтому вы не сможете кэшировать так много;это потенциально замедлит вас при повторном доступе к ним.

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

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

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

Answer 3

У вас есть 140 элементов данных для возврата каждый раз, каждый из которых типа double.

Нет никакой практической разницы, будет ли это 1x140 или 20x7, или 7x20, или 4x35 и т. Д. Это может быть бесконечно быстрее для одной формы курса, но затем вы рассмотрели дополнительную сложность в PHPкод для работы с другой формой.

У вас есть подтвержденное узкое место, или это просто случайная преждевременная оптимизация?