November 17, 2014 at 21:12

The battle of key-value storage

    What key-value storage do you use in battle?


    I borrowed a list from the site db-engines.com (by the way, a very interesting site, I recommend it), included all the databases with non-zero “popularity” from there. Do not mark the bases that you just tried / interesting, but only those that spin and bring money to your company right now.

    Please note: MongoDB is NOT a key-value storage, but you can vote for it, see the "Document storage as key-value" item.

    Write if you forgot some popular base (i.e., the authors of the db-engines.com site forgot), I’ll add to the survey.

    What key-value storage properties are important to you?


    A motley bunch of requirements. Please walk thoughtfully over them. Please note that many properties contradict each other, because half are aimed at functionality, and the other at performance, which in general contradict each other. Some properties are possible only if other properties or combinations are available, some are enhanced / weakened versions of each other, etc.

    Clauses 2-6 describe some reasonable properties of transactions (by the way, you may not need transactions at all: (e.g. simple get and put by the key are not transactions yet), then do not check any of these items), items 7-9 - the level of consistency of the properties mentioned above.

    “Native client for Java / C / C ++ / C #” - this means the client for these languages ​​does not just form a request in the language in which the database is written, and goes to some IPC / JNI, but works directly with the database. In fact, this means that the database is written (including) in this language. Thanks to such things as Protocol Buffers, Thrift and detailed ones, the base, generally speaking, can be written in several languages.

    I 100% forgot some important properties, write in a personal, add to the survey.

    Only registered users can participate in the survey. Please come in.

    What key-value storage do you use in battle?

    • 1.4% Aerospike 20
    • 0.2% ArangoDB 4
    • 4.5% Berkeley DB 62
    • 0.7% Coherence 10
    • 1.2% DynamoDB 17
    • 2% Ehcache 28
    • 0% FoundationDB 1
    • 0.2% GridGain 4
    • 0.2% GT.M 4
    • 0% Hamsterdb 1
    • 1.3% Hazelcast 18
    • 0% Hibari 0
    • 0% HyperDex 0
    • 0.2% Infinispan 4
    • 0.5% Kyoto Cabinet 7
    • 3.1% LevelDB 42
    • 0.5% MapDB 7
    • 37.7% Memcached 511
    • 0.2% NCache 3
    • 0.5% Oracle NoSQL 8
    • 0.1% Project Voldemort 2
    • 53.9% Redis 731
    • 3.2% Riak 44
    • 0.5% RocksDB 7
    • 0% Scalaris 0
    • 0.2% SimpleDB 4
    • 0% Sqrrl 0
    • 0% STSdb 0
    • 1.7% Tarantool 24
    • 0.8% Tokyo Cabinet 11
    • 0.2% Tokyo Tyrant 4
    • 0% WebSphere eXtreme Scale 0
    • 0% XAP 1
    • 0% ZODB 1
    • 1.6% Other key-value storage (I will indicate in the comments) 22
    • 20.6% Relational database as key-value storage (Oracle, MySQL, PostgreSQL, ...) 279
    • 20.9% Document storage as key-value (MongoDB, CouchDB, Couchbase, ...) 284
    • 4.5% of a different type of database as key-value storage (e.g. graph: Neo4j, wide column storage: Cassandra, HBase, ...) 61
    • 6.1% Proprietary key-value storage 83
    • 8.1% I do not use key-value storage 111
    • 0.4% LMDB 6
    • 0% LedisDB 1
    • 0.1% GoLevelDB 2
    • 0.2% BoltDB 4
    1354 users voted. 1101 users abstained.

    What key-value storage properties are important to you?

    • 62.3% Scalability (I want to store more / withstand more workload by adding servers) 358
    • 34.8% Atomicity of transactions with one key (either record all changes in value or nothing) 200
    • 17.5% Isolation of transactions on one key (multiple simultaneous transactions on one key are prohibited) 101
    • 33.2% Durability of transactions (after the end of the transaction, I definitely won’t lose data) 191
    • 12.1% Multiple Key Transaction Atomicity 70
    • 6.9% Isolation of transactions for several keys (multiple simultaneous transactions intersecting by keys are prohibited) 40
    • 6.6% Transactions within the server (on the DC / the entire database changes will spread over time) 38
    • 5.2% Transactions within the DC (changes will spread over the entire base over time) 30
    • 9.4% Transactions to the entire base 54
    • 44.4% Fault tolerance (server burned out - continue to work) 255
    • 20.2% Cool fault tolerance (DC disconnected - continue to work) 116
    • 20.2% Replication of changes between servers (the property is slightly weaker than scalability) 116
    • 14.1% Key ordering (the ability to iterate over the keys in sorted order, find the closest larger / smaller key than the given key, etc.) 81
    • 20.2% Guaranteed maximum response latency 116
    • 18.4% Subscription for events by key 106
    • 15.8% Logging (some, at least I want to be able to see what is happening with the database, for debug) 91
    • 5.9% Playback Change Logging 34
    • 16.3% Asynchronous API (received future by key) 94
    • 40% Data storage in memory (to go for each key to a disk - too slowly) 230
    • 23.8% Storage on disk (e.g. for reliability if the database is not distributed) 137
    • 10.4% Windows support (I want to drive the base on my development Windows / I have a Windows server) 60
    • 6% MacOS support (I want to drive the base on my development Mac) 35
    • 5.9% Remote requests (RPC, thin clients) 34
    • 9.2% Native Client for Java 53
    • 11.3% Native client for C / C ++ 65
    • 9.5% Native client for C # 55
    • 11.4% Web interface (send CRUD requests via HTTP) 66
    • 16.2% Web-face for monitoring the base 93
    • 8.3% Backup to Relational Database 48
    • 28.3% Some backup 163
    • 10.6% No properties are needed, as well as the key-value of the storage in principle 61
    574 users voted. 1154 users abstained.
    Tags:

    Also popular now: