Какой метод быстрее в SQL Server? Возвращать данные XML или необработанные данные, которые потребляются через DataTable? - PullRequest
1 голос
/ 30 августа 2009

Масштабируемость сервера является для нас серьезной проблемой. Я пытаюсь выполнить как можно большую часть обработки на клиенте, и, поскольку SQL Server 2008 не имеет встроенной поддержки JSON, он поддерживает XML ...

Я подумал, что если я верну свои данные (используя FOR XML EXPLICIT), а затем в C # (слой BRL), я могу просто использовать один вызов SqlDataReader, чтобы прочитать весь XML и затем передать его клиенту (JQuery).

Разве этот подход не будет более быстрым и более масштабируемым (на сервере), чем использование необработанных данных в C # с использованием DataTable и их возврат клиенту через веб-сервис, который сериализует их в JSON? Опять же, ключевым моментом здесь является масштабируемость сервера.

Спасибо.

Ответы [ 4 ]

5 голосов
/ 30 августа 2009

Если для вас важна масштабируемость сервера, почему вы хотите, чтобы сервер отправлял загрузку текста вместо «сырых» данных в исходной форме, понятной драйверу? Если вы хотите, в конечном итоге, обрабатывать данные как JSON, я не вижу, как может помочь добавление дополнительного преобразования XML как на стороне базы данных, так и на стороне веб-службы. Если вы можете отправить его клиенту в XML, вы уверены, что хотите, чтобы формат, прочитанный клиентом, был , который был тесно связан с базой данных? Это не похоже на хороший уровень связи со мной. Как только вам нужно внести любые изменения в формат, вы внезапно возвращаетесь к синтаксическому анализу XML, его изменению и повторной инициализации.

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

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

Что касается масштабируемости: я не вижу, чтобы сериализация повлияла на то, как конкретно масштабируется код. Это позволит масштабировать как (более мощный сервер), так и вне (больше серверов одинаковой мощности) без дополнительных проблем. Это не значит, что он вводит дополнительный «единственный мастер», который может стать причиной узких мест. Во всяком случае, я бы ожидал, что не-XML-маршрут будет масштабироваться на больше за счет небольшого снижения нагрузки на сервер базы данных (что может оказаться трудным для масштабирования узким местом). Это основано на догадке о том, что для сериализации результатов в XML требуется больше усилий, чем при использовании представлений данных собственного проводного протокола - и я подозреваю, что сериализация XML в SQL-сервере довольно сильно оптимизирована. Опять же, я призываю вас измерить различия (и учесть другие факторы), прежде чем переходить на тот или иной путь.

0 голосов
/ 30 августа 2009

Следует избегать ненужных преобразований, таких как сериализация в XML, а затем повторная сериализация в формате JSON.

Если вы собираетесь отправлять JSON клиенту, вам, вероятно, следует забыть XML все вместе.

Если вы собираетесь использовать XML, вы должны помнить:

Сериализация в XML никогда не бывает дешевой по сравнению с просто не сериализацией.

Между SQL Server и управляемым кодом, я бы предположил, что SQL Server лучше просто потому, что он высоко оптимизирован для этого сценария и делает это в собственном коде .

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

0 голосов
/ 30 августа 2009

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

Системе проще возвращать данные в их собственном формате, а средний уровень C # обрабатывает их оттуда.

0 голосов
/ 30 августа 2009

При использовании подхода C # вы определенно потребляете больше циклов ЦП, чем просто вывод простого XML с SQL-сервера. Здесь есть и другие соображения. SQL-сервер находится на веб-сервере? Если нет, вы должны учитывать пропускную способность сети от SQL до веб-сервера. Собственный поток из SQL на веб-сервер меньше, чем XML. Это может оказаться более узким местом, чем дополнительные циклы ЦП. Кроме того, вы понимаете, что речь идет только о производительности сервера, но json - это более компактный поток для отправки клиенту, который более легко обрабатывается, что облегчает работу пользователя.

Brian

...