An experimentation to add ORM on top of Tokyo Cabinet
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


An experimentation to add ORM on top of Tokyo Cabinet 

What Is Tokyo Cabinet?
- Modern implementation of DBM(key/value hash style(HDB), but supports fixed length hash(FDB), and b tree(BDB))
- High concurrency/ high scalability (developed by a developer at Mixi, Japanese equivalent of Facebook)
- More detail at

How dm-tokyo-cabinet-adapter stores data into Tokyo Cabinet.

- Each object is stored as "ObjName.bdb" file: object id as key and entire data marshalled as value
- Each attribute is stored as "ObjNameAttribute.bdb" file: attribute name as key and reference object id as value
- The above architecture can also be considerd "ObjeName.bdb" as table and "ObjNameAttribute.bdb" as indexes for each attributes.
- Currently implements basic CRUD, association, and eql finder.

Motivation behind the development.

- To experiment what you can do with basic hash based database. 
  Interesting post at
- To learn internal of DataMapper and how to implement ORM/adapter 

How to install

1. Install Tokyo Cabinet
2. Install Ruby Binding
3. Install dm-tokyo-cabinet-adapter
3.1 download dm-tokyo-cabinet-adapter
3.2 cd to the dir
3.3 gem build dm-tokyo-cabinet-adapter.gemspec 
3.4 gem install dm-tokyo-cabinet-adapter-0.0.2.gem
4. Create data dir
5. Setup database.yml like below

  :adapter: tokyo_cabinet
  :data_path: <%= Pathname(__FILE__).dirname.expand_path + 'data' %>

6. The rest is usual way to setup datamapper on Merb.

Benchmarking results

My current implementation is a lot slower than MySQL and sqlite, but changing some data storage strategies speed up the performance dramatically, so there are lots of potential for optimization. 

Further research topics/TODO
- Implement outstanding tasks such as multi conditions, other finder conditions (<, <=, like), Data Types
- At this moment, it's only uses B tree, as it covers the wide range of functionality (range search, duplicate values, transaction support, and so on). Consider replacing part to HDB or FDB for compact storage and speed.
- Are there any ways to retrieve first/last key on FDB/HDB?
- Can TC support "not equal" operation?