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

Question

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

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

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

Answer 1

В схеме вещей несколько миллионов строк не являются особо большой базой данных.

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

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

Я собираюсь выйти на конечность здесь (потому что это обычно так), но я был бы удивлен, если бы ваша проблема тоже не была

1. Отсутствие «правильных» покрывающих индексов для дорогостоящих запросов
2. Плохо настроен или находится под указанной дисковой подсистемой

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

Answer 2

Как гласит старая поговорка: "нормализуйся, пока не болит, денормируй, пока не заработай".

Я люблю это! Обычно это такие вещи, которые больше не должны приниматься. Я могу себе представить, что когда-то DBASEIII раз, когда вы не могли открыть более 4-х таблиц одновременно (если только не изменили некоторые параметры AUTOEXEC.BAT И не перезагрузили компьютер, ахах! в денормализации.

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

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

Answer 3

2 миллиона строк, как правило, не очень большая база данных, в зависимости от того, какую информацию вы храните. Обычно, когда производительность снижается, вы должны проверить свою стратегию индексирования. Там может помочь помощник по настройке ядра СУБД SQL Server.

Answer 4

Для этого может быть миллион причин; используйте SQL Profiler и Query анализатор, чтобы определить , почему ваши запросы замедляются, прежде чем идти по пути изменения схемы. Весьма вероятно, что все, что вам нужно сделать, это создать пару индексов и запланировать «обновление статистики» ... ... но, как я уже сказал, Profiler и Query Analyzer - лучшие инструменты для выяснения того, что происходит .. .

Answer 5

• Сначала убедитесь, что ваша база данных достаточно работоспособна, запустите на ней DBCC DBREINDEX, если это возможно, DBCC INDEXDEFRAG и обновите статистику, если вы не можете позволить себе снижение производительности.

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

• Теперь, когда у вас есть самые длинные запросы, настройте сопли на них; найдите те, которые отображаются чаще всего, посмотрите планы выполнения в Query Analyzer, найдите время, чтобы их понять, добавьте индексы, где это необходимо для ускорения поиска

• посмотрите на создание покрытых индексов; при необходимости измените приложение, если оно выполняет команду SELECT * FROM ... когда требуется только SELECT LASTNAME, FIRSTNAME ....

• Повторите выборку из профилировщика, продолжительностью 5 секунд, 3 секунды и т. Д., Пока производительность не будет соответствовать вашим ожиданиям.

Answer 6

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

Answer 7

Сначала мы использовали полностью нормализованную базу данных, но теперь мы сделали ее частично нормализованной из-за проблем с производительностью (чтобы уменьшить количество соединений).

Как гласит старая пословица: "нормализуйся, пока не болит, денормируй, пока не заработай".

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

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

Не зная слишком много о домене вашего приложения, трудно сказать, как вы можете его защитить в будущем, но разделение недавно использованных и старых данных на отдельные таблицы является довольно распространенным подходом для баз данных с интенсивным движением - если 95% Ваши пользователи запрашивают свои данные за последние 30/45 дней, имея таблицу «live_data», содержащую, скажем, данные за последние 60 дней, и «old_data» для более старых данных, которые могут повысить производительность.

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

Answer 8

Несколько миллионов записей - это крошечная база данных для SQL Server. Он может обрабатывать терабайты данных с большим количеством соединений, без пота. Скорее всего, у вас проблема с дизайном или плохо написанные запросы.

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

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

Мое первое предположение: вы не ставили индексы на внешние ключи.

Другие предположения относительно того, что может быть неправильным, включают в себя чрезмерное использование таких вещей, как: коррелированные подзапросы скалярные функции взгляды вызывающие взгляды курсоры Таблицы EAV недостаточная проходимость использование выбора *

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

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

Вам нужно запустить профилировщик и определить, какие у вас самые медленные запросы. Также посмотрите на все запросы, которые выполняются очень часто. Небольшое изменение может окупиться, когда запрос выполняется тысячи раз в день.

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

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

Answer 9

Интересно ... много ответов здесь ..

Является ли версия rdbms / os 64-разрядной?

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

Другая проблема - это данные XML. Вы используете XML-индексы? Из книг в строке (2008) «Используя первичный индекс XML, поддерживаются следующие типы вторичных индексов: PATH, VALUE и PROPERTY.»

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

НТН

Answer 10

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

Если узкое место связано с потребностями в отчетах или только для чтения, я лично не вижу проблем в том, чтобы денормализовать таблицы отчетов в дополнение к нормализованным «производственным» таблицам; создайте процесс, чтобы свернуть на любой уровень, который вам нужен, чтобы сделать запросы быстрыми. Простой SP или ночной процесс, который периодически сворачивает и денормализует таблицы, используемые только для чтения, часто может иметь огромное значение для пользователей.

В конце концов, что хорошего в том, чтобы иметь теоретически чистый, идеально нормализованный набор данных, если никто не хочет использовать вашу систему из-за медленной работы?