Getting started with dynomite should be as easy as this.
git clone git://github.com/cliffmoon/dynomite.git cd dynomite git submodule init git submodule update rake ./bin/dynomite start -c config.json
If your favorite language supports thrift, you can generate a client using the thrift interface definition in dynomite/if/dynomite.thrift. For instance, if you want to generate c++ bindings:thrift —gen cpp ./if/dynomite.thrift
That will generate header and cpp files which can be integrated into your own project.
Using the ruby thrift client it should be as easy as this:
require 'thrift' require 'thrift/transport/socket' require 'thrift/protocol/tbinaryprotocolaccelerated' require "gen-rb/Dynomite" socket = Thrift::Socket.new('localhost', 9200) socket.open protocol = Thrift::BinaryProtocolAccelerated.new(Thrift::BufferedTransport.new(socket)) client = Dynomite::Client.new(protocol) client.put("a key", nil, "a value") get_result = client.get("a key") puts get_result.context puts get_result.results
The output from this will look a little something like this:
...firstname.lastname@example.org+09j a value
The first string is what’s called the context. This is a serialized piece of metadata that is meant to be opaque to the client application. When mutating a value the application code should pass this context in as the second parameter to a put request. It establishes a version history within dynomite to help reconcile consistency issues later. For instance, lets say you had marshalled a user object into dynomite and wanted to modify its email. You would do something like so.
get = client.get(user_id) user = Marshal.load(get.results) user.email = new_email client.put(user_id, get.context, Marshal.dump(user))
When dynomite goes to do the update it will use the context information from the client in order to establish a common history between the replicas. This allows dynomite to distribute both read and write operations without having to coordinate transactions between nodes.