Обработка больших баз данных

Question

Я работаю в веб-проекте (asp.net) около шести месяцев. Конечный продукт готовится к запуску. Проект использует SQL Server в качестве базы данных. Мы провели тестирование производительности с некоторыми большими объемами данных, результаты показывают, что производительность снижается, когда данные становятся слишком большими, например, 2 миллиона строк (проблемы тайм-аута, задержка ответов и т. Д.). Сначала мы использовали полностью нормализованную базу данных, но теперь мы сделали ее частично нормализованной из-за проблем с производительностью (чтобы уменьшить количество соединений). Прежде всего, это правильное решение? Плюс какие возможные решения, когда размер данных становится очень большим, как нет. клиентов увеличится в будущем?

Я хотел бы добавить:

• 2 миллиона строк - это таблицы сущностей, таблицы, разрешающие отношения, имеют строки намного большего размера.
• Производительность ухудшается, когда данные + нет. пользователей увеличивается.
• Денормализация была сделана после выявления часто используемых запросов.
• Мы также используем большое количество столбцов xml и xquery. Может ли это быть причиной?
• Немного не в тему, некоторые люди в моем проекте говорят, что динамический SQL-запрос быстрее, чем подход с использованием хранимых процедур. Они провели какое-то тестирование производительности, чтобы доказать свою точку зрения. Я думаю, что наоборот. Некоторые из наиболее часто используемых запросов создаются динамически, тогда как большинство других запросов заключено в хранимые процедуры.

Answer 1

После анализа индексов и запросов вы можете захотеть просто использовать больше оборудования. Еще несколько концертов ОЗУ могли бы сработать.

Answer 2

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

Что нужно проверить:

Тупики

• Все ли процессы обращаются к таблицам в одинаковом порядке?

Медлительность

• Какие-либо запросы выполняют сканирование таблиц?
  • Проверка на наличие больших объединений (более 4 таблиц)
  • Проверьте свои индексы

Смотрите мои другие посты с общими советами по производительности:

• Как оптимизировать таблицы для конкретных запросов?
• Любимые приемы настройки производительности

Answer 3

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

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

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

НО НЕ ДО вы проверили свои стратегии индексирования и статистики таблиц.
Убедитесь, что вы используете разумные, хорошо структурированные запросы и что ваши объединения правильно сформированы. Проверьте планы запросов, чтобы ваши запросы действительно обрабатывались так, как вы ожидаете.

Как уже говорили другие, SQL Profiler / Database Engine Tuning Advisor действительно хорошо справляются с этой задачей.

Для меня денормализация обычно находится внизу моего списка дел.

Если проблемы не устранены, проверьте настройки программного и аппаратного обеспечения сервера.

• Ваша база данных и файлы журналов включены отдельные физические диски с использованием отдельные контроллеры?
• Есть ли у него достаточно памяти?
• Установлен ли файл журнала автогроу? Если это так, то автогров предел до низкого уровня, т.е. часто.

Answer 4

Мы всегда старались разрабатывать, используя базу данных, максимально приближенную к «реальному миру». Таким образом, вы избегаете многих подобных ошибок, поскольку любой старый разработчик сходит с ума, если время его подключения истекло во время отладки. Лучший способ отладить проблемы производительности Sql IMO - это то, что предлагает Митч Уит; профиль, чтобы найти оскорбительные сценарии и начать с них. Оптимизация сценариев может увести вас далеко, а затем вам нужно взглянуть на индексы. Также убедитесь, что ваш сервер Sql обладает достаточной мощностью, особенно важен IO (диск). И не забывай; кеш это король. Память дешева; купить больше. :)