Any benchmarks or anecdata about how this performs with millions of 'paths'? What about data larger than memory?<p>Also, you mention difficulties with changing RRD settings, like time intervals. How does this handle similar config migration?<p>I've recently been involved in RRD replacement as well for the same reasons you cite in the article. Our technology choice was OpenTSDB. How does YAWNDB stack up? (Granted, OpenTSDB is in another category of deployment complexity.)
This looks really interesting.<p>How are you writing the data to disk? I don't see exactly what you're doing in the article. Are you just writing the data to files directly or is there some sort of DB in there? From what I've seen, the storage is the most difficult part.
Hi there! Ask me anything, I was an original author of the DB before Pavel took up it's development after I left. Frankly, I was really surprised to see the link here — Pavel did an excellent job describing our rationale in English.
I'm excited since I'm specifically in the market for a lightweight tsdb written in Erlang.
Also the documentation looks quite nice.<p>But like all the other possible contenders I've found, so far. I am unable to compile this project out of the box. Hopefully the maintainers of this one will be commenting on my github issues.<p>At this point it I'm getting the feeling I will have to my own half-baked tsdb to answer only my immediate problem, instead of finding the magic do-it-all well written, documented and extensible tsdb in Erlang.
(I'm 2 weeks into Erlang, so it will probably be very terrible).<p>I've tried (and opened various issues on):
pulsedb: <a href="https://github.com/pulsedb/pulsedb" rel="nofollow">https://github.com/pulsedb/pulsedb</a>
litetsdb: <a href="https://github.com/dreyk/litetsdb" rel="nofollow">https://github.com/dreyk/litetsdb</a>
etsdb: <a href="https://github.com/philipcristiano/etsdb" rel="nofollow">https://github.com/philipcristiano/etsdb</a>
I don't see how to record meta information like a quality indicator (important for lets say timespans where no data could be recorded e.g. during a connection loss).
1. `make all' fetches dependencies. This is bad. It should only compile them.<p>2. No canonical way of running the thing as a daemon. How am I supposed to
make a package out of it?<p>3. No "reload config" command, at least I don't see it. Erlang supports such
thing with application's environment.