Что база данных запрашивает и вставляет скорость, зависят от?
Всегда пытайтесь использовать InvariantCulture в тех строковых методах, которые принимают его как перегрузку. При помощи InvariantCulture Вы находитесь на безопасной стороне. Многие программисты.NET не могут использовать эту функциональность, но если Ваше программное обеспечение будет использоваться различными культурами, InvariantCulture является чрезвычайно удобной функцией.
5 ответов
Для приблизительного сравнения: запись теста TPC-C для SQL Server составляет около 1,2 млн транзакций в минуту, и так было в течение последних 4 лет или так (ограничено лимитом ОС 64 ЦП). Это примерно ~ 16k транзакций в секунду . Это на супер-высокопроизводительных машинах, 64 процессорах, большом количестве ОЗУ, аффинитизированных клиентов на узел NUMA и серверной системе ввода-вывода с коротким вырезом (используется примерно 1-2% каждого шпинделя). Имейте в виду, что это транзакции TPC-C, поэтому они состоят из нескольких операций (я думаю, что в среднем это 4-5 операций чтения и 1-2 записи каждая).
Теперь вам следует уменьшить масштаб этого топового оборудования до вашего фактическое развертывание, и вы получите приблизительную оценку того, где вы можете рассчитывать на общую обработку транзакций OLTP .
Для загрузки данных текущий мировой рекорд составляет около 1 ТБ за 30 минут (если он еще актуален ...). Несколько десятков тысяч вставок в секунду - это довольно амбициозно, но достижимо при правильном выполнении на серьезном оборудовании. В статье по ссылке содержатся советы и рекомендации по обеспечению высокой пропускной способности ETL (например, использование нескольких потоков загрузки и привязка их к узлам NUMA).
Для вашей ситуации я бы посоветовал в первую очередь измерить , чтобы вы могли найти устраните узкие места, а затем задайте конкретные вопросы, как решить конкретные узкие места. Хорошей отправной точкой является технический документ Waits and Queues .
при правильной работе на серьезном оборудовании. Статья по ссылке содержит советы и рекомендации по обеспечению высокой пропускной способности ETL (например, используйте несколько потоков загрузки и привязайте их к узлам NUMA).Для вашей ситуации я бы посоветовал в первую очередь измерить , чтобы вы могли найти устраните узкие места, а затем задайте конкретные вопросы, как решить конкретные узкие места. Хорошей отправной точкой является технический документ Waits and Queues .
при правильной работе на серьезном оборудовании. Статья по ссылке содержит советы и рекомендации по обеспечению высокой пропускной способности ETL (например, используйте несколько потоков загрузки и привязайте их к узлам NUMA).Для вашей ситуации я бы посоветовал в первую очередь измерить , чтобы вы могли найти устраните узкие места, а затем задайте конкретные вопросы, как решить конкретные узкие места. Хорошей отправной точкой является технический документ Waits and Queues .
Модель «Rich Relational Dependency» не способствует высокой скорости вставки. Каждое ограничение (первичный ключ, проверки значений и особенно внешние ключи) необходимо проверять для каждой вставленной записи. Это гораздо больше работы, чем «простая вставка».
И это не значит, что ваши вставки не имеют нарушений ограничений, время, вероятно, уйдет на проверку ваших внешних ключей. Если только у вас нет триггеров, потому что они еще хуже.
Конечно, возможно, что единственное, что неверно, это то, что ваша таблица Insert является родительским FK для отношения FK с обязательными дочерними элементами для другой таблицы, которая забыла добавить индекс для дочерней FK стороны. по отношению FK (это не происходит автоматически и о нем часто забывают). Конечно, это просто надежда на удачу.: -)
Ограничения добавляют небольшое снижение производительности. Он также должен обновлять индексы для каждой вставки. И если вы не помещаете несколько вставок в одну транзакцию, сервер базы данных должен выполнять каждую вставку как новую отдельную транзакцию, что еще больше замедляет ее.
150 запросов в секунду, объединение 4 таблиц звучит нормально, хотя я не Я мало знаю о ваших данных.
«Я всегда ожидал, что это будет довольно быстро, порядка нескольких десятков тысяч вставок в секунду, а запросы будут занимать миллисекунды после установления соединения».
(a) Производительность базы данных на 99% зависит от объема физического ввода-вывода (если только вы не находитесь на каком-то небольшом сайте, использующем базу данных в памяти, которая может безвредно позволить отложить все физические операции ввода-вывода до завершения рабочего дня). (b) Ввод-вывод базы данных включает не только фактический физический ввод-вывод для файлов данных, но также физический ввод-вывод для сохранения журналов / журналов / ... (и ведение журнала часто даже выполняется в двойном режиме (т. е. дважды) так сказать около двух десятилетий). (c) Каким образом «количество вставок» соответствует «количеству физических операций ввода-вывода», полностью определяется тем, сколько вариантов доступно разработчику базы данных для оптимизации физического дизайна. В целом об этом можно сказать только одно: системы SQL по большей части терпят неудачу (чтобы обеспечить параметры, необходимые для преобразования «десятков тысяч вставок» в, возможно, «пару сотен» физических операций ввода-вывода). Это означает, что «десятки тысяч вставок» обычно также подразумевают «тысячи физических операций ввода-вывода», что обычно подразумевает «десятки секунд».
Тем не менее, ваше сообщение, кажется, выражает ожидание того, что каким-то образом «вставки выполняются чрезвычайно быстро. ("десятки тысяч в секунду") "в то время как" запросы выполняются медленнее "(" миллисекунды на запрос ", подразумевая"
Важным фактором здесь является индексирование. При правильном выполнении они могут довольно хорошо ускорить операторы Select, но помните, что индекс задерживает вставку, а сервер не только обновляет данные, но и индексы. Уловка здесь заключается в следующем:
1) Определите запросы, которые действительно критичны по скорости, эти запросы должны иметь для них оптимальные индексы.
2) Здесь также важен коэффициент заполнения. Это обеспечивает пустое пространство на странице индекса для последующего заполнения. Когда страница индекса заполнена (вставлено достаточное количество строк), необходимо создать новую страницу, что займет еще больше времени. Однако пустые страницы занимают место на диске.
Моя уловка заключается в следующем: для каждого приложения я установил следующие приоритеты:
1) Скорость чтения (SELECT, Some UPDATE, Some DELETE) - чем выше этот приоритет, тем больше индексов Я создаю
2) Скорость записи (INSERT, Some Update, Some DELETE) - чем выше этот приоритет, тем меньше индексов я создаю
3) Эффективность дискового пространства - чем выше этот приоритет, тем выше мой коэффициент заполнения
Обратите внимание, что эти знания обычно применимы к SQL Server, ваш пробег может отличаться от другой СУБД.
Оценка оператора SQL также может помочь здесь, но это Требуется настоящий профессионал, тщательный анализ WHERE и JOIN может помочь определить узкие места и определить, где страдают ваши запросы. Включите SHOWPLAN и планы запросов, оцените то, что вы видите, и спланируйте соответственно.
Также посмотрите на SQL Server 2008, индексированные соединения!