Accesso a più database o un accesso massiccio?

Non esiste una risposta corretta a questo; come ogni ottimizzazione dipende molto dal contesto / utilizzo.

Tuttavia, considera come segue la seguente regola:

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 -+.

Ricorda la prima regola di ottimizzazione: misura, non indovinare . Provali entrambi, ordinali con una sorta di codice del cronometro e scopri cosa richiede più tempo.

E ricorda anche la vecchia battuta sul fatto che "ci sono solo due problemi difficili nell'informatica: invalidazione della cache e denominazione delle cose bene". Se si estrae tutto dal DB in una volta e lo si tiene in memoria, si dispone di una cache. E ora hai un nuovo problema: ogni volta che qualcosa cambia ovunque nel sistema , deve fare la stessa modifica in due punti: il database e la cache. Se hai più di un server che parla al DB, o più API per fare in modo che il server modifichi i dati, questo può diventare molto complicato molto rapidamente.

Non esiste una soluzione silver bullet a questa domanda. Suppongo che tu debba PROVARE i possibili compromessi e mettere a punto i tuoi server per ottenere il massimo da esso.

Primo punto: prima di iniziare a fare i miglioramenti necessari a IMPOSTARE il benchmark delle prestazioni correnti , misurarlo e prenderlo una linea di base in confronto possibili soluzioni per migliorarlo.

La seconda cosa è che l'utilizzo delle applicazioni deve essere monitorato. Il modo in cui l'applicazione viene utilizzata dagli utenti finali. Riducendo i numeri grezzi dei dati restituiti che non sono necessari all'utente finale, può far risparmiare molte risorse del server . Ad esempio: non è necessario restituire 5000 record mentre gli utenti sono interessati ai primi 50.

Terzo punto: devi capire la frequenza delle chiamate e le possibili implicazioni. Ad esempio: se la maggior parte delle chiamate è una query della tabella dei valori di ricerca, è probabile che tu possa creare un'infrastruttura per memorizzare nella cache queste chiamate . In altre parole, se i dati non cambiano frequentemente, prendere in considerazione l'opzione di memorizzazione nella cache. E, naturalmente, la riduzione al minimo del numero di chiamate dovrebbe contribuire a migliorare le prestazioni.

Ottenere tutto in una volta ti offrirà prestazioni migliori, a meno che "tutto" non includa oggetti come BLOB o oggetti di dati di grandi dimensioni simili. L'overhead delle prestazioni per serializzare tutto, spostarlo sul filo, quindi deserializzare dall'altra parte è piuttosto significativo, con la latenza della rete che ne rappresenta una grossa fetta. La memoria è più economica della larghezza di banda della rete e probabilmente rimarrà tale per un po 'ancora. La tua unica vera risposta verrà da un punto di riferimento, ma se stai solo cercando di valutare l'uno rispetto all'altro, questo è il modo in cui mi piacerebbe.

Se stai prendendo una decisione architettonica, allora REST è un'opzione. Con REST, si richiede sempre una risorsa più volte, ad esempio non si invia una richiesta per ottenere 2 oggetti perché ogni oggetto ha il proprio URL. La preoccupazione per le prestazioni nel farlo con questo stile sarà probabilmente risolta quando uscirà HTTP / 2.0. Altrimenti, devi solo ottimizzare per renderlo il più veloce possibile. Molte aziende lo stanno facendo in questo modo.