Выбор базы данных для большого объема данных?

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

Число таблиц не будет большим (< 15), большинство данных (99%) будет содержаться в одной большой таблице, которая почти вставляется/читается (без обновлений).

Предполагаемый объем данных в этой таблице будет расти на 500 000 записей в день, и мы должны сохранить как минимум 1 год, чтобы они могли делать различные отчеты.

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

У меня нет первого опыта работы с этими большими базами данных, поэтому я прошу те, у которых в этой ситуации лучший выбор для БД. Я знаю, что Oracle - безопасная ставка, но мне больше интересно, если у кого-то есть опыт работы с Postgresql или Mysql с аналогичной настройкой.

Ответ 1

Я использовал PostgreSQL в среде, где мы видим 100K-2M новых строк в день, большинство из которых добавлено в одну таблицу. Тем не менее, эти строки, как правило, сводятся к образцам, а затем удаляются в течение нескольких дней, поэтому я не могу говорить о долгосрочной эффективности с более чем 100 М строк.

Я обнаружил, что производительность вставки вполне разумна, особенно если вы используете объемную копию. Производительность запроса - это хорошо, хотя выбор, который планировщик иногда вызывает у меня головоломку; особенно при выполнении JOIN/EXISTS. Наша база данных требует довольно регулярного обслуживания (VACUUM/ANALYZE) для бесперебойной работы. Я мог бы избежать некоторых из этого, более тщательно оптимизируя autovacuum и другие настройки, и это не так много, если вы не делаете много DELETE. В целом, есть некоторые области, где мне становится сложнее настраивать и поддерживать, чем должно быть.

Я не использовал Oracle и MySQL только для небольших наборов данных, поэтому я не могу сравнивать производительность. Но PostgreSQL отлично работает для больших наборов данных.

Ответ 2

У вас есть копия " Набор инструментов хранилища данных"?

Предлагается сделать следующее.

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

Ответ 3

Некоторые интересные моменты в Google BigTable есть...

Bigtable Vs DBMS

Быстрая скорость запроса
Нет объединений, поддержка SQL, база данных, ориентированная на столбцы
Использует один Bigtable вместо того, чтобы иметь много нормализованных таблиц
Даже не в 1NF в традиционном представлении
Предназначен для поддержки исторического запроса timestamp field = > что вчера выглядела эта веб-страница?
Сжатие данных проще - носки разрежены

Я выделил поддержку Joins and No SQL Support, о которой вы говорили, вам нужно будет запустить серию отчетов. Я не знаю, сколько (если таковые имеются), не имеющие возможности для этого, будут иметь на вас отчеты о работе, если вы используете это.

Ответ 4

Объем данных (200 миллионов записей в год) не очень большой и должен идти с любым стандартным движком базы данных.

Дело еще проще, если вам не нужны живые отчеты. Я бы зеркалировал и преагрегировал данные на каком-то другом сервере, например. ежедневная партия. Как предположил С.Лотт, вы можете прочитать информацию о хранилище данных.

Ответ 5

Google База данных BigTable и Hadoop - это два которые могут обрабатывать большой объем данных.

Ответ 6

Мы используем Firebird для действительно огромной базы данных (сохраняя данные уже более 30 лет), и она очень хорошо масштабируется.

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