README.md

   1 # Voldemort is a distributed key-value storage system #
   2
   3 _N.B.: Voldemort is no longer under development. LinkedIn was the primary maintainer and user of Voldemort, and stopped all production usage in 2018. Most of the Voldemort Read-Only use cases and some of the Read-Write use cases have migrated to [Venice](https://github.com/linkedin/venice), which is actively maintained and also open sourced._
   4
   5 ## Overview ##
   6
   7 * Data is automatically replicated over multiple servers across multiple datacenters.
   8 * Data is automatically partitioned so each server contains only a subset of the total data
   9 * Server failure is handled transparently
  10 * Pluggable serialization is supported to allow rich keys and values including lists and tuples with named fields, as well as to integrate with common serialization frameworks like Protocol Buffers, Thrift, and Java Serialization
  11 * Data items are versioned to maximize data integrity in failure scenarios without compromising availability of the system
  12 * Each node is independent of other nodes with no central point of failure or coordination
  13 * Pluggable storage engines, to cater to different workloads
  14 * SSD Optimized Read Write storage engine, with support for multi-tenancy
  15 * Built in mechanism to fetch & serve batch computed data from Hadoop
  16 * Support for pluggable data placement strategies to support things like distribution across data centers that are geographical far apart.
  17
  18 It is used at LinkedIn by numerous critical services powering a large portion of the site. .
  19
  20 ## QuickStart ##
  21
  22 *You can refer to http://www.project-voldemort.com for more info*
  23
  24 ### Download Code ###
  25
  26 ```bash
  27 cd ~/workspace
  28 git clone https://github.com/voldemort/voldemort.git
  29 cd voldemort
  30 ./gradlew clean build -x test
  31 ```
  32
  33 ### Start Server ###
  34
  35 ```
  36 # in one terminal
  37 bin/voldemort-server.sh config/single_node_cluster
  38 ```
  39
  40 ### Use Client Shell ###
  41
  42 Client shell gives you fast access to the store. We already have a test store defined in the "single_node_cluster", whose key and value are both String.
  43
  44 ```bash
  45 # in another terminal
  46 cd ~/workspace/voldemort
  47 bin/voldemort-shell.sh test tcp://localhost:6666/
  48 ```
  49
  50 Now you have the the voldemort shell running. You can try these commands in the shell
  51
  52 ```
  53 put "k1" "v1"
  54 put "k2" "v2"
  55 get "k1"
  56 getall "k1" "k2"
  57 delete "k1"
  58 get "k1"
  59 ```
  60
  61 You can find more commands by running```help```
  62
  63 Want to dig into the detailed implementation or even contribute to Voldemort? [A quick git guide for people who want to make contributions to Voldemort](https://github.com/voldemort/voldemort/wiki/A-quick-git-guide-for-people-who-want-to-make-contributions-to-Voldemort).
  64
  65
  66 ## Comparison to relational databases ##
  67
  68 Voldemort is not a relational database, it does not attempt to satisfy arbitrary relations while satisfying ACID properties. Nor is it an object database that attempts to transparently map object reference graphs. Nor does it introduce a new abstraction such as document-orientation. It is basically just a big, distributed, persistent, fault-tolerant hash table. For applications that can use an O/R mapper like ActiveRecord or Hibernate this will provide horizontal scalability and much higher availability but at great loss of convenience. For large applications under internet-type scalability pressure, a system may likely consist of a number of functionally partitioned services or apis, which may manage storage resources across multiple data centers using storage systems which may themselves be horizontally partitioned. For applications in this space, arbitrary in-database joins are already impossible since all the data is not available in any single database. A typical pattern is to introduce a caching layer which will require hashtable semantics anyway. For these applications Voldemort offers a number of advantages:
  69
  70 * Voldemort combines in memory caching with the storage system so that a separate caching tier is not required (instead the storage system itself is just fast).
  71 * Unlike MySQL replication, both reads and writes scale horizontally
  72 * Data partioning is transparent, and allows for cluster expansion without rebalancing all data
  73 * Data replication and placement is decided by a simple API to be able to accommodate a wide range of application specific strategies
  74 * The storage layer is completely mockable so development and unit testing can be done against a throw-away in-memory storage system without needing a real cluster (or even a real storage system) for simple testing
  75
  76 ## Contribution ##
  77
  78 The source code is available under the Apache 2.0 license. We are actively looking for contributors so if you have ideas, code, bug reports, or fixes you would like to contribute please do so.
  79
  80 For help please see the [discussion group](http://groups.google.com/group/project-voldemort), or the IRC channel chat.us.freenode.net #voldemort. Bugs and feature requests can be filed on [Github](https://github.com/voldemort/voldemort/issues).
  81
  82 ## Special Thanks ##
  83
  84 We would like to thank [JetBrains](http://www.jetbrains.com) for supporting Voldemort Project by offering open-source license of their [IntelliJ IDE](http://www.jetbrains.com/idea/) to us.