Производительность вставки SQL Server и Access, особенно при использовании GUID

Question

Мне интересно узнать, как можно улучшить производительность SQL Server при использовании последовательного GUID при использовании Access 2007 в качестве внешнего интерфейса для SQL Server 2008 (обратите внимание, это единственный контекст, который меня интересует).

Я провел несколько тестов (и получил довольно неожиданные результаты, в частности, от SQL Server при использовании последовательный GUID: производительность вставки очень быстро падает, и, кажется, не так быстро снижаться для меня.

В основном тест выглядит следующим образом:

В интерфейсе Access, используя только VBA, вставьте 100 000 записей партиями по 1000, последовательно.

• Я попробовал это как с Идентификацией, так и с последовательным GUID в качестве ПК.
• Я пробовал это в SQL Server 2008 Standard (без специальной настройки, просто установка по умолчанию) в качестве базы данных Access 2007 в качестве серверной части. Все таблицы связаны с внешним интерфейсом.

Некоторые результаты (больше, с необработанными данными, доступными на моей записи в блоге о тесте ):

Понятно, что с ростом базы данных производительность вставки снижается, но SQL Server здесь работает не очень хорошо.

http://blog.nkadesign.com/wp-content/uploads/2009/04/chart02.png

Расширенное представление результатов для SQL Server: http://blog.nkadesign.com/wp-content/uploads/2009/04/chart03.png

Изменить 13APR2009

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

Answer 1

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

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

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

Редактировать Я думаю, здесь также может быть что-то еще, что мы не видим. Я думал, что ваши номера SQL выглядят плохо, поэтому я провел свой собственный тест. На моем рабочем столе под управлением Windows Vista 3,6 ГГц и 2 ГБ оперативной памяти выполнялись операции вставки с последовательным идентификатором GUID на SQL Server:

• Среднее из 1382 вставок в секунду при 0 записях

• Среднее 1426 вставок в секунду при 500 тыс. Записей

• В среднем 1609,6 вставок в секунду от 0 до 500 Кб со средним полом 992 вставок / сек и средним потолком 1989 вставок / сек.

Таким образом, учитывая обычное отклонение, возникающее при запуске этого на рабочем столе, я бы сказал, что вставки SQL Server в основном линейно масштабируются от 0 записей до полумиллиона. На выделенном, настроенном сервере я бы ожидал еще большей согласованности (не говоря уже о далеко лучшей производительности):

Диаграмма Excel, вставок в секунду http://img24.imageshack.us/img24/9485/insertspersecond.jpg

Answer 2

У меня вопрос, соответствует ли ваша тестовая установка реальности вашего приложения или нет. Короче говоря, вы тестируете правильную вещь?

Будет ли ваше приложение добавлять большое количество записей по одной за раз?

Или это будет добавление пакетов записей на основе SQL SELECT?

Если последнее, вы можете попытаться сделать все это на стороне сервера, особенно если исходные таблицы в SELECT находятся на сервере. Важно понимать, что с ODBC пакетное добавление будет отправляться на SQL Server как отдельная вставка для каждой отдельной строки (каждая похожа на подход, основанный на наборе записей в вашем тестовом коде). Если вы перемещаете тот же процесс полностью на стороне сервера, это можно сделать как пакетную операцию.

Кроме того, вы должны проверить снова, используя ADO вместо DAO. Это может оптимизировать работу совершенно по-другому.

И наконец, кто-то обратил мое внимание на прошлой неделе на эту замечательную статью Энди Барона:

Оптимизация приложений Microsoft Office Access, связанных с SQL Server

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

Answer 3

Откуда вы получаете данные?

Изменится ли число, если вы используете пункты меню Access Export, а не запись в одно и то же время?

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

Если столбец идентификаторов является приемлемым, почему вы даже рассматриваете последовательный GUID (что-то вроде привязанного средства в MSSQL, который я последний раз проверял).

---

РЕДАКТИРОВАТЬ: Глядя на ваш код и кратко просматривая документы Recordset на MSDN, я вижу, что вы сможете использовать более эффективные параметры. Например. ваши dbSeeChanges и dbOpenDynaset, которые подходят, если вы пытаетесь разрешить другим пользователям возиться с теми же строками (или вам нужно вернуть вставленное значение IDENTITY или, возможно, GUID), но я не думаю, что они вам нужны. По сути, после каждого INSERT или UPDATE вы читаете запись обратно из базы данных в VBA. Я бы внимательно прочитал эти настройки конфигурации соединения и держу пари, что вы найдете что-то более удовлетворительное.

Answer 4

Вы понимаете, что по крайней мере часть снижения производительности - это заполнение журнала, и что идентификатор GUID на 40 байт длиннее, чем int?

Но я не придираюсь; Приятно видеть, что кто-то берет реальные метрики, а не просто махает рукой. Модифицированный.

Answer 5

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

Кроме того, просто мысль, есть ли какие-либо транзакции? Возможно, транзакции SQL Server приводят к значительному снижению производительности, которого у доступа нет (учитывая, что доступ на самом деле не ориентирован на одновременный доступ).