0

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?

1 Answer 1

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.

3
  • I implied enough raw resources - sorry that I did not mention this explicitly.
    – fen
    Mar 2, 2015 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. Mar 6, 2015 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 6, 2015 at 14:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .