Performance Advantages to Splitting Applications from Databases
-
-
So the really easy guide is...
You separate the app and database in order to scale, but at the cost of performance.
For pure performance, you keep them together. The closer the database is to the app, the lower the latency and overhead between them. Even the fastest network connection isn't as fast as a local network connection that doesn't leave the server. And most databases will let you connect through a socket instead of over a network which is even faster still, it's just a shared memory connection. This takes the entire network stack out of the equation and lowers overhead and latency still more.
When you get really big, though, at some point your app + database needs gets larger than what can fit into a single physical box. At that point, you can't keep them together any longer and you have to make the switch. This can be because you have a single giant application / DB or because you have some combination of multiples apps and/or multiple databases that together are too big and need to be shared.
But generally, you want your apps and databases close. The more distance you put between them, the more there is to overcome.
Think of it like a regular disk. Local disks are faster and more reliable than a distant SAN. But it is easier to aggregate many SANs to many servers, so to scale, people sometimes accept the risks and slowness of a SAN because it saves money at scale. Same with databases and apps, the relationship is nearly identical.
-
@gtech said in Performance Advantages to Splitting Applications from Databases:
Is there any performance increase when you separate your SQL server from the Application in cases where the application allows it?
The short answer is no. Read Scott’s reply for details.
-
I didn't have a chance to listen to the video, but security may be another reason to separate Web, App, and DB. You can essentially have stricter traffic rules. I know someone will probably say well, if it's on a local box there is no traffic to worry about and if you have can have your siem alert on specifics such as DB access. However, it is generally accepted as best security practice to have these roles separate with strict rules based on specific traffic only. The application role tends to have more moving pieces than the web or DB role. Web and DB roles are generally very basic for traffic requirements which makes them much easiter to lock down and monitor.
-
@JaredBusch said in Performance Advantages to Splitting Applications from Databases:
@gtech said in Performance Advantages to Splitting Applications from Databases:
Is there any performance increase when you separate your SQL server from the Application in cases where the application allows it?
The short answer is no. Read Scott’s reply for details.
Right and performance can decrease even more if you have SSL termination between these roles.
-
@IRJ said in Performance Advantages to Splitting Applications from Databases:
@JaredBusch said in Performance Advantages to Splitting Applications from Databases:
@gtech said in Performance Advantages to Splitting Applications from Databases:
Is there any performance increase when you separate your SQL server from the Application in cases where the application allows it?
The short answer is no. Read Scott’s reply for details.
Right and performance can decrease even more if you have SSL termination between these roles.
Absolutely.
-
@IRJ said in Performance Advantages to Splitting Applications from Databases:
I didn't have a chance to listen to the video, but security may be another reason to separate Web, App, and DB. You can essentially have stricter traffic rules.
With sockets, nothing is stricter as there is literally no traffic at all. It's the maximum lock down.
-
@scottalanmiller said in Performance Advantages to Splitting Applications from Databases:
@IRJ said in Performance Advantages to Splitting Applications from Databases:
I didn't have a chance to listen to the video, but security may be another reason to separate Web, App, and DB. You can essentially have stricter traffic rules.
With sockets, nothing is stricter as there is literally no traffic at all. It's the maximum lock down.
I mentioned this in my post and that with proper SIEM setup you can get the same type of monitoring for suspicious activity that may trigger a NIDS if it were separated.
Of course if you have admin or root on the single setup you have everything.
-
@IRJ said in Performance Advantages to Splitting Applications from Databases:
Of course if you have admin or root on the single setup you have everything.
Absolutely, but if you get root on the DB server you get everything, and having two systems means double the attack surface, both of which potentially have a lot of access. So cutting the number of places to get root access to in half is a big deal, as well.
Of course, if you dramatically lock down "what can travel over the DB connection", you can limit DB exposure quite a bit, especially if you get say a read-only connection. But for a typical app, let's just say WordPress, you need read/write and don't have those kinds of controls and you have pretty broad exposure.
-
@gtech yeah the only reason is saturation of resources and scaling out.
rdbs do not scale out easily while front ends do. -
@matteo-nunziati said in Performance Advantages to Splitting Applications from Databases:
@gtech yeah the only reason is saturation of resources and scaling out.
rdbs do not scale out easily while front ends do.And RDBMSs tend to scale better vertically (throwing more RAM and CPU in a box) while app servers tend to scale better horizontally (throwing more, smaller boxes at it.)
