Нужен совет по дизайну базы данных

Question

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

Я вставляю в одну таблицу ~ 2 миллиона строк каждый день, затем эти таблицы ежемесячно архивируются и сжимаются. Каждая месячная таблица содержит ~ 15 000 000 строк. Хотя это увеличивается месяц за месяцем.

Для каждой вставки, которую я делаю выше, я объединяю данные из строк, которые принадлежат друг другу, и создаю другую "коррелированную" таблицу. Эта таблица в настоящее время не архивируется, так как мне нужно убедиться, что я никогда не пропущу обновление коррелированной таблицы. (Надеюсь, это имеет смысл) Хотя в целом эта информация должна оставаться довольно статичной после нескольких дней обработки.

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

Так что я думаю, после всего вышесказанного мой вопрос довольно прост. Должен ли я написать скрипт, который группирует данные из моей коррелированной таблицы в меньшие таблицы. Или я должен хранить наборы результатов запросов в нечто вроде memcache? Я уже использую кеш mysqls, но из-за ограниченного контроля над тем, как долго хранятся данные, он не работает идеально.

Основные преимущества использования Memcache:

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

Основные недостатки, которые я вижу при использовании чего-то вроде memcache:

• Данные не являются постоянными, если компьютер перезагружен / кэш очищен.

Основные преимущества использования MySql

• Постоянные данные.
• Меньше изменений кода (хотя добавление что-то вроде memcache тривиально в любом случае)

Основные недостатки использования MySql

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

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

Большое спасибо.

Alan

Answer 1

Помимо вариантов, которые вы обсуждали выше, вы также можете рассмотреть возможность добавления более мощного оборудования на изображение, если это вариант.

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

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

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

Просто мысль!

Answer 2

Я работаю в компании с похожей ситуацией, с миллионами вставок ежемесячно.

Мы приняли стратегию обобщения данных в меньшие таблицы, сгруппированные по определенным полям.

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

Время от времени мы перемещаем самые старые строки в таблицу резервных копий, уменьшая прирост основной таблицы.

Answer 3

Если вы хотите провести некоторый анализ статических данных за несколько дней назад, вам, возможно, следует подумать об использовании чего-то вроде системы OLAP.

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

Я думаю, что ваш вопрос - прекрасный пример ситуации, в которой он используется, но, возможно, я так думаю только потому, что это моя работа. =)

Взгляните.

Answer 4

(еще один ответ от меня, достаточно другой, чтобы я выложил его отдельно)

Два вопроса:

Какую статистику хочет получить ваша компания?
и
После того, как строки вставлены в базу данных, они когда-либо изменяются?

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

например. такие вещи, как:

• Когда вставляется новая строка, соответствующая статистике «B», идите и увеличивайте число в другой таблице для статистики «B», минута «Y»
  или
• Каждый час запускается небольшой запрос по строкам, вставленным за последний час, который генерирует статистику за этот час и сохраняет их отдельно
  или
• Как указано выше, но каждую минуту и ​​т. Д.

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