Хранить огромные данные в MySQL?

Question

Я пытаюсь создать таблицу БД в MySQL для хранения данных статистики моего продукта.Статистика почти каждого дня должна быть в базе данных.Проблема в скорости.

В настоящее время я сохраняю для каждого продукта следующие значения: ВРЕМЯ, ПРОДАННЫЙ ПУНКТ, PRODUCT_ID, HIT, OTHER_ID

Я думал о двух разных способах хранения данных:

• День за днем ​​для каждого продукта подряд (сериализуется)
• Год за годом для каждого продукта подряд (сериализуется)

или ваши идеи?

Скоростные тесты, которые я сделал не так плохо, почти хорошо.Но у вас есть лучшие идеи или опыт по этому вопросу?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Может возникнуть проблема со скоростью:

• когда вы вставляете данные в базу данных
• когда вы запрашиваете базу данных (т. е. из веб-приложения)

Если ваша база данных выделена для статистики, то это нормально, чтобы начать создавать отчетывы хотите производить;таким образом вы можете определить:

• данные, которые нужно вставить в базу данных
• запросы, которые вы собираетесь выполнить к базе данных

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

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

Как заполнить базу данных данными

1. Во-первых, у вас, вероятно, большой и подробный объем данных, например, строка, описывающая покупку.Начните находить размеры , которые действительно полезны в вашем отчете;измерение - это мера, которая вас волнует, например, что вы продали, когда , кто первоначально продал его.
2. Для каждого измерениянайдите наименьший уровень детализации, который вы хотите использовать в своем отчете: вас интересует час покупки или только год?Вас волнует категория проданного продукта или только его SKU?

Это сообщит вам данные, которые вы должны перенести из исходной базы данных в статистику.

Как регулярно обновлять данные

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

Примечания

1. Всякий раз, когда оригиналБаза данных изменяется в своей схеме или, более тонко, в том, как она хранит данные, вы должны учитывать, как эти изменения влияют на вашу процедуру обновления (триггеры или внешний скрипт)
2. Если ваша статистика взаимодействует (например,из веб-приложения), я бы предложил использовать Кубы данных для определения вашей базы данных.
3. Имейте в виду, что вы не можете легко сортировать, выбирать или группировать сериализованные данные.