Кілька доступів до бази даних або один масовий доступ?

25

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

Я знаю, як орієнтувати фактичні запити, але я не знаю, як перевірити, що найкраще, коли мова йде про продуктивність бази даних, коли тисячі користувачів одночасно отримують доступ до бази даних і як починає працювати об'єднання з'єднань.

performance sql

— DudeOnRock
джерело

Яку платформу ви використовуєте? якщо LAMP u cud використовувати memcaching

— ravi404

Як і будь-яка інша оптимізація продуктивності, ви вимірюєте її.

— Теластин

2

@Telastyn: Я приймаю фундаментальні рішення щодо дизайну і не маю сервера інсценізації. Всі мої db-виклики - це aa 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

Отримати все одразу, ви отримаєте кращу ефективність, якщо "все" не включає такі речі, як BLOB або подібні великі об'єкти даних. Продуктивність накладних витрат, щоб серіалізувати все, перемістити його по дроту, а потім десеріалізувати його на іншому кінці, є досить значним, а затримка в мережі є великою частиною цього. Пам'ять дешевша, ніж пропускна здатність мережі, і, ймовірно, залишатиметься ще деякий час. Ваша єдина реальна відповідь буде виходити з орієнтиру, але якщо ви просто намагаєтесь оцінити одну над іншою, це я так спершусь.

— TMN
джерело

Відповідно до коментарів, для цього використовується локальна база даних, тому тут немає затримки «за дротом».

— Мейсон Уілер

1

Згідно з коментарями, він шукав стратегії, які не були б "чудовими, коли все було на місцях, але були неоптимальними, коли їх приймали в прямому ефірі".

— TMN

1

Якщо ви приймаєте архітектурне рішення, то REST - це один із варіантів. За допомогою REST ви завжди запитуєте ресурс кілька разів, тобто ви не надсилаєте запит на отримання 2 об’єктів, оскільки кожен об’єкт має свою URL-адресу. Занепокоєння у виконанні цього стилю, ймовірно, буде вирішено, коли HTTP / 2.0 вийде. В іншому випадку ви просто оптимізуєте, щоб зробити це якомога швидше. Дуже багато компаній роблять це таким чином.

— име96
джерело