Проектирование баз данных для тяжелой синхронизированной регистрации данных

Во-первых, огромные объемы данных не всегда хорошо обрабатываются в реляционной базе данных.

Некоторые люди помещают огромные наборы данных в файлы. Обычные старые файлы. Быстро обновляется, легко создавать резервные копии.

Файлы отформатированы так, чтобы массовая загрузка базы данных работала быстро.

Во-вторых, никто не анализирует огромные объемы данных. Они редко суммируют 5 000 000 строк. Обычно они хотят подмножество.

Итак, вы пишете простые фильтры файлов, чтобы вырезать их подмножество, загрузить это в «витрину данных» и позволить им запросить это. Вы можете построить все нужные им индексы. Просмотры, все.

Это один из способов справиться с «хранилищем данных», который заключается в том, что ваша проблема звучит так.

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

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

Сейчас у нас таблицы журналов по 100-200 миллионов строк, и это довольно болезненно.

• резервное копирование невозможно, требуется несколько дней простоя.

• очистка старых данных становится слишком болезненной - она обычно привязывает базу данных на несколько часов

Пока мы видели только следующие решения:

• резервное копирование, установка ведомого MySQL. Резервное копирование ведомого устройства не влияет на основную базу данных. (Мы еще не делали этого - поскольку журналы, которые мы загружаем и преобразуем, находятся в плоских файлах - мы создаем резервные копии этих файлов и можем регенерировать базу данных в случае сбоев)

• Очистка старых данных, единственный безболезненный способ, который мы нашли - это ввести новый целочисленный столбец, который определяет текущую дату, и разбить таблицы (требуется mysql 5.1) по этому ключу, по дням. Удаление старых данных сводится к удалению раздела, что происходит очень быстро.

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

Общий ответ: вероятно, вам не нужны все эти подробности постоянно.

Например, вместо того, чтобы хранить каждую продажу в гигантской таблице продаж, вы создаете записи в таблице DailySales (одна запись в день) или даже в группе таблиц (DailySalesByLocation = одна запись для каждого местоположения в день, DailySalesByProduct = одна. запись на продукт в день и т. д.)

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

CouchDB, MongoDB и Riak - это документо-ориентированные базы данных; они не имеют тяжеловесных функций SQL для создания отчетов, но если вы храните большой журнал, то они могут подойти, поскольку они проще и легче масштабируются, чем SQL-базы данных.

С ними немного проще начать работу, чем с Cassandra или HBase (другой тип NoSQL), которые вы также можете рассмотреть.

Из этого поста SO: http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/