Масштабирование базы данных MS SQL Server 2008

Question

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

То, как таблица в настоящее время:

cache_id - int - идентификатор
cache_name - nvchar 256 - используется для поиска вместе с event_id
cache_event_id - int - Основной способ группировки
cache_creation_date - datetime
cache_data - varbinary (MAX) - размер данных будет от 2k до 5k

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

Я вижу разные способы хранения:
1) 1 большая таблица, она будет содержать десятки миллионов записей и легко станет размером в несколько гигабайт.
2) Несколько таблиц, которые содержат данные выше, то есть каждая таблица будет содержать от 200 000 до миллиона записей.

Данные из этой таблицы будут использоваться для отображения веб-страниц, поэтому любые данные, превышающие 200 мс для получения записи, являются плохими в моих глазах (я знаю, что некоторые люди считают, что загрузка страницы занимает 1-2 секунды, но я думаю, что это медленно и хочу сделать все возможное, чтобы держать его ниже).

Итак, все сводится к тому, что замедляет работу SQL-сервера?
Это размер таблицы (дискового пространства)
Количество строк
В какой момент перестает быть экономически эффективным использование нескольких серверов баз данных?


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

Answer 1

So it boils down to, what is it that slows down the SQL server?
Is it the size of the table ( disk space )
Is the the number of rows
At what point does it stop becoming cost effective to use multiple 
       database servers?

Это все «правило большого пальца»; Нагрузка (и, следовательно, в значительной степени производительность) БД в значительной степени влияет на объем данных и нагрузку на транзакции в 2 раза, при этом ИМХО, как правило, более актуально.

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

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

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

Answer 2

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

Проверьте все ваши догадки, сравните результаты и посмотрите, что работает. И продолжайте искать более проверяемые идеи. (И не бойтесь отвергать изменения, которые в конечном итоге не помогают. Это основное требование - иметь надежду на постоянную простоту.)

И принять тот факт, что ваш дизайн базы данных будет развиваться. Это не так страшно, как ваш комментарий предполагает, что вы так думаете. Изменить базу данных гораздо проще, чем программное обеспечение, которое ее использует.

Answer 3

Нормализовать и индексировать.

Как, мы не можем вам сказать, потому что вы не сказали использовать то, что ваш стол пытается моделировать или как вы пытаетесь использовать его.

1 миллион строк совсем не редкость. Опять же, мы не можем вам многое рассказать в отсутствие контекста, только вы можете, но не можете предоставить.