…supplementary tool. (Example: put non-critical session data or stats into Redis or Tokyo Tyrant.) And if you're starting on a new app, you should give serious consideration to NoSQL options for your primary datastore, in addition to the venerable SQL choices.
NoSQL and the Cloud
The SQL databases we're using today were designed over a decade ago. They were written with the constraints of 1990s hardware in mind: storage is cheap, memory and cpu are expensive. Today's …
…simply be better, very soon. Once the mixer covers Ruby 1.9.x, JRuby and Tokyo Tyrant (see todo list ), rufus-tokyo will be irrelevant.
This is great for me (and for you), we will get a better Ruby library for TC/TT. Please note that for Tokyo Tyrant we already have a very fast option with Flinn Mueller's ruby-tokyotyrant , which will always be faster than a FFI Tokyo Tyrant library.
James is exposing his motivations for Oklahoma Mixer on its front …
…Tokyo Cabinet uses so users could read about them in documentation and other resources for that library. Tokyo Tyrant also uses these names to configure a database by command-line, so you can find them in several different contexts.
Database object have an optimize() method that can sometimes be used to modify the tuning parameters of an open() database. The parameters that can be used as such are noted above. There are sometimes additional restrictions though. For example, the :limsiz …
Tokyo Tyrant
Over here, the model of distribution which seems most compelling is the one used by Dynamo. Indeed, it is copied by Voldemort, Riak and Cassandra - three very different kinds of stores. The reason it is most compelling is because it gives simple knobs to an application to tune its expectations of durability, read performance, consistency, write performance, etc. This makes it very general purpose. The other reason this model is good …
…to be modestly performant. I've sacrificed the extreme performance gains from something like Tokyo Tyrant in order to provide something very easy to use. As a result, it's not quite as full-featured as the alternatives in terms of networking or traffic capacity. Third, Oria's persistence is modeled on Redis'- it writes asynchronously to the disk as it goes dormant (i.e. stops fielding requests). Unlike other KVS', however, Oria is not fully persistent. Rebooting…
The cloud providers are splitting into a few camps. On one side, you have
companies like Amazon that offer infrastructure as a service ( IaaS), and Google
who offers platform as a service ( PaaS). PaaS offers rapid development,
and no server administration, but it locks you into a specific provider.
Enter Engine Yard, a company that's enhancing Ruby on Rails to run on on top of
arbitrary IaaS. In this interview Ezra Zygmuntowicz paints the picture.
…
…more elegantly using something like Redis, or a fully persistent key-value store like Tokyo Tyrant. Now there's really no excuse to get that pesky data clogging up your database out of there. These are just some examples.
By the way, if you want to know what your Redis server is doing, telnet to your Redis instance on port 6379, and just enter "monitor". Watch in awe as all the commands coming in from other clients appear on your screen.
In the next post we'll dig …
…Hash-type data store would come in handy. I used Tokyo Cabinet with Tokyo Tyrant, which serializes and deserializes small Ruby Hash objects as my application needs them.
The result was an application that was extremely quick to develop, and which should have great scaling properties.
Core Data on iPhone
When I was approximately halfway through developing my iPhone application, which stores user preferences, Apple released iPhone OS 3.0. Among many improvements to the toolkit …
…it has a 1MB slab size by default . This limit doesn't make sense with Tokyo Tyrant, which is a daemon allowing access to a Tokyo Cabinet key-value database via the Memcached protocol.
I'm still not confident that the semantics of the ruby memcache client are what one would want for use with persistent key-value stores. In particular, I haven't delved into the code enough to figure out if the cases where failure occurs in the memcache client should be different …