Simple question: is it stupid to run mongodb and elasticsearch on the same nodes within a cluster of three if you take care of mongodb's memory hunger using cgroups and ignore the aspect of concurring io?
Asked
Active
Viewed 597 times
1 Answers
0
Warning
The question is light on facts like needed IOPS, RAM, and CPU, so the answer will be light on the same.
Generally speaking it's bad to put two IO/CPU/RAM intensive workloads on the same node, but I do have experience with working on Elasticsearch instances that share hosts with other databases (like Redis and PostgreSQL) that are separated by cgroups / LXC containers. It can be done, and done well enough for a production workload, given enough raw resources. It's a simple matter of keeping watch on IO and RAM usage using standard system tools like vmstat, sar, iotop, etc. and etc. You'll need a few thousand IOPS potential, a few dozen GBs of RAM, and a dozen or so CPU cores, but it's a resonable architecture if you can afford some substantial host machines. Then again, if you can afford substantial enough hosts (for example, i2.4xls in Amazon-speak), then you can afford a larger pool of smaller instances (i2.xls) and run Elasticsearch and MongoDB separated from eachother and then be able to scale up in the future a spart of a better system design.
Wesley
- 32,320
- 9
- 80
- 116
-
I implied enough raw resources - sorry that I did not mention this explicitly. – fen Mar 02 '15 at 16:51
-
To add to this response, I would give Elasticsearch and MongoDB each their own disks if you expect moderate to intensive write load. Same goes if your read activity is heavy and will hit a dataset larger then the RAM provided. – James Wahlin Mar 06 '15 at 13:55
-
@JamesWahlin Definitely something to consider. The hosts I work with have 100,000+ IOPS r/w sustained, so it simplifies architecture with brute force power, but isn't exactly clever. =) – Wesley Mar 06 '15 at 14:04