Множественный доступ к базе данных или один массовый доступ?

Что является лучшим подходом, когда речь идет о производительности и оптимальном использовании ресурсов: многократный доступ к базе данных через AJAX для получения только точной информации, необходимой в случае необходимости, или выполнение одного доступа для получения объекта, который содержит всю информацию, которая может потребоваться с большой вероятностью, что не все на самом деле нужно?

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

Там нет ни одного правильного ответа на это; как и любая оптимизация, она сильно зависит от контекста / использования.

Однако примите во внимание следующее:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

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

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

Нет никакого решения серебряной пули в этом вопросе. Я предполагаю, что вам нужно ПОПРОБОВАТЬ возможные компромиссы и настроить свой сервер (ы), чтобы добиться максимальной отдачи от него.

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

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

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

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

Если вы принимаете архитектурное решение, тогда REST - один из вариантов. С REST вы всегда запрашиваете ресурс несколько раз, т.е. вы не отправляете запрос на получение 2 объектов, потому что каждый объект имеет свой собственный URL. Проблема производительности при использовании этого стиля, вероятно, будет решена, когда выйдет HTTP / 2.0. В противном случае вы просто оптимизируете, чтобы сделать это как можно быстрее. Многие компании делают это таким образом.