MySQL - один большой запрос против отдельных запросов Ajax

Question

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

Я нахожусь в процессе разработки базы данных mySQL для веб-приложения, и мой вопрос:

Эффективнее ли сделать один запрос, который возвращает одну строку, используя AJAX

или

Чтобы запросить 100 - 700 строк, когда пользователь, вероятно, когда-либо будет использовать результаты только двух или трех?

Неужели я спрашиваю, что для сервера тяжелее 2-3 запроса с одним результатом или 1 запрос с 100 - 700 результатами?

Спасибо

Mark

Answer 1

ну, есть некоторые вещи, которые следует учитывать здесь,

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

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

Answer 2

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

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

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

Профилирование - ваш лучший выбор, так как firebug позволяет вам профилировать JavaScript, чтобы увидеть, действительно ли вам нужно оптимизировать базу данных.

Answer 3

Зависит от размера возвращаемых данных.

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

Для выполнения нескольких небольших запросов требуется большая нагрузка на базу данных, но пропускная способность значительно снижается, поэтому пользователю это кажется быстрее. Время выполнения для 10 против 700 строк на стороне базы данных, вероятно, довольно схоже, но время передачи и рендеринга будет значительно отличаться.

Answer 4

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

Answer 5

Я в значительной степени согласен с тем, что все остальные говорили. Я добавлю это, хотя. Это действительно зависит от ваших данных и от того, как вы собираетесь их использовать и / или кэшировать. Если 700-1000 строк могут быть кэшированы в хеш-таблице, и каждый будет извлекать биты из этого набора, тогда будет работать комбинация двух подходов. Периодически извлекайте и кэшируйте большой набор (при необходимости аннулируйте кэш), но только передавайте то, что нужно конкретному клиенту, через Ajax. Это дает вам преимущество в виде одного большого запроса (который, как правило, более эффективен), но позволяет получать только те данные, которые нужны клиенту (поскольку сеть обычно является самым узким местом).

И всегда делай то, что говорит Джеймс Блэк ... профиль. Это единственный способ узнать наверняка.

Answer 6

Возвращение 700 запросов будет на порядок больше, чем возвращение 3 результатов. Если вы обычно знаете, что ваш средний пользователь будет заинтересован только в 5 или менее результатах, было бы безопасно предположить, что вы можете вернуть эти результаты заранее и избавить себя от необходимости тратить пропускную способность на эти дополнительные 695 результатов, которые никому на самом деле не нужны. *

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

Если каждая строка данных составляет 1 КБ, что может быть завышением, то это разница 5 КБ на запрос (плюс заголовки) по сравнению с 700 КБ. Это очень быстро сложится, учитывая количество пользователей.