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

25

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

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

DudeOnRock
источник
какую платформу вы используете? если ЛАМПА и cud использовать memcaching
ravi404
Как и любая другая оптимизация производительности, вы измеряете ее.
Теластин
2
@Telastyn: я делаю некоторые фундаментальные решения по проектированию, и у меня нет промежуточного сервера. Все мои db-вызовы относятся к базе данных, которая находится на той же машине, где выполняется php. Я надеялся извлечь уроки из опыта других людей в этой области, прежде чем я понял, что маршрут, по которому я решил пойти, был великолепен, когда все было локальным, но неоптимальным, если его брать вживую.
DudeOnRock
1
@DudeOnRock - кивком в целом, это зависит от ваших моделей использования и того, как изменяются данные. Если один запрос обеспечивает 80% того, что нужно людям, и данные не часто меняются, то соглашайтесь с этим. Легко кешировать, легко оптимизировать. Если один запрос возвращает примерно 5% того, что обычно требуется пользователям, то, возможно, нет. Я бы склонялся к большему количеству запросов, чем к меньшим. Вы всегда можете отключить их на сервере, прежде чем он попадет в БД. Сложнее отменить «все делает один запрос».
Теластин
@ravz: звучит интересно!
DudeOnRock

Ответы:

27

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

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

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 -+.
Эд Гастингс
источник
24

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

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

Мейсон Уилер
источник
И будьте уверены, что вы измеряете. Например, результаты могут отличаться в зависимости от пропускной способности соединения с базой данных и задержки.
SpaceTrucker
4

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

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

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

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

Е.Л. Юсубов
источник
2

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

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

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

imel96
источник