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?
SnapOverflow
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?
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.