Стратегия для обработки больших наборов данных в сильно вставленных в таблицу - PullRequest
2 голосов
/ 31 июля 2010

У меня есть веб-приложение, которое имеет базу данных MySql с таблицей device_status, которая выглядит примерно так ...

deviceid | ... various status cols ... | created 

Эта таблица вставляется много раз в день (2000+ на устройство в день)(по оценкам, к концу года будет более 100 устройств))

По сути, эта таблица получает запись, когда на устройстве происходит практически что-либо.

Мой вопрос: как мне поступить?таблица, которая очень быстро станет очень большой?

  1. Стоит ли просто расслабиться и надеяться, что с базой данных все будет в порядке через несколько месяцев, когда в этой таблице будет более 10 миллионов строк?а потом через год когда у него 100 миллионов строк?Это самая простая, но кажется, что таблица такого большого размера будет иметь ужасную производительность.

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

  3. Если у меня есть часовая и / или дневная сводная таблица, которая суммируетразличные статусы для устройства?Если я сделаю это, каков наилучший способ вызвать агрегацию?Cron?БД Триггер?Также мне, вероятно, все еще нужно архивировать.

Должно быть более элегантное решение для обработки данных такого типа.

1 Ответ

1 голос
/ 31 июля 2010

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

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

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

...