Live data from Hacker News

Beringei: A high-performance time series storage engine

code.facebook.com

41–50 of 58 posts

Re: Beringei: A high-performance time series storage engine

#41

Earlier quoted context omitted.

Can you elaborate on what it is that slows down your app performance? Is it bottle-necking on writing to the database? Does the database have read activity? Does the application slow down when there is read activity? With some basic assumptions on my part including that you can have a delay in writing data to the database (since it's archival and analysis), but you don't want the application to be delayed, putting a…

Yes, we only have one DB for everything and it is bottle-necking on writes. Queuing the writes is probably the easiest solution since we already have RabbitMQ setup... thanks for your answer.

There are a lot of good suggestions here, but if this is the route you're going down and you are still using the same database, do everything you can to batch your inserts. In your queue consumer, aggregate as much as you can tolerate in memory, and then insert them all and commit the inserts in a single transaction. This eliminates a huge amount of MVCC overhead.

Re: Beringei: A high-performance time series storage engine

#42
post #37

Earlier quoted context omitted.

I'm not sure I follow everything what you wrote. I'm interested in how many inserts are you doing per second to the DB. Is it in 1000s/sec or millions/sec.

Millions, not thousands, of inserts per second. TrailDB is hella fast (that's why we use it).

[deleted]

Re: Beringei: A high-performance time series storage engine

#43
post #37

Earlier quoted context omitted.

I'm not sure I follow everything what you wrote. I'm interested in how many inserts are you doing per second to the DB. Is it in 1000s/sec or millions/sec.

Millions, not thousands, of inserts per second. TrailDB is hella fast (that's why we use it).

Thanks. I will check it out.

Re: Beringei: A high-performance time series storage engine

#44
post #28
post #8

Earlier quoted context omitted.

CSV Same way most web servers log traffic.

Or perhaps SQLite, since it should perform similar to writing to a CSV file and you get querying out of the box afterwards.

SQLite is a major powerhouse for stuff like this, and if your analysis is on a single computer with a single disk, analysis is almost always faster than any sort of highly parallel big data setup. I've loaded, analyzed, and reported on 2TB of data using SQLite in less time than it took for an 8 machine spark cluster took to load the data.

Re: Beringei: A high-performance time series storage engine

#45
general note on when companies open source non-trivial projects but squash all pre-release commits, not being able to dig though implementation history and change logs make it difficult to jump in despite the code being publicly visible.

Context: initial commit with 277,989 additions [0].

[0] - https://github.com/facebookincubator/beringei/commit/17a6c2d...

Re: Beringei: A high-performance time series storage engine

#46

We're getting good results from http://traildb.io/ and we don't have to grant Facebook a worldwide, royalty-free license to our patent pool in order to use it.

Great to hear that!

We would love to hear how you are using TrailDB and what could be improved for your use case. Feel free to open issues in GitHub or drop by at our Gitter channel, https://gitter.im/traildb/traildb

Re: Beringei: A high-performance time series storage engine

#47
post #26

Earlier quoted context omitted.

I don't think TrailDB is comparable to Beringei. TrailDB is built for behavioral analytics queries while Beringei is developed for time-series aggregated metrics.

> time-series aggregated metrics That's exactly what we're using TrailDB for. Works great.

Does TrailDB pre-aggregate metrics? AFAIK it stores the raw data bucketed with an actor id (usually a server or visitor) and performs compression and some columnar storage optimizations for events of actors.

Re: Beringei: A high-performance time series storage engine

#48
post #34

Earlier quoted context omitted.

I'm curious about what kind of write speeds you are using traildb for?

We trace every server request with it, across all stages of the request—approx. 10-12 events/timestamps per request—across multiple processes (think Zipkin). The per-request event streams are independent "trails" per process, and then we merge them together later and compute aggregated metrics using hdr_histogram. Individual events are typically hundreds to thousands of nanoseconds long, with about 20 nanoseconds of…

If you don't mind asking: how do you uniquely identify the requests? Is it a composite field made up of `client_ip:timestamp` or a random UUID? What does a typical payload sent across to the TSDB look like? Also I'm assuming the services are written in a language like C or C++?

Re: Beringei: A high-performance time series storage engine

#49
post #37

Earlier quoted context omitted.

I'm not sure I follow everything what you wrote. I'm interested in how many inserts are you doing per second to the DB. Is it in 1000s/sec or millions/sec.

Millions, not thousands, of inserts per second. TrailDB is hella fast (that's why we use it).

So you have a batching mechanism for creating TrailDB files, right? Then you're able to query historical metrics by processing these TrailDB files.

Re: Beringei: A high-performance time series storage engine

#50

What would HN suggest to store about 1GB of data per day, mostly for archiving and offline analysis, with less than 10 columns including timestamp? We're currently writing everything to our postgres DB and flushing the table to S3 every few days but it's killing the app performance under high loads. I'm looking for something that is easy to set up and keep running with low to no maintenance.

Given the "archive and offline analysis" requirements, which are special characteristics. The "hacked" way is to go CSV files, store them on s3. It is very limited but it is also very simple. (Not sure what software can run queries on CSV files directly). The "doing things right" way is to go for AWS RedShift or Google BigQuery. There is a learning curve at the start but it's really REALLY good and it will pay off by…

sqlite can directly process csv
Post reply on HN