Выбор базы данных для большого объема данных? - PullRequest
40 голосов
/ 10 марта 2009

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

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

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

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

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

Ответы [ 6 ]

27 голосов
/ 10 марта 2009

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

Я обнаружил, что производительность вставки вполне приемлема, особенно если вы используете массовую копию. Производительность запросов хорошая, хотя выбор, который делает планировщик, иногда озадачивает меня; особенно при выполнении СОЕДИНЕНИЙ / СУЩЕСТВ. Наша база данных требует довольно регулярного обслуживания (VACUUM / ANALYZE), чтобы обеспечить ее бесперебойную работу. Я мог бы избежать этого, более тщательно оптимизировав автовакуум и другие настройки, и это не такая большая проблема, если вы не делаете много УДАЛЕНИЙ. В целом, в некоторых областях мне кажется, что его сложнее настроить и поддерживать, чем следует.

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

8 голосов
/ 10 марта 2009

У вас есть копия " The Warehouse Toolkit "?

Есть предложение сделать следующее.

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

  2. Сохраняйте факты в простых простых файлах, пока не захотите создавать отчеты в стиле SQL. Не создавайте и не создавайте резервную копию базы данных. Создавать и резервировать файлы; загружать базу данных только для отчетов, которые вы должны делать из SQL.

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

6 голосов
/ 10 марта 2009

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

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

6 голосов
/ 10 марта 2009

Здесь есть несколько интересных моментов, касающихся Google BigTable ...

Bigtable Vs СУБД

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

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

6 голосов
/ 10 марта 2009

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

5 голосов
/ 10 марта 2009

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

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

...