Может ли SQL Server 2008 обрабатывать 300 транзакций в секунду?

Question

В моем текущем проекте, база данных - это SQL 2005, а нагрузка составляет около 35 транзакций в секунду. Клиент ожидает больше бизнеса и планирует 300 транзакций в секунду. В настоящее время даже при хорошей инфраструктуре у БД возникают проблемы с производительностью. Типичная транзакция будет иметь как минимум одно обновление / вставку и несколько вариантов выбора.

Работали ли вы, ребята, на каких-либо системах, которые обрабатывали более 300 ткс / с на SQL 2005 или 2008, если да, то какую инфраструктуру вы использовали, насколько сложными были транзакции? Пожалуйста, поделитесь своим опытом. Кто-то уже предложил использовать Teradata, и я хочу знать, действительно ли это нужно или нет. Не совсем моя работа, но мне любопытно, сколько SQL может обработать.

Answer 1

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

Answer 2

Согласно tcp.org для SQL Server 2005 возможно получение 1379 транзакций в секунду. Вот ссылка на систему, которая это сделала. (На этом сайте есть системы на базе SQL Server, в которых выполняется гораздо больше транзакций ... та, которую я связал, была только первой, на которую я смотрел)

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

Answer 3

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

Но если у вас в данный момент возникают проблемы, вполне возможно, что основная часть вашей проблемы - плохой дизайн базы данных и плохой дизайн запросов. Есть много способов написать плохо выполняющиеся запросы. В системе с высокими транзакциями вы не можете позволить себе ни одного из них. Нет select *, нет курсоров, нет коррелированных подзапросов, нет плохо выполняемых функций, нет выражений where, которые не могут быть sargeable и так далее.

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

Интересная статья: http://sqlblog.com/blogs/paul_nielsen/archive/2007/12/12/10-lessons-from-35k-tps.aspx