От чего зависит скорость запросов к базе данных и скорость вставки?

Question

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

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

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

Я не совсем уверен, что это стандартное поведение / производительность, или мы делаем что-то не так. Например, 1500 запросов, которые подразумевают объединение 4 таблиц в одном ключевом столбце, занимают около 10 секунд. Загрузка 300 КБ данных в формате xml в базу данных с использованием простых вставок занимает 3 минуты без нарушения каких-либо ограничений.

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

Правильно ли это? Если нет, что может повлиять на производительность? (Все запросы выполняются по индексированным столбцам)

Answer 1

Для приблизительного сравнения: запись теста производительности TPC-C для SQL Server составляет около 1,2 млн транзакций в минуту и ​​была такой же за последние 4 года или около того (ограничена 64 CPU Ограничение ОС). Это что-то в балпарке ~ 16 000 транзакций в секунду . Это на суперкомпьютерах высшего класса, 64 ЦП, много оперативной памяти, аффинитизированных клиентов на узел NUMA и серверно-разборная система ввода-вывода (используется только примерно 1-2% каждого шпинделя). Имейте в виду, что это транзакции TPC-C, поэтому они состоят из нескольких операций (я думаю, в среднем это 4-5 операций чтения и 1-2 записи).

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

Для загрузки данных текущий мировой рекорд составляет около 1 ТБ за 30 минут (если он все еще актуален ...). Несколько десятков тысяч вставок в секунду довольно амбициозны, но достижимы при правильной работе на серьезном оборудовании. Статья в ссылке содержит советы и рекомендации по высокой пропускной способности ETL (например, использование нескольких потоков загрузки и привязка их к узлам NUMA).

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

Answer 2

Индексация является здесь основным фактором, при правильном выполнении они могут довольно быстро ускорить операторы Select, но помните, что индекс будет тормозить вставку, а сервер обновляет не только данные, но и индексы. Хитрость здесь такова:

1) Определите запросы, которые действительно критичны по скорости, эти запросы должны иметь оптимальные индексы для них.

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

Мой трюк такой, для каждого приложения я устанавливаю приоритеты следующим образом:

1) Скорость чтения (SELECT, Some UPDATE, Some DELETE) - чем выше этот приоритет, тем больше индексов я создаю
2) Скорость записи (INSERT, Some Update, Some DELETE) - чем выше этот приоритет, тем меньше создаваемых мной индексов
3) Эффективность дискового пространства - чем выше этот приоритет, тем выше коэффициент заполнения

Обратите внимание, что эти знания обычно применяются к SQL Server, пробег может отличаться в зависимости от СУБД.

Здесь также может помочь оценка операторов SQL, но для этого нужен настоящий профессионал, тщательный анализ ГДЕ и СОЕДИНЕНИЕ может помочь определить узкие места и проблемы, с которыми сталкиваются ваши запросы. Включите SHOWPLAN и запросите планы, оцените то, что вы видите, и планируйте соответственно.

Также посмотрите на SQL Server 2008, индексированные объединения!

Answer 3

Модель "Богатая реляционная зависимость" не способствует быстрой скорости вставки. Каждое ограничение (первичный ключ, проверка значений и особенно внешние ключи) должно проверяться для каждой вставленной записи. Это намного больше работы, чем «простая вставка».

И это не значит, что ваши вставки не имеют нарушений ограничений, вероятно, настанет время для проверки ваших внешних ключей. Если у вас также нет триггеров, потому что они еще хуже.

Конечно, возможно, что единственное, что неправильно, это то, что ваша таблица вставки - это FK-родитель для FK-отношения "must-have-children" для другой таблицы, которая забыла добавить индекс для стороны child-FK. по отношению к FK (это не автоматически и часто забывают). Конечно, это просто надежда на удачу.: -)

Answer 4

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

150 запросов в секунду, объединяющих 4 таблицы, звучат нормально, хотя я не очень разбираюсь в ваших данных.

Answer 5

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

(a) Производительность базы данных зависит на 99% от объема физического ввода-вывода (если только вы не находитесь на каком-то небольшом сайте, использующем базу данных в памяти, которая может безвредно позволить отложить весь физический ввод-вывод до окончания рабочего дня готово). (b) База данных ввода / вывода включает в себя не только фактический физический ввод / вывод для файлов данных, но также физический ввод / вывод для сохранения журналов / журналов / ... (и ведение журнала часто даже выполняется в двойном режиме (т. е. дважды) так как скажем около двух десятилетий или около того). (c) То, каким образом «количество вставок» соответствует «количеству физического ввода-вывода», полностью определяется тем, сколько вариантов имеется у разработчика базы данных для оптимизации физического проекта. В целом об этом можно сказать только одно: системы SQL в большинстве случаев терпят неудачу (чтобы обеспечить опции, необходимые для преобразования «десятков тысяч вставок» в просто «пару сотен» физического ввода-вывода). Это означает, что «десятки тысяч вставок» обычно также подразумевают «тысячи физических операций ввода-вывода», что обычно подразумевает «десятки секунд».

Тем не менее, ваше сообщение, кажется, выражает ожидание, что каким-то образом «вставки выполняются очень быстро (« десятки тысяч в секунду »)», в то время как «запросы медленнее» («миллисекунды на запрос», что подразумевает «менее 1000 запросов в секунду»). второй "). Это ожидание абсурдно.