Какая база данных (СУБД) может лучше всего обрабатывать большие таблицы?

Question

У меня также есть очень большая таблица в SQL Server (2008 R2 Developer Edition), которая имеет некоторые проблемы с производительностью.

Мне было интересно, будет ли другая СУБД лучше работать с большимистолы.Я в основном рассматриваю только следующие системы: SQL Server 2008, MySQL и PostgreSQL 9.0.

Или, как указано в приведенном выше вопросе, размер таблицы и производительность в основном зависят от индексов и кэширования?

Кроме того, улучшит ли нормализация производительность или помешает ей?

Редактировать:

В одном из комментариев ниже утверждается, что я был расплывчатым.У меня более 20 миллионов строк (данные о запасах за 20 лет и данные о вариантах за 2 года), и я пытаюсь выяснить, как повысить производительность на порядок.Я забочусь только о производительности чтения / вычисления;Меня не волнует производительность записи.Единственные записи выполняются при обновлении данных, и это BulkCopy.

У меня уже есть некоторые индексы, но, надеюсь, я делаю что-то не так, потому что мне нужно сильно ускорить процесс.Мне тоже нужно начать смотреть на мои запросы.

Предоставленные комментарии и ответы уже помогли мне понять, как начать профилирование моей базы данных.Я программист, а не администратор баз данных (поэтому Рекомендация по книге Марко идеальна ).У меня нет такого большого опыта работы с базами данных, и я никогда не профилировал базу данных раньше.Я попробую эти предложения и сообщу в случае необходимости.Спасибо!

Answer 1

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

Я предлагаю вам прочитать Рефакторинг приложений SQL , потому что это решает проблему не с "тюнера БД", а с точки зрения разработчика.

Книга автора книги «Искусство SQL», в которой сравниваются Oracle, SQL Server и MySQL по многим сценариям. Это прагматично и содержит несколько полезных графиков.

Я бы держался подальше от MySQL, если не заставлял. Postgres 9.0 работает в соответствии с несколькими определениями «скалы», но я все равно буду использовать 8.4 в производстве в течение нескольких месяцев.

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

Answer 2

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

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

Извините, ярлыков на самом деле нет.

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

Answer 3

Переключение СУБД не является решением.

Насколько велика?Какие у него индексы?

Если он действительно такой большой, то можете ли вы его разбить?

Answer 4

Только что видел это. Вы должны проверить infobright.org. Для числовых расчетов это здорово. Он предоставляет ядро ​​базы данных для mysql, но построено для анализа, а не для обновления транзакций.

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

Answer 5

Я думаю, что Simpledb это выбор.Учитывая, что amazon использует его для своей платформы.

Answer 6

Два продукта БД, которым большинство действительно крупных компаний, банков, военных и правительств доверяют огромные объемы данных: Oracle и DB2 .Оба идут с соответственно жирными ценниками.Оба продукта имеют десятилетия интенсивной профессиональной настройки, хотя зачастую преимущества доступны только для людей, которые оплачивают (дополнительно!) Оплату услуг для опытных консультантов.У меня есть друг, который является таким консультантом DB2;он заряжает руку и ногу, но достигает удивительного прироста производительности с мерами, которые другие люди не примут во внимание.

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