On 28/03/14 14:39, Aaron Nichols wrote: > On Fri, Mar 28, 2014 at 1:45 AM, Maxime Brugidou > <maxime.brugi...@gmail.com <mailto:maxime.brugi...@gmail.com>> wrote: > > I don't understand why all this is necessary. > > I strongly disagree with the "horizontal scalability" of mongoDB ( > i run a very large mongodb cluster in production in addition to > other databases) and would rather suggest a pluggable backend with > a simpler default (like text files or maybe postgresql or mysql). > > > I'll just 2nd this opinion. My immediate reaction to the addition of > mongo is rejection - my experience with it at scale has been awful & > on a small scale it always feels like overkill. Further, since the > data being served seems like a relatively small dataset it's unclear > to me why there cannot be more options. For our use case (which is
That has already been discussed in the thread - are you OK with the plugin idea? > ~180k metrics) an in-memory datastore for metadata should be more than > sufficient assuming it can be re-hydrated from some persistent source > which could simply be waiting for a polling interval of gmetad. I have > no need for the addition of nagios / rsyslog events. > Knowing you have 180k metrics is only one factor How many users (both humans and processes) want to view your data in real-time? Is it just used by sysadmins, for example, or does everybody in every development or support team access Ganglia? > I've never looked at Ganglia as a horizontally scalable system and > accepted that because it made things simple. If I need to scale it out > I need to partition my grids / clusters. > Agreed - that has always worked and it would continue to work that way too. This is also good for people who have multiple small sites, etc.
------------------------------------------------------------------------------
_______________________________________________ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
