Практические ограничения по размеру для РСУБД

Question

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

СУБД, с которой я тестировал, - это DB2 в AIX.Неудачная среда разработки была загружена с 1/20 тома, который будет обработан в производственном процессе.Я уверен, что производственное оборудование превосходит аппаратное и промежуточное оборудование, но я просто не верю, что оно справится с огромным объемом данных и сложностью запросов.

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

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

Теперь на мой вопрос.Люди, которые утверждают, что имеют опыт такого рода вещей (а я нет), уверены, что мои опасения необоснованны.Они?Может ли современная СУБД (SQL Server 2008, Oracle, DB2) справиться с объемом и сложностью, которую я описал (учитывая соответствующее количество оборудования), или мы находимся в сфере технологий, таких как Google BigTable?

I 'Я надеюсь получить ответы от людей, которым фактически приходилось работать с таким объемом на не теоретическом уровне.

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

Answer 1

Я работаю с несколькими базами данных SQL Server 2008, содержащими таблицы с нумерацией строк в миллиардах. Единственными реальными проблемами, с которыми мы столкнулись, были проблемы с дисковым пространством, временем резервного копирования и т. Д. Запросы были (и остаются) всегда быстрыми, обычно в диапазоне <1 секунды, никогда не превышали 15-30 секунд, даже при тяжелых объединениях, агрегациях и и так далее. </p>

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

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

Самое первое, что вы всегда должны делать, когда видите медленный запрос, это подтянуть план выполнения. Если вы видите какое-либо полное сканирование индекса / таблицы, поиск строк и т. Д., Что указывает на неадекватную индексацию вашего запроса или запрос, который написан так, чтобы не использовать преимущества покрытия индексов. Неэффективные объединения (в основном вложенные циклы), как правило, являются вторым наиболее распространенным виновником, и часто это можно исправить с помощью переписывания запроса. Но не имея возможности увидеть план, это всего лишь домыслы.

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

Answer 2

90 миллионов строк должны составлять около 90 ГБ, поэтому узким местом является диск.Если вам нужны эти запросы редко, запускайте их как есть.

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

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

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

Answer 3

Похоже, вы снова и снова рассчитываете одни и те же данные из нормализованных данных.Один из способов ускорить обработку в подобных случаях - это поддерживать SQL с его хорошими отчетами, взаимосвязями, согласованностью и т. Д. И использовать OLAP Cube , который рассчитывается каждые x минутПо сути, вы регулярно строите большую таблицу денормализованных данных, что позволяет быстро выполнять поиск.Реляционные данные обрабатываются как основные, но куб позволяет быстро извлекать предварительно рассчитанные значения из базы данных в любой точке.

Answer 4

В многомерных (методология Кимбалла) моделях в нашем хранилище данных на SQL Server 2005 у нас регулярно имеются таблицы фактов с таким количеством строк только в одном месячном разделе.

Некоторые вещи происходят мгновенно, а некоторые занимают время, это зависит от операции, от того, сколько звезд объединяется и что происходит.

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

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

Answer 5

Если это только 1/20 ваших данных, вам почти наверняка нужно искать более масштабируемые и эффективные решения, такие как Google Big Table.Взгляните на NoSQL

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