I couldn’t find much documentation on this, aside from a CoreOS YouTube video from 2014:
Is there any advantage from a performance standpoint installing a MemSQL host over multiple servers, vs a standalone server?
Let’s use the example of a single Dell PowerEdge server, Scenario #1: 128GB of RAM with 1 Master, 1 Aggregator, and 1 Leaf.
Scenario #2: Two Dell PowerEdge servers both with 128GB of RAM, identical specs, interlinked with a 10G fiber connection. Server #1 includes 1 Master & 1 Leaf. Server #2 includes 1 Aggregator & 1 Leaf.
Using more total leaf node hardware (more total processor cores, RAM, and drives across the cluster) will give you more throughput and faster parallel query performance, in general.
I concur… Also scale up eventually will be very unmanageable. With Scale-out though we have had good success with VMs not having close locality (something you would assume MPP/Analytics would need as pre-req)… there are drawbacks of losing VMs and how quickly you can slap these nodes back in… I think with IAC (infrastructure-as-code) and containerization this will be extremely low-touch.
@isanth, could you please elaborate on “scale-out” if you don’t mind? My simple brain is thinking of the following setup to start: x number of servers all connected to a 10GbE switch, with MemSQL hosts on each one, a Master Agreggator on server #1, and aggregator / leaves spread across the other servers. If I need to scale up, then I could add a spare server.
The one thing I’m unsure of is if a 10GbE connection between leaf servers would be overkill, seeing as each machine will store data on SATA SSDs, or if a 1GbE connection would be enough. Are there example setups scenarios available on the main website?
I’ve never dealt with VMs, perhaps that’s a new avenue for me to venture towards. I’m still in the traditional “get x number of servers for the task” mentality.
Scale up is an industry-standard term for handling increasing scale by using a larger and larger components, such as servers with more RAM, cores, and disk. It works until you reach the limits of the maximum-sized component that’s available to you, within your budget.
Scale out is in industry-standard term for handling increasing scale by adding more standard-sized components.
Using one 10GbE switch to connect nodes is a perfectly reasonable approach. Many of our enterprise customers do that. Even if it is more than your total disk bandwidth, some workloads will do shuffles of the data that’s in RAM, and could use all the available bandwidth.
Thats right… So each VM takes one position of (MAG, CAG1,LEAF1, LEAF2…LEAFN)… Now if you are in the cloud , this should not be difficult, as the cost of running on-prem will get prohibitive, and running VLANs etc… is just inexorable (I think in the days of FPGA, netezza etc… these appliances were popular, but will be looked down in a database management in the 2020s).
Also, memsql folks (who may be on this forum) can enjoin us if “containers” would be more pragmatic (vs VMs), as for low-latency this might be quite deleterious… (especially columnstore via the I/O on SSDs).
I think, the paramount question to ask MemSQL is : Will the performance for rowstore/columnstore scale “linearly” with adding more VMs (and hence memsql nodes).
Yup… i think there is also a rate-limiting factor enterprise shops impose, as the network topology can get complicated… (One of the reasons, i always prefer collecting as much as data points to know where we are losing speed. so expose as much metrics , right from perf, /var/log/sa, memsql monitoring etc…).
a good book on a side note, which give some of the database internals (but sans network topology):
