111–120 of 132 posts
Earlier quoted context omitted.
It is a pun on this song https://www.youtube.com/watch?v=fWNaR-rxAic
Apart from author being obviously inspired by the song I admit I don't see any connection or anything worth naming that "the pun." Maybe it's just me.
Many kudos to Stripe for funding this. Truly a great gift to the community.
"We want to sponsor your distributed database research, but not your Barbie animated GIF production."
When a product claims to have 100% uptime, I immediately cringe, knowing full well that they're probably full of bovine manure. Good read.
Earlier quoted context omitted.
Store what in the cookie? Every ad the user has seen across the entire web, along with how many times they've seen it in the last N minutes/hours/days/weeks? A cookie won't fit all that data and a more traditional database generally won't work. In memory k/v stores like Redis won't work due to data size (TBs of data). Hbase/Cassandra/etc sort of work with latency in the 5ms range. That's fairly expensive in a 90ms SL…
We (Adroll) have been very happy with DynamoDB for use cases like this. Works fine with ~500B keys, while maintaining very low, and consistent, latencies.
Earlier quoted context omitted.
Store what in the cookie? Every ad the user has seen across the entire web, along with how many times they've seen it in the last N minutes/hours/days/weeks? A cookie won't fit all that data and a more traditional database generally won't work. In memory k/v stores like Redis won't work due to data size (TBs of data). Hbase/Cassandra/etc sort of work with latency in the 5ms range. That's fairly expensive in a 90ms SL…
The alst 4 ads
When a product claims to have 100% uptime, I immediately cringe, knowing full well that they're probably full of bovine manure. Good read.
If you're big enough to require something like Aerospike, you're rich enough to build something like F1.
And honestly, if you have money, it's a lot simpler and less risky to just hire 20 DBAs and programmers to build a database application that can handle that kind of operation. Low latency, network-partition-resistant, high-performance database applications are not a new thing.
We use Aerospike heavily. It works just fine. I'm constantly surprised by the general tone of comments on posts like these as if it's some crazy revelation that this software still obeys the fundamental laws of distributed systems. There is no perfect database out there, all of them will fail with network partitions. Aerospike was designed to work in clusters that are very close together, often the same rack. It has…
Genuine question: how do you know you've never lost a single write?
eg: aerospike will have counters to cap a certain transaction and when we do offline aggregations from logs written through a completely different system, the numbers have to match.
If something is capped to spend $100 and the aggregations don't match up to exactly $100, then there's something wrong, especially with very fine grain numbers.
Earlier quoted context omitted.
Try HBase. At another AdTech company, we have been very happy with it. https://eng.yammer.com/call-me-maybe-hbase
Nooooooooooooooooooooo! Seriously, no! Use mongoDB, PostgreSQL, even flat files if you must, but HBase? We used it in production about 3-4 years ago and it was a nightmare from both usage and especially maintenance point. Fortunately we had a flat-files based backup system so we were able to rescue data every! Single! Time! the damn thing crashed and took (part of) data with it. Of course, this is anecdotal evidence,…
We use is in a very real time use case with latency requirements of single digit milliseconds, and if you tweak it the right way, you can the required performance from it, along with easy horizontal scaling.
Also, I am curious too for aphyr to take on HBase, but I don't think the result would be different since running Jepsen is straightfoward and not much to a person's interpretation. The results and further experiments are what aphyr does nicely.
Earlier quoted context omitted.
He tested PostgreSQL: https://aphyr.com/posts/282-call-me-maybe-postgres
I don't understand how this is comparable though. All of other databases were tested in clustered mode. Why not PostgreSQL as well ?
It's also worth posing this question in reverse: what would happen if these distributed databases were tested in a single-cluster configuration? As noted in the most recent article on Elasticsearch, many of them (e.g. Elasticsearch, Cassandra, and Riak) acknowledge writes before fsync and can therefore lose data due to issues like `kill -9`, power loss, and other exceptional conditions, while Postgres doesn't. For a single-node database this robustness is very important, while he argues that it isn't as important for a distributed one. Because these databases aren't designed to be used as single nodes, aphyr didn't substantially ding them for that. Again, what's important is whether the database does what its documentation says it does when used as its documentation says it should be used.