Delphi с SQL Server: драйверы OLEDB и Native Client

Question

Мне сказали, что собственный клиент SQL должен быть быстрее, чем драйверы OLEDB.Поэтому я собрал утилиту для проведения нагрузочного теста между ними - и получаю смешанные результаты.Иногда один быстрее, иногда другой, независимо от того, каким может быть запрос (простой выбор, предложение, объединение, упорядочение по и т. Д.).Конечно, сервер выполняет большую часть рабочей нагрузки, но меня интересует время, которое требуется между данными, поступающими на ПК, и временем, когда данные становятся доступны в приложении.

Тесты нагрузки состоят изочень маленькие запросы, которые возвращают очень большие наборы данных.Например, я делаю select * from SysTables, и в этой таблице более 50 000 записей.После получения данных я делаю еще одну загрузку с циклическим просмотром результатов (используя пока не Q.eof ... Q.next ... и т. Д.).Я также попытался добавить некоторые вещи в запрос - например, order by Val, где Val - это поле varchar(100).

Вот пример моего тестера нагрузки, цифры в самом низу - средние значения ...

Так что же на самом деле, какие различия между ними?Я знаю, что OLE очень гибок и поддерживает множество различных механизмов баз данных, тогда как Native Client специфичен только для SQL Server.Но что еще происходит за кулисами?И как это влияет на то, как Delphi использует эти драйверы?

Это специально использует ADO через компонент TADOConnection и TADOQuery.

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

Answer 1

Как заявлено Microsoft :

Собственный клиент SQL Server - это автономный интерфейс прикладного программирования (API) для доступа к данным, используемый как для OLE DB, так и для ODBC, который был представлен в SQL Server 2005. Собственный клиент SQL Server объединяет поставщика SQL OLE DB и SQL. Драйвер ODBC в одну собственную динамически подключаемую библиотеку (DLL).

Насколько я понимаю, ADO - это просто объектно-ориентированный уровень БД на уровне приложения поверх OleDB. Он будет использовать OleDB во всех случаях. Какие изменения используются провайдером. Если вы укажете поставщика SQLNCLI10, вы будете использовать последнюю версию протокола. Если вы укажете поставщика SQLOLEDB, вы будете использовать общий протокол SQL Server 2000 +.

Как таковой:

  ADO -> OleDB -> SQLNCLI10 provider -> MS SQL Server (MSSQL 2000, 2005 or 2008 protocol)
  ADO -> OleDB -> SQLOLEDB provider -> MS SQL Server (MSSQL 2000 protocol)

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

Но ИМХО рекомендуется использовать наиболее подходящего поставщика для вашей базы данных. Некоторые виды данных (например, var(maxchar) или Int64) лучше всего обрабатывать. И провайдер SQLNCLI10 был обновлен, поэтому я думаю, что он более настроен.

Answer 2

1. В своем вопросе вы используете OLE и собственный клиент SQL. Возможно Вы имеете в виду несколько вещей одновременно:

   • OLE -> OLEDB, устаревшая технология доступа к универсальным данным;
   • OLE -> "SQL«Сервер OLEDB-провайдер», который является SQL Server 2000 OLEDB-провайдером;
   • Собственный клиент SQL Server, который является SQL Server 2005 и более поздней клиентской программой.И он включает в себя как поставщика OLEDB, как драйвер ODBC.

2. Если говорить о поставщиках OLEDB и поддерживаемых версиях SQL Server, то:

   • "Поставщик SQL Server OLEDB "(SQLOLEDB) поддерживает протокол SQL Server 2000;
   • " Собственный клиент SQL Server 9 "(SQLNCLI) поддерживает протоколы SQL Server 2000 и 2005;
   • " Собственный клиент SQL Server 10"поддерживает протоколы SQL Server 2000, 2005 и 2008.

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

3. Абстрактно сравнивая, я могу только догадываться о различиях между SQLNCLI и SQLOLEDB:

   • Один из них более корректно использует протокол сервера;
   • Одиниспользует более продвинутые функции протокола;
   • Один выполняет больше обработки, что позволяет обрабатывать больше ситуаций;
   • Один использует более общее / оптимизированное представление данных.

   БезПри правильном применении эталонных тестов и среды трудно принять результаты сравнения, поскольку они могут зависеть от нескольких факторов.

Answer 3

Я думаю, вы должны сосредоточиться на оптимизации:

• настройки сервера и базы данных sql
• ваши запросы
• ваша схема данных

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

Answer 4

Краткий ответ:
Это не имеет значения.

Длинный ответ:
Разница в производительности между двумя клиентскими библиотеками относительно незначительна по сравнению с выполнением сервера + передача данных по сети, что вы в основном измеряете, и, следовательно, неубедительные тестовые данные. В любом случае, есть хороший шанс, что вы используете один и тот же слой низкого уровня в обоих случаях с незначительной разницей в косвенности.

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

Для вашего текущего теста вы должны использовать SQL Profiler для измерения времени выполнения запросов на Сервере, в то же время, когда вы запускаете тест, вы увидите, что они также сильно различаются. Вычитая эти числа из результатов теста, вы получите время для связки Время клиента + Сетевая передача.

Производительность сети весьма различна и оказывает большее влияние на ваш тест, чем вы думаете. Попробуйте, чтобы кто-то передавал потоковое видео в то же время, когда вы запускаете тест, и вы увидите ... (Имели это с моей прежней компанией; настройка SQL в этом случае не была ответом)

Answer 5

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

Answer 6

Нельзя использовать собственные клиенты с ADO, как есть .

ADO не понимает тип данных XML SQL Server.Тип поля:

field: ADOField;

field := recordset.Fields.Items["SomeXmlColumn"];

Попытка доступа field.Value выдает EOleException:

• Источник: Microsoft Cursor Engine
• ErrorCode: 0x80040E21 (E_ITF_0E21)
• Сообщение: Многошаговые операции вызвали ошибки.Проверьте каждое значение состояния

Драйверы клиента native (например, SQLNCLI, SQLNCLI10, SQLNCLI11) представляют тип данных Xml для ADO как

field.Type_ = 141 

В то время как устаревший драйвер SQLOLEDB представляет тип данных Xml для ADO как adLongVarWChar , строка в кодировке Unicode:

field.Type_ = 203 //adLongVarWChar

И VARIANT содержитв field.Value это WideString (технически известный как BSTR) :

TVarData(field.Value).vtype = 8 //VT_BSTR

Решение, как отмечает Microsoft:

Использование ADO с собственным клиентом SQL Server

Существующие приложения ADO могут получать доступ и обновлять значения XML, UDT, а также текстовые и двоичные значения больших значений с помощью поставщика SQLOLEDB.Новые большие varchar (max) , nvarchar (max) и varbinary (max) типы данных возвращаются как типы ADO adLongVarChar , adLongVarWChar и adLongVarBinary соответственно.Столбцы XML возвращаются как adLongVarChar , а столбцы UDT возвращаются как adVarBinary .Однако если вы используете поставщик OLE DB для собственного клиента SQL Server (SQLNCLI11) вместо SQLOLEDB, вам нужно обязательно задать для ключевого слова DataTypeCompatibility значение "80", чтобы новые типы данных правильно отображались втипы данных ADO.

Они также отмечают:

Если вам не нужно использовать какие-либо новые функции, представленные в SQL Server 2005, нет необходимостииспользуйте поставщика OLE DB для собственного клиента SQL Server;Вы можете продолжить использовать свой текущий поставщик доступа к данным, который обычно является SQLOLEDB.

Answer 7

• Время выполнения запроса показывает, насколько хорошо работает ядро ​​базы данных (и любая схема / оптимизация запроса).Здесь то, что вы используете, не имеет значения.ODBC / OLEDB / Native независимо от того, что просто передает запрос в базу данных и выполняется там
• Время, которое требуется для чтения от первой записи до последней, говорит о том, насколько хорошо слой доступа к данным иваша сеть перфом.Здесь вы узнаете, насколько хорошо данные возвращаются и «кэшируются» на вашем клиенте.В зависимости от данных, настройки сети могут быть важны.Например, если в ваших таблицах используются «большие» записи, больший MTU может потребовать меньше пакетов (и меньше циклических возвратов) для отправки их клиенту.

В любом случае, до ищетрешение , вы должны определить проблему .Профилируйте свое приложение, как на стороне клиента, так и на стороне сервера (для этого в SQL Server есть хорошие инструменты), и найдите, что именно делает его медленнее.Тогда и только тогда вы сможете искать правильное решение.Может быть, уровень доступа к данным не проблема.Сегодня 20 000 записей - это небольшой набор данных, а не большой.

Answer 8

Кроме того, кроме отсутствия поддержки типа данных XML, Delphi ADO не распознает столбцы, определенные в SQL Server как TIME (DBTYPE_DBTIME2=145) или DATETIMEOFFSET (DBTYPE_DBTIMESTAMPOFFSET=146);, попытка использовать эти поля в приложении приведет к многочисленным ошибкам, таким как «Неверный вариант». Значение 'или некоторые элементы управления (например, TDBGrid) просто полностью опустят поле.

Похоже, отсутствие поддержки DBTYPE_DBTIME2=145 является ошибкой / проблемой QC, так как уже есть поддержка ftTime (мне также не ясно, почему SQL Server не возвращает DBTYPE_DBTIME, которую поддерживает Delphi), Типы XML и Offset не имеют четкого отображения TFieldType.

Поддержка типов данных для улучшений даты / времени в OLE DB