<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">While this is anecdotal, it offers a bit of perspective. I have done testing on my laptop with sustained ingestion rates of 5,000 and 6,000 samples / 10 seconds without a single dropped mutation. This is with a single Cassandra 3.0.9 node create with ccm on a laptop running Fedora 24 and having 16 GB RAM, 8 cores, and SSD. We also use test environment with virtual machines and shared storage where we might have a tough time sustaining those ingestion rates on a single node depending on the time of day.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 12, 2016, at 11:22 PM, John Sanda &lt;<a href="mailto:jsanda@redhat.com" class="">jsanda@redhat.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hey Daniel,<div class=""><br class=""></div><div class="">Sorry for the late reply. The person who did all the compression work (gayak on freenode) probably will not be around much for the rest of the year. He would be the best person to answer questions on compression; however, I should have some numbers to report back to you tomorrow.</div><div class=""><br class=""></div><div class="">With respect to performance handling 100 samples/second is not a problem, but just like with any other Cassandra TSDB, your hardware configuration is going to be a big factor. If you do not have good I/O performance for the commit log, ingestion is going to suffer. I will let Stefan chime with some thoughts on EC2 instance types.</div><div class=""><br class=""></div><div class="">Lastly, we welcome and appreciate community involvement. Your use case sounds really interesting, and we’ll do our best to get your questions answered and get you up and running.</div><div class=""><br class=""></div><div class="">- John</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 8, 2016, at 12:05 PM, Daniel Miranda &lt;<a href="mailto:danielkza2@gmail.com" class="">danielkza2@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Forgot the links. The uncompressed storage estimates are actually for NewTS, but they should not be much different for any other Cassandra-backed TSDB without compression.<br class=""><br class="">[1] <a href="https://www.adventuresinoss.com/2016/01/22/opennms-at-scale/" class="">https://www.adventuresinoss.com/2016/01/22/opennms-at-scale/</a><br class="">[2] <a href="https://prometheus.io/docs/operating/storage/" class="">https://prometheus.io/docs/operating/storage/</a><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">Em qui, 8 de dez de 2016 às 15:00, Daniel Miranda &lt;<a href="mailto:danielkza2@gmail.com" class="">danielkza2@gmail.com</a>&gt; escreveu:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Greetings,<br class="gmail_msg"><br class="gmail_msg">I'm looking for a distributed time-series database, preferably backed by Cassandra, to help monitor about 30 instances in AWS (with a perspective of quick growth in the future). Hawkular Metrics seems interesting due to it's native clustering support and use of compression, since naively using Cassandra is quite inefficient - KairosDB seems to need about 12B/sample [1], which is *way* higher than other systems with custom storage backends (Prometheus can do ~1B/sample [2]).<br class="gmail_msg"><br class="gmail_msg"></div>I would like to know if there are any existing benchmarks for how Hawkular's ingestion and compression perform, and what kind of resources I would need to handle something like 100 samples/producer/second, hopefully with retention for 7 and 30 days (the latter with reduced precision).<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">My planned setup is Collectd -&gt; Riemann -&gt; Hawkular (?) with Grafana for visualization.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks in advance,<br class="gmail_msg"></div><div class="gmail_msg">Daniel<br class="gmail_msg"></div></div></blockquote></div>
_______________________________________________<br class="">hawkular-dev mailing list<br class=""><a href="mailto:hawkular-dev@lists.jboss.org" class="">hawkular-dev@lists.jboss.org</a><br class=""><a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" class="">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">hawkular-dev mailing list<br class=""><a href="mailto:hawkular-dev@lists.jboss.org" class="">hawkular-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/hawkular-dev<br class=""></div></blockquote></div><br class=""></div></body></html>