Что такое хорошее решение SQL Server 2008 для обработки массивных записей, чтобы они не замедляли чтение для пользователей базы данных?

Question

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

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

У кого-нибудь есть идея, как сделать это с помощью SQL Server 2008?

Answer 1

Paul. Ваш вопрос состоит из двух частей.

Во-первых, почему запись идет медленно?

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

Чтобы выяснить, почему записи выполняются медленно, вам нужно сравнить методы загрузки с методами хранилища данных. Например, вы пробовали использовать промежуточные таблицы? Разделение таблицы? Данные и файлы журналов на разных массивах? Если вы не уверены, с чего начать, посмотрите мой учебник Perfmon, чтобы измерить вашу систему на предмет поиска узких мест:

http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/

Во-вторых, как вы масштабируете?

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

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

Чтобы выяснить, какое решение подходит вам, добавьте к своему вопросу следующее:

• Размер вашей базы данных (ГБ / ТБ, # миллионов строк в самой большой таблице, в которой есть записи)
• Размер вашего сервера и хранилища (в коробке с 10 дисками есть другие решения, отличные от коробки, подключенной к SAN)
• Метод загрузки данных (это вставки с одной записью, массовая загрузка, разбиение таблиц и т. Д.)

Answer 2

Это всего лишь идея. Создайте вид своих «активных» таблиц. Затем BCP в данных в «промежуточной» таблице. Когда это будет сделано, обновите представление, включив в него «промежуточные» таблицы. Просто идея.

Answer 3

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

Answer 4

Почему бы не использовать MemCached для устранения чтений, у меня такая же ситуация, когда я работаю, и мы использовали memcached в Windows с отличными результатами. Я был удивлен, насколько тривиально было заставить мой код работать с ним тоже. Существуют библиотеки обертки с открытым исходным кодом практически для всех основных языков, и их использование может привести к 99% ваших чтений, даже не затрагивая базу данных (поскольку вы устанавливаете значения memcache в операции записи базы данных).

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

При чтении значения memcached, просто проверьте, имеет ли оно значение null (верните, если нет), или выполните обычную базу данных для чтения и возврата. Он может хранить практически все, при условии, что каждая пара ключ / значение в кэше памяти менее 1 МБ.

Answer 5

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

Если это одна и та же база данных, вы всегда можете использовать подсказку «with (nolock)» для чтения, даже когда таблица заблокирована для записи / вставки. Тем не менее, имейте в виду, что чтение может быть грязным чтением. Я не уверен, как вы можете сделать более быстрые быстрые записи, когда таблица заблокирована, потому что запись уже выполняется. Вы можете сделать транзакцию небольшой, чтобы ускорить запись и снять блокировки. Другой вариант - иметь отдельную базу данных для массовых вставок и другую базу данных для чтения.