Необходима консультация по проектированию базы данных

Question

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

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

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

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

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

Основные преимущества я могу видеть использовать что-то вроде кэша памяти:

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

Основные недостатки я вижу использовать что-то вроде кэша памяти:

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

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

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

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

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

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

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

Алан

Answer 1

Помимо опций, которые обсуждаются выше, вы также можете рассмотреть вопрос о добавлении более мощные аппаратные средства в картину, если тот вариант.

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

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

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

Просто подумайте!

Answer 2

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

Два вопроса:

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

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

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

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

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

Answer 3

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

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

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

Посмотрите.

Answer 4

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

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

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

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