Проектирование базы данных для регистрации больших объемов данных

Question

У меня есть приложение, в котором я получаю каждые 40 000 строк данных. У меня есть 5 миллионов строк для обработки (база данных MySQL 5.0 на 500 МБ).

На самом деле, эти строки хранятся в одной и той же таблице => медленное обновление, сложное резервное копирование и т. Д.

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

Для этой цели postgresql лучше mysql?

Answer 1

1 - 40000 строк / день не такой большой

2 - Разделите ваши данные по дате вставки: вы можете легко удалить старые данные таким образом.

3 - Не стесняйтесь пройти шаг datamart. (вычислить часто задаваемые показатели в промежуточных таблицах)

К вашему сведению, я использовал PostgreSQL с таблицами, содержащими несколько ГБ данных, без каких-либо проблем (и без разделения). Время вставки / обновления было постоянным

Answer 2

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

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

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

Пока мы видели только эти решения:

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

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

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

Answer 3

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

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

Answer 4

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

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

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

С это ТАК сообщение: http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/

Answer 5

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

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

Answer 6

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

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

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

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

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

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