3 ms·
This use-case is not something that you would use MongoDB for. Try Zookeeper. This being said, I would feel embarrassed to post this on behalf of the engineeri
by partycoder 10y ago
This use-case is not something that you would use MongoDB for. Try Zookeeper.
This being said, I would feel embarrassed to post this on behalf of the engineering department of a company.
This post is just a very illustrated way of saying "we have no idea about what we are doing and our services are completely unreliable".
This is so bad that is more of an HR problem than it is an engineering problem.
- teraflop 10y agoDid you miss the part about how they're running a hosting platform that stores details about the status of containers for all their customers? Zookeeper is fine for things like service discovery that deal with a bounded amount of data. You don't want to use it for something where the amount of data depends on, say, how many containers your customers decide to start. Every ZK server keeps all of its data on the Java heap, so if your data gets too big, pow. How big is too big? Don't worry, you'll find out the hard way sooner or later! Plus, there's no sharding -- every write operation has to be acknowledged by a majority of nodes in your cluster. So for write-heavy workloads (which is what I would expect a service status dashboard to experience) your cluster actually gets slower if you try to add more machines.
- partycoder 10y agoZookeeper slows down when you add nodes since quorum/consensus is larger. You can mitigate some of this with non-voting nodes (observer nodes) but only up to certain extent. So yes, a single Zookeeper cluster won't scale horizontally. But that doesn't limit the amount of independent clusters you can have. The reason I suggested Zookeeper is because it offers you ephemeral nodes, which is convenient to mark stuff as unavailable.