Ce schimbă această alegere
Alegerea modifică contention, networking și limitele de eșec. Separarea este utilă doar când beneficiul operațional justifică o altă gazdă, o altă cale de acreditare și o altă procedură de recuperare.
Comparați factorii de decizie
| Factor | API și baza de date pe un singur VPS | VPS separat pentru aplicație și bază de date |
|---|---|---|
| Calea cererii | Conexiunea locală evită un hop de rețea între gazde. | Fiecare interogare depinde de ruta de rețea și de autentificarea acesteia. |
| Contention de resurse | API, workerii și baza de date partajează activitatea CPU, RAM și disc. | Fiecare gazdă are un buget separat de resurse. |
| Limita de eșec | Un eveniment pe o singură gazdă poate afecta împreună aplicația și baza de date. | O defecțiune a gazdei aplicației nu trebuie să oprească baza de date, dar serviciul are nevoie de ambele. |
| Sfera de acces | O singură graniță de administrare poate accesa ambele componente. | Administrarea bazei de date poate folosi o graniță de gazdă și rețea mai restrânsă. |
| Planificarea conexiunilor | Pool-urile locale au nevoie în continuare de limite între API și workeri. | Pool-urile au nevoie de limite plus decizii privind timeout-ul de rețea și reîncercările. |
| Recuperare | O singură reconstrucție trebuie să reconstruiască ambele roluri și versiunile lor compatibile. | Fiecare restaurare și conexiunea aplicație-bază de date trebuie exersate împreună. |
Când fiecare opțiune își merită locul
Păstrează un stack mic combinat atât timp cât suprapunerea măsurată se încadrează cu rezervă și o singură graniță de mentenanță este acceptabilă. Separă baza de date când cerințele sale de resurse, acces sau recuperare au devenit independent importante.