4 ms·
Because HA, simple to use solutions are very expensive, closed source, or operationally costly. if you think you've got the secret sauce, and you've actually h
by ssmoot 12y ago
Because HA, simple to use solutions are very expensive, closed source, or operationally costly.
if you think you've got the secret sauce, and you've actually had to put it into action and still hit five nines, awesome. But IME doing that with something like PostgreSQL is non-trivial (read: costly). That's why FoundationDB looked so appealing (to me).
- bbulkow 12y agoBiased opinion here (Aerospike CTO and Founder), but you might want to check out open-source Aerospike DB. Like Foundation, it's clustered by default, very very good at SSD / Flash, runs great in cloud deployments, etc. It's been used in production by big ad houses like AppNexus as well as retailers like SnapDeal. Lots of miles on the code. Was closed source for years, but went open source about 9 months ago.
- jakevn 12y agoDoes Aerospike offer transactions?
- jhugg 12y agoIt seems they offer per-key transactions. VoltDB offers full transactions / open-source. Lots of differences between us and Aerospike / FDB.
- ddorian43 12y agoNo high availability on open-source. Meant to be used with partitioning in mind so if you need cross-partition transactions most of the time, it's slow.
- jhugg 12y agoVoltDB has fantastic HA, but yes, not in the OSS version. You might be surprised how many apps deploy on VoltDB with cross-partition transactions making up a solid chunk of their workload. Yes, they're slower than partitioned operations, but they're still faster than MySQL much of the time. Most of the apps we see partition very well, especially for writes. The fact that they can run 10k distributed aggregates a second to get a global view is something few other systems can touch.
- okal 12y agoAGPL would make VoltDB unattractive to most, I'd imagine.
- jhugg 12y agoSeems to work for Mongo, but yeah. You pay me and the licensing question goes away. You still get to poke around the source.
- jaytaylor 12y agoNo clean SQL layer like FoundationDB though.
- tracker1 12y agoIf you don't need SQL, there are a few pretty compelling options out there, each not without their faults... just the same. MongoDB, RethinkDB, ElasticSearch, Cassandra and I'm sure a number of others.. each of them have HA options (though RethinkDB is still a few months out for auto-failover iirc), and Cassandra has pretty close to linear scalability in production for some very large data loads. I really like each for different reasons, and would lean towards one or another depending on load. Not to mention, my speculation is PostgreSQL will likely have an in-the-box replication with failover and/or multi-master solution in place within a few versions.
- AlisdairO 12y agoI think the biggest loss is that all the listed solutions aside from PG lack true multi-key transactions.
- biokoda 12y agoActorDB has them
- AlisdairO 12y agoLooks very different in terms of the sort of performance you'd likely expect out of it, though. My initial reading is that if you want acceptable performance you're likely forced into thinking about sharding - and even then you're going to be punished by SQLite's poor concurrency support.
- biokoda 12y agoSQLite's concurrency support is irrelevant. ActorDB is a sharded by default type of database. The point of ActorDB is to split your dataset into "actors". Actor is an individual unit of storage (a sqlite database). As such your entire database is scalable across any number of nodes. A natural fit is something like dropbox, evernote, feedly, etc. Every user has his own actor and it is a full SQL database. Which makes the kind of queries dropbox would need very easy to do. It also has a KV store option. This is basically a large table across all your servers. This table can have foreign key sub tables. From my understanding of FoundationDB this part is closer to what they were offering.