Практические ограничения размера для RDBMS
Я работаю над проектом, который должен сохранить очень большие наборы данных и связанные справочные данные. Я никогда не сталкивался с проектом, который потребовал таблиц вполне это большое. Я доказал, что по крайней мере одна среда разработки не может справиться в уровне базы данных с обработкой, требуемой сложными запросами против представлений, что прикладной уровень генерирует (представления с несколькими внутренними и внешними объединениями, группировкой, подведением итогов и усреднением против таблиц с 90 миллионами строк).
RDBMS, против которого я протестировал, является DB2 на AIX. dev среда, которая перестала работать, была загружена 1/20-м из объема, который будет обработан в производстве. Меня уверяют, что производственные аппаратные средства превосходят dev и подготавливают аппаратные средства, но я просто не полагаю, что это справится с чистым объемом данных и сложностью запросов.
Прежде чем dev среда перестала работать, она брала сверх 5 минут для возврата небольшого набора данных (несколько сотен строк), который был произведен сложным запросом (много соединений, большая группировка, подведение итогов и усреднение) против больших таблиц.
Мое инстинктивное чувство состоит в том, что архитектура дб должна измениться так, чтобы агрегирования, в настоящее время обеспечиваемые представлениями, были выполнены как часть непиковой пакетной обработки.
Теперь для моего вопроса. Меня уверяют люди, которые утверждают, что имели опыт этого вида вещи (который я не делаю), что мои страхи необоснованны. Они? Может современный RDBMS (SQL Server 2008, Oracle, DB2) справляется с объемом и сложностью, которую я описал (данный ассигновать сумму в размере аппаратных средств) или являюсь нами в области технологий как BigTable Google?
Я надеюсь на ответы от людей, которые должны были на самом деле работать с этим видом объема на нетеоретическом уровне.
Природа данных является финансовыми транзакциями (даты, суммы, географические положения, компании), таким образом, почти все типы данных представлены. Все справочные данные нормализованы, следовательно несколько соединений.
5 ответов
Я работаю с несколькими базами данных SQL Server 2008, содержащими таблицы с миллиардными строками. Единственными реальными проблемами, с которыми мы столкнулись, были проблемы с дисковым пространством, временем резервного копирования и т. д. Запросы были (и остаются) всегда быстрыми, обычно в диапазоне < 1 секунды, никогда не превышая 15-30 секунд даже с тяжелыми соединениями, агрегациями и т.д.".
Реляционные системы баз данных определенно могут справиться с такой нагрузкой, а если один сервер или диск начинает работать с нагрузкой, то большинство высококлассных баз данных имеют решения по разделению.
Вы ничего не упомянули в своем вопросе о том, как индексируются данные, а в 9 случаях из 10, когда я слышу жалобы на производительность SQL, проблемой оказывается недостаточное/отсутствующее индексирование.
Самое первое, что вы всегда должны делать, когда видите медленный запрос, это поднять план выполнения. Если вы видите какие-либо полные сканирования индексов/таблиц, поиск строк и т.д., это указывает на недостаточное индексирование запроса или на то, что запрос написан так, что не может использовать преимущества покрывающих индексов. Неэффективные соединения (в основном вложенные циклы), как правило, являются вторым наиболее распространенным виновником, и это часто можно исправить с помощью переписывания запроса. Но без возможности увидеть план, все это лишь предположения.
Итак, основной ответ на ваш вопрос: да, реляционные системы баз данных вполне способны работать с такими масштабами, но если вы хотите получить что-то более подробное/полезное, то, возможно, вам стоит опубликовать пример схемы/тестового сценария или хотя бы план выполнения, чтобы мы могли посмотреть.
Если это только 1/20 ваших данных, вам почти наверняка нужно искать более масштабируемые и эффективные решения, такие как Google Big Table. Взгляните на NoSQL
. Я лично считаю, что MongoDB - отличное промежуточное звено между NoSQL и RDMS. Он не реляционный, но предоставляет гораздо больше возможностей, чем простое хранилище документов.
В многомерных (методология Кимбалла) моделях в нашем хранилище данных на SQL Server 2005 у нас регулярно есть таблицы фактов с таким количеством строк только в одном месячном разделе.
Некоторые вещи выполняются мгновенно, а некоторые требуют времени, это зависит от операции, количества объединяемых звезд и того, что происходит.
Те же модели плохо работают на Teradata, но, насколько я понимаю, если мы перемоделируем в 3NF, распараллеливание Teradata будет работать намного лучше. Установка Teradata во много раз дороже, чем установка SQL Server, поэтому она просто показывает, насколько важно моделирование различий и соответствие ваших данных и процессов базовому набору функций.
Не зная больше о ваших данных, о том, как они моделируются в настоящее время и какие варианты индексации вы сделали, трудно сказать что-либо еще.
Похоже, вы снова и снова вычисляете одни и те же данные на основе нормализованных данных. Один из способов ускорить обработку в подобных случаях - сохранить SQL с его хорошими отчетами, взаимосвязями, согласованностью и т. Д. И использовать куб OLAP , который вычисляется каждые x минут. По сути, вы регулярно строите большую таблицу денормализованных данных, которая позволяет быстро выполнять поиск. Реляционные данные обрабатываются как главные, но куб позволяет быстро извлекать заранее рассчитанные значения из базы данных в любой момент.
90 миллионов строк должны занимать около 90 ГБ, поэтому ваше узкое место - диск. Если вам нужны эти запросы редко, запустите их как есть.
Если вам часто нужны эти запросы, вы должны разделить свои данные и предварительно вычислить групповое суммирование и усреднение для той части ваших данных, которая не изменилась (или не изменилась с прошлого раза).
Например, если вы обрабатываете исторические данные за последние N лет до сегодняшнего дня включительно, вы можете обрабатывать их один месяц (или неделю, день) за раз и где-то хранить итоговые и средние значения. Затем во время запроса вам нужно будет повторно обработать период, который включает сегодняшний день.
Некоторые СУБД дают вам некоторый контроль над обновлением представлений (при выборе, при изменении источника, в автономном режиме), если сложное групповое суммирование и усреднение на самом деле достаточно просты для правильного понимания базы данных, теоретически это может, обновлять несколько строк в представлении при каждой вставке / обновлении / удалении в исходных таблицах в разумные сроки.