Aerospike goes Open Source

I think the independently written article from AppLovin (link above) points to it actually working as promised.

CTO, co-founder, initial coder here.

Aerospike really is a lot faster than Mongo and Cassandra. It's open source, and you can run whatever benchmarks you'd like yourself. It's about as fast a well-tuned multi-core sharded Redis system, except you don't have to write configure the sharding, and you can have a combination of RAM or Flash, different data in each, of course Flash is cheaper/slower but that's why we give you both.

You can run a single c3.8xlarge on amazon and see 1m tps, or 250K on a c3.2xlarge. We're doing a lot of benchmarks on EC2 and GCE because they're "reference platforms" that you'll all believe. More details in the coming weeks from us, or publish your own.

Just try it yourself; this isn't marketing.

Everyone I talk to coming from Cassandra is seeing a server reduction of 4x~5x, with higher levels of stability (overhead for peaks). I was at a conference late last week and the company I was with (adform's founder, Jakob) said they had a major Cassandra outage that week that cost them a lot of money, and Adform is a Cassandra contributor and knows what they're doing.

Same thing with Mongo shops. They do about 5x reduction and see much higher performance.

Technical points of why we're faster:

* Coded in C, multitheaded, with reference counting.

* Avoid malloc, but if you have to malloc, avoid the CLib memory allocator. We do a lot of slab allocation (a la memcache) and use JEmalloc for variable sized allocs.

* Use epoll directly and be careful about IO. Don't use mmap, which is 4x slower than read and write.

* Code directly to device, with your own data layout. Databases are a reliability layer, everything else is extra complexity. O_SYNC is better than fsync.

There's a lot of smaller tricks in the code, but it all adds up to speed, and I don't expect you to believe me. I've spent 25 years in silicon valley writing high performance software, and so has most of the team. We come from a strong background of embedded, settop box, cell phone programmers.

Let me tell you a short story. I brought my particular bag of tricks to a streaming video server company in the mid 90's. I produced an internal product that was 100x faster - that is, required 100x lower cost hardware than the company's existing product (133mhz Pentium instead of high end sun machines). The product got buried - because the sales guys couldn't make their commission checks.

I'm tired of that mentality.

Aerospike has been running in production at seriously high loads for years. I work with a lot of guys who say - "What else am I going to use?" For the use case where you want KVS, with decent API support (redis-like lists and UDFs), and a little analytics, and scale-out adding nodes under production load, it's the right choice.

If you're thinking of a Mongo KVS, Cassandra, Redis, you really need to look at Aerospike. Do yourself, and your startup, a favor.

( And, yes, the name is based on the Aerospike engine, but we were thinking more of the Trident II D5, which uses an Aerospike at the front, to essentially extend the aerodynamic length of the missile. The problem with sub-based missiles is they have to be short to fit in the sub, and a use of the aerospike was one of many techniques for making the US based deterrent accurate. We used the name Aerospike because there are a lot of small techniques that make an "unbelievable" difference - that's what engineering is, compared to theory. )

PM me directly if you're having trouble running benchmarks or anything.

Aerospike maintains a comprehensive set of tests for the server. Every commit goes through functional and regression tests. Each release goes through a gauntlet of performance and clustering tests. The test system is a standalone system from the database, and is integrated with our CI system. Unfortunately, we have not been able to publish our test system, yet.

I believe my numbers were 4k random access. Admittedly, this was an ages-ago kernel (2.6.18 derivative). mmap as a pattern has issues with concurrency, because you burn threads, and you can't cancel them. The only way out is to try to predict when an mmap page access will block and thread it differently, but then your code path gets longer.

There might be single-thread single-core patterns where mmap works best, or if newer kernels have changed. The reality: you have an IO, you put this "action" aside, you need to be woken up when complete, do you want to burn a thread or an IO context?

We also have recent numbers about using Linux's epoll / eventfd / signal mechanism, like Nginix seems to use, and its so deeply inferior to doing Linux AIO that its hard to choose that path, as seductive as single-event-loop is.

As a Cassandra Committer, I would really appreciate you updating your ycsb integration so we can corroborate your benchmarks, as I currently doubt their authenticity/honesty. It looks very much like you compared non-durable performance in Aerospike to durable performance in Cassandra.

It also appears from your documentation that you do not support any kind of safe active-active multi-dc mode, even in your paid-for offering (http://www.aerospike.com/docs/architecture/xdr.html), so even if faster than Cassandra, users should carefully read the fine print before deciding to use Aerospike, unless as the application grows in size and necessity (i.e. uninterruptibility in event of disaster) you want to find multi-dc is not actually viable for you.

NB: I'm unaware of any adform contributions to Cassandra, although a senior developer there has filed a few bug reports.