We do and we‘re still okay with it. It‘s an incredible piece of engineering of a database, all optimized towards a single use case:
Guaranteed single-millisecond reads and writes on a key-value store that‘s too expensive to fit in RAM.
That being said, nowadays it‘s hard to have a dataset with exactly these properties, and honestly they messed up all other use cases pretty hard.
Secondary indices are hard in practice, and so is any other structure, like sorted sets, or lists, or trees, or any kinds of analytics. They tried a lot of things (LDT) and abandoned them again.
Also, AS can be a diva at operations. The amount of brains and engineering within Aerospike is mindblowing, but it‘s like a F1 car: The fastest you can build, but everything is special and custom made and expensive to replace.
We‘re looking currently at Scylla, which is still decent at K/V (also thanks to recent hardware improvements), but wayyy more flexible from the data model side.
MySQL Cluster (NDB) is a better choice for many looking for a near real-time key-value store. It support cross-partition transactions, partition-pruned index scans, partition-aware transactions, multi-master asynchronous geographic replication between clusters, an Event API, on-disk columns, on-line add node, and has been around the block a lot longer.
We benchmarked AeroSpike vs NDB (a key-value store on top of NDB), and NDB out-performed Aerospike for most workloads with equivalent hardware:
http://www.diva-portal.org/smash/get/diva2:849736/FULLTEXT01...
I don't think so. I believe it would fail quite a few of Jespen's tests, as it is a real-time DB. Typically, you set the transaction deadlock detection timeout to be a couple of seconds. Jepsen thinks transactions can take minutes to complete, and it's ok - the messages are just late.
In fact, in NDB, most people think 2PC is a blocking protocol, but it isn't in NDB. If the Transaction Coordinator (TC) fails, there is a quick leader election protocol and a new one takes over failed TCs. Participant failures cause blocking - but only a few seconds (the configured deadlock detection timeout). So, it's behaviour is similar to abortable consensus (aka Paxos), if automatically retry failed transactions.
> Jepsen thinks transactions can take minutes to complete, and it's ok
Jepsen takes great pains to make no assumptions about the time it takes for transactions to execute. We test systems with millisecond-level timeouts, or multi-minute timeouts, and both work fine.
Ok, my mistake. I saw you tried to install NDB several years ago, without any luck.
Nowadays, there's mysql cluster mgr, severalnines installer, and we wrote some chef code to automate it. So it's pretty straightforward.
can you comment on ease of operations between NDB cluster and aero spike? from my experience NDB cluster is pretty difficult. curious if aero is the same.
Ndb is pretty stable if your workload is stable. Most HLRs at network operators around the world run NDB 24x7, so it is the go-to HA OLTP real-time DB. If, however, you start overloading it, it can be temperamental. So, don't treat it like innodb and do full table scans while expecting millisecond PK lookups.
I can't really comment on running Aerospike in production, because i haven't done it - just run experiments with it.
We did in the past, and lots of AdTech companies currently do. In fact Oracle is one of the biggest users because they acquired BlueKai, and AppNexus is probably their oldest customer.
It's an interesting database that has some strange quirks and is primarily good at a narrow use-case of fast key/value and low-latency on SSDs. It's grown since then but there are better options now like ScyllaDB, Redis Enterprise, Apache Ignite, MemSQL, etc. depending on scenario. I'm not sure there's a situation I would choose Aerospike for anymore.
The "developer" edition of Memsql does not permit you to put it into production and doesn't have any high availability features. So basically you can only run the enterprise version which starts at a minimum commitment of $25k annually and goes up according to RAM usage. Many small projects and startups will opt for a database that lets them get started cheaper/free and with less requirements. Also being not open source might make people worried as too many closed source databases folded in the past, leaving users stuck or forced to migrate to something else.
I evaluated Memsql for a project which would have made good use of both the row storage and columnar storage engines. But with Clickhouse, there's now a columnar database that performs extremely well and is completely free and open source. So half the usecase for Memsql went away. For the row based engine, the competition is a bit tougher. If one doesn't need extreme performance, CockroachDB provides a super easy to cluster consistent SQL db. And for people with more performance need, there's Mysql Cluster (NDB) for example or several NoSQL solutions.
Memsql is aiming for the enterprise market with well paying customers. They are not targeting the HN startup scene that much.
You already mentioned two examples. But open sourcing a database doesn't just prevent against the folding of the company behind it. It creates a community that drives improvements and helps prevent the project from folding. Clickhouse for example has a growing community that files bugs and authors improvements. CloudFlare for example contributed some very useful features.
Open source also means one can examine the bug tracker (in most cases, some don't provide an open bug tracker) for known bugs and dive into the implementation in order to understand the inner workings in more detail if needed. I've made good use of this ability numerous times in the past.
The gist is: if a database which is always a key part of a software architecture, is not open source, then it better provide extremely convincing arguments to choose it over other products. Being open source on the other hand doesn't mean choosing a partical software is a no-brainer. There are tons and tons of open source databases with questionable quality. Open Source as a criterion is just one amongst many. I would for example not hesitate to use some hosted proprietary DB on AWS if it fit the project because I know AWS is unlikely to go away. But some smaller/young companies? The risk that they'll disappear unfortunately is very real in this industry.
Yes, we used it for years and it's a very good system and one of the most polished datawarehouse/column-store systems around with a great interface. It's also very fast and reliable.
Unfortunately it's not open-source and doesn't have a production license for the community edition so it costs money. We never had a problem as we always paid for software (even as a startup) but it can be an issue considering their customers are usually bigger enterprises.
I did in my previous job. It was a good experience except around the time we started seeing corrupt LDTs (Large Data Type). I think a proper solution was never found and they eventually deprecated the feature. I'd recommend it IF you really think you can model your business on top of the KV interface.
