Kyoto Tycoon

Kyoto Tycoon is a key-value store built upon Kyoto Cabinet, a dbm rehash by a guy who loves doing dbm rehashes, Mikio Hirabayashi. He has done three so far. Three separate rewrites of the same idea! This is a direct descendant of Tokyo Tyrant / Cabinet written in C++ to hopefully support non-POSIX (read non-Unix) systems. While the Cabinet portion of the Kyoto pairing is to this level of compatibility, the network bindings that turn it into a server (the Tycoon portion) are not. I tried compiling it with Cygwin, but there were some library dependencies that were missing that I did not want to have to compile, so I ran it on my handy-dandy Ubuntu 10.10 server VM. Continue reading


Neo4j is a graph database written in Java by an eponymous company. A graph database is one that represents data in terms of nodes and relationships between the nodes. This allows for very deep hierarchies and for modeling relationships between objects very easy. The engine itself stores related objects near each other to optimize retrieval. Continue reading


The most serious competition to SQL databases in the sphere of normal development comes from document systems. A document is a collection of key/value pairs, and they vary from document to document, even those that represent the same thing. There are several such systems on the market currently, and MongoDB is one such system written in C++ and made for clustering. The name indicates its function: storing a lot of data very quickly. It is open-source but created and maintained by a commercial company called 10gen. Continue reading


Riak is a key-value store written in Erlang by a company called Basho. They originally wrote it for their own use, but then came to the conclusion that they could build a company around it, similar to the origin story of Redis. Basho also released a couple of other products, also using Erlang, as well as creating an auto-build system. For those out of the know, Erlang is a functional programming language written for high-volume, high-availability telephony installations, originally created by Ericsson. The VM for it is called OTP (Open Telecom Platform), but don’t be put off by the name: it can be used outside of telephone switches. There’s another NoSQL DB written in Erlang, CouchDB, which I wrote another article on. Erlang has been credited with enabling these programs to be written quickly and with multi-threading and high-availability built-in. Continue reading


CouchDB was my gateway drug into NoSQL. It was the most appealing because of its simplicity and its out-of-the-box functionality (a GUI admin, specifically). It is a document store which means it stores multiple fields, and those fields can be documents in and of themselves. One quote that I think is particularly telling of Couch is this: “CouchDB is built of the Web. I’ve never seen software that so completely embraces the philosophies behind HTTP,” comment one developer (Jacob Kaplan-Moss). Continue reading


Ye gods! Punish me not, Apollo, for using Cassandra, a data store written at Facebook and adopted at Reddit and Digg, and tried at Twitter, for I have made the required sacrifice of many hectatombs. All right, I will end with the pagan prayer and get to the technology. Continue reading


Redis is a great little tool for storing little bits of information that you want to keep around but don’t care that much about.  It is a basic key-value store, but it does things like hashes, sets, sorted sets, lists, and message streams.  There is also basic master/slave replication available.  There are also things it does not have: security, durability (in standard mode), consistency, atomicity, online-backups, or real transactions.  It keeps all its data in memory, although there is a feature that allows you to basic page or swap, but it is still not recommended to use it to store larger datasets than available memory.  It is also a single-process, so no locks, but no use of the multi-processor, multi-core architecture common in many systems. Continue reading


Object stores came about when programmers wanted to be able to access objects just like they would out of a cache. They wanted to be able to persist a data entity right to disk without thinking about how it was stored, how it should be translated to SQL, and how to break it apart into separate tables. SQL-based RDBMSes were the norm but C++ was growing in popularity. Older languages like C and COBOL were made for SQL, but SQL was not made for objects. So object databases were born, allowing simple operations like get and set, instead of lengthy mapping code. There were many commercial offerings of this type of system in the 90s, like Objectivity and Versant. Continue reading

Oracle RAC

Oracle is a software program that is at once relatively simple and devilishly complex. Want to do a backup and don’t mind some downtime? Just copy the data files to another location after stopping the server. It’s like backing up a Word document. Want to implement a RAC? Well, clear your calendar, because that’s like rebuilding an engine. There are database administrators that have devoted their entire careers to understanding and to maintaining Oracle systems. Given the many flavors and the longevity of the products, this is a necessary and often worthwhile endeavor. I have heard that the RAC is one of the most complex pieces of this puzzle. Continue reading