Сортировка на сервере или на клиенте?

Question

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

Кто-нибудь, какая стратегия лучше всего подходит для общей производительности многопользовательской системы?

Answer 1

В общем, вы должны позволить базе данных выполнять сортировку; если у него нет ресурсов для эффективной обработки, вам необходимо обновить сервер базы данных.

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

Answer 2

Зависит от того, участвует ли пейджинг? Каков максимальный размер набора данных? Нужно ли сортировать весь набор данных одним и тем же способом все время? или по выбору пользователя? Или (если используется подкачка страниц), нужно ли сортировать только записи на одной странице на экране клиента? (обычно неприемлемо) или нужно отсортировать весь набор данных и заново отобразить первую страницу вновь отсортированного набора?

Каково распределение клиентского оборудования по сравнению с требованиями к обработке для этой операции сортировки?

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

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

Answer 3

Я за ответ Робертса, но я хотел бы добавить к нему немного.

Я также поддерживаю сортировку данных в SQL Server, я работал на многих системах, которые пытались сделать это на стороне клиента, и почти во всех случаях нам приходилось переписывать процесс, чтобы он выполнялся внутри SQL Сервер. Почему это вы можете спросить? Ну, у нас есть две основные причины.

1. Количество сортируемых данных
2. Необходимость правильной подкачки из-за # 1

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

Чтобы добавить некоторые цифры, сортировка на стороне сервера SQL в сортировку на стороне клиента в нашей среде, ни для одного из них страниц нет. На стороне клиента 28 секунд с использованием XML для сортировки, а на стороне сервера общее время загрузки - 3 секунды.

Answer 4

Как правило, я согласен с мнением, высказанным выше, что сортировка на стороне сервера - это, как правило, путь. Однако иногда есть причины выполнять сортировку на стороне клиента:

• Критерии сортировки выбираются пользователем или многочисленны. В этом случае, возможно, не стоит добавлять в таблицу небольшую загрузку индексов, особенно если это касается производительности вставки. Если какие-то критерии сортировки используются редко, индекс не обязательно стоит, так как вставки будут превосходить число выборок.
• Критерии сортировки не могут быть выражены в чистом SQL [необычно] или не могут быть проиндексированы. Это не обязательно более быстрая клиентская сторона, но она загружает сервер.

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

Answer 5

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

Также, скажем, в сетке, вам, возможно, придется реализовать сортировку на клиенте, так как пользователь может изменить порядок, щелкнув заголовок столбца (не нужно просить сервер снова получить всю информацию). )

Answer 6

Я предпочитаю настраиваемую сортировку на клиенте, однако я также предлагаю, чтобы большинство операторов SQL по умолчанию содержали разумное предложение ORDER BY. Это очень мало влияет на базу данных, но без этого вы можете столкнуться с проблемами позже. Часто, даже не осознавая этого, разработчик или пользователь начинают полагаться на некоторый начальный порядок сортировки по умолчанию. Если предложение ORDER BY не было задано, данные случайно попадают в этот порядок. Позже индекс может измениться или данные могут быть реорганизованы, и пользователи будут жаловаться, потому что первоначальный порядок данных мог измениться из-под них.

Answer 7

Как и любой другой вопрос, связанный с производительностью, универсальный ответ ... «Это зависит». Тем не менее, я разработал предпочтение сортировки на клиенте. Мы пишем приложения на основе браузера, и мое определение клиента разделено между веб-серверами и реальным клиентом конечного пользователя, браузером. У меня есть две причины предпочитать сортировку на клиенте сортировке в БД.

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

SELECT TOP 1 price 
FROM itemprice 
WHERE ItemNumber = ? 
   AND effectivedate <= getdate() 
ORDER BY effectivedate DESC

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

Вторая причина, по которой я предпочитаю сортировку на клиентском уровне, связана с производительностью. Веб-серверы масштабируются горизонтально, то есть, если я перегружаю свой веб-сервер пользователями, я могу добавить еще один, и другой, и другой. У меня может быть столько внешних серверов, сколько мне нужно, чтобы справиться с нагрузкой, и все работает просто отлично. Но, если я перегружу базу данных, я облажался. Базы данных масштабируются по вертикали, вы, конечно, можете использовать больше оборудования для решения проблемы, но в какой-то момент это становится непомерно дорогостоящим, поэтому я хотел бы позволить БД делать выбор, который она должна делать, и позволить клиенту выполнять сортировку, которая это может довольно просто.

Answer 8

Как обычно, « Это зависит »:)

Если у вас есть хранимая процедура, например, которая отправляет результаты на уровень представления (будь то отчет, сетка и т. Д.), Вероятно, не имеет значения, какой метод вы используете.

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

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

Answer 9

Ситуации меняются, и важна эффективность измерений.

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

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

Answer 10

Сделайте это на сервере.

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

Если набор данных небольшой, он не окажет никакого влияния на производительность или использование ресурсов при выполнении этого на клиенте или сервере.

все это с учетом того, что ваше клиентское приложение хорошо спроектировано, и вы не сможете участвовать в сценариях, когда вы выполняете сортировку на клиенте и параметры сортировки изменяются (например, когда клиент говорит «ооо, теперь я хочу этот важный отчет о яшме, который Вы ссылаетесь в 356 различных местах с 23 различными параметрами, упорядоченными по фамилии, а не по дате рождения '