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

Ответ 1

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

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

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

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

• Отсутствие "правильных" индексов покрытия для дорогостоящих запросов
• Плохая настройка или под указанной дисковой подсистемой

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

Если у вас по-прежнему возникают проблемы, проверьте настройки сервера и оборудования.

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

Ответ 10

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

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

Тупики

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

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

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

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

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

Является ли версия rdbms/os 64 бит?

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

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

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

НТН

Ответ 14

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

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

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

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

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

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

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

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

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

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