Практические ограничения базы данных SQL-сервера

Question

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

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

При каком размере у меня начнутся проблемы с производительностью sql-сервера? Я видел упоминание о системах vldb, но также слышал, что они могут быть настоящей болью. Есть ли порог, где я должен начать смотреть на это? Есть ли лучший дБ, чем sql-сервер, который предназначен для такого рода вещей?

Answer 1

Говоря о скорости транзакций более 10 кбит / с, вы не должны спрашивать совета на форумах ... Это близко к тестам производительности TPC-C по 32 и 64 способам, которые для настройки требуют миллионов.

В каком размере вы будете сталкиваться с проблемами?

При хорошей модели данных и проектировании схемы, правильно настроенный и запланированный сервер с правильной мощностью не столкнется с проблемами в течение 1 млрд. записей в день. Последние опубликованные тесты SQL Server составляют около 1,2 млн. Тран / мин. Это примерно 16 000 транзакций в секунду при цене системы в 6 миллионов долларов США в 2005 году (64-способный Superdome). Чтобы достичь 10 тыс. Тран / сек для запланированной нагрузки, вам не понадобится Superdome, но вам понадобится довольно мощная система (вероятно, по крайней мере, с 16 путями) и особенно очень очень хороший подсистема ввода / вывода. При обратном планировании емкости конверта обычно учитывают около 1 Кбит / с на HBA и 4 ядра процессора для питания HBA. И вам понадобится немало клиентов баз данных (промежуточные уровни приложения), чтобы накормить 1 билл. записей в день в базу данных. Я не утверждаю, что я занимался планированием ваших возможностей здесь, но я просто хотел дать вам пример того, о чем мы говорим. Это многомиллионный проект, и что-то в этом роде не предназначено для советов на форумах.

Answer 2

Если вы не говорите так, как крупный индекс Google, базы данных Enterprise, такие как SQL Server или Oracle, будут в порядке.

Джеймс Девлин из Coding the Wheel подвел итог: (хотя это скорее сравнение между бесплатными БД, такими как MySQL, с Oracle / SQL Server

В настоящее время мне нравится думать о SQL Server и Oracle как о «Звездах смерти» вселенной реляционных баз данных. Чрезвычайно мощный. Монолитный. Brilliant. Сложный почти за пределами способности одного человеческого разума понять. И это огромная трата денег, кроме тех редких ситуаций, когда вам действительно нужно уничтожить планету.

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

В случае с чем-то вроде индекса Google, читаемого в «Большой таблице», очень интересно, как Google настроил его на использование кластеров серверов для обработки поиска по огромным объемам данных в течение простых миллисекунд.

Answer 3

Это может быть сделано, но, учитывая ваши аппаратные затраты и планы, заставьте MS позаботиться о вас. Это будет часть ваших расходов на HW.

Сказав это, Пол Нильсон написал около 35 тыс. TPS (3 миллиарда строк в день) 2 года назад. Комментарии, которые стоит прочитать, также отражают то, что сказал Ремус

Answer 4

Размер самой базы данных не создает проблемы с производительностью. Практические проблемы с размером базы данных связаны с проблемами эксплуатации / обслуживания.

Например:

1. Удаление фрагментов и перестроение индексов занимает слишком много времени.
2. Резервное копирование занимает слишком много времени или занимает слишком много места.
3. Восстановление базы данных не может быть выполнено достаточно быстро в случае сбоя.
4. Будущие изменения в таблицах базы данных потребуют слишком много времени.

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

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

Кроме того, обязательно учитывайте размеры файлов журнала транзакций.