P16: Practical Progress

reblog: "Anti-RDBMS: A list of distributed key-value stores"

Here is a great overview of the current landscape of freely available distributed hashtables (DHTs), by one of the founders of Last.fm.

Anti-RDBMS: A list of distributed key-value stores

I've looked at several of these systems in the past, but was delighted to see coverage of even more recent developments like Project Voldemort -- apparently used by LinkedIn.

I still have a need for some system along these lines. My "excerpt server" BDBs are 120 GB and growing forever, with periodic bit-rot errors cropping up, necessitating reconciliation between replicas. I'd love to have a solution that I can throw more data+traffic at that just works.

A new fork of MySQL - "Drizzle"

Drizzle: A High-Performance Microkernel DBMS for Scale-Out Applications

A friend just clued me into this very interesting fork of MySQL, spearheaded by someone inside the MySQL team (Brian Aker) and apparently with the blessing of "Monty" Widenius

Goals include:

• Use UTF8 and InnoDB by default
• Rip out everything that isn't absolutely necessary, including: stored procs, views, triggers, grants
• Make the core as small as possible
• Sharding across multiple nodes
• Make it a "real" community project

Neat! :)

Code is on Launchpad - it's a fork of the MySQL 6.0 codebase. They're aiming for something usable in a few months.

Reply to Viktor, re "Tokyo Cabinet + Tyrant"

Viktor Sovietov left an interesting comment on my "More scalable datastores" post the other day:

Why do not try Tokyo Cabinet + Tyrant as per node storage? In combination with Scalaris and tcerl it could work quite well, I think.
Also, using distributed filesystem can be an option as well. I even prefer this approach, because it gives much better performance.

Well, I am currently using a distributed filesystem: MogileFS. The best thing about Mogile is that it's simple and it scales. But it stores metadata in MySQL so this is ultimately a bottleneck. Also, in Mogile, each record is just a separate file on a filesystem; fetching one record requires (1-2) HTTP connections.

Right now I'm using Mogile to store images (photos). This fits nicely with the one-record = one-file paradigm. But I have another dataset which is ~95 GB and growing, append-only; record size is typically 1 kB. If I store these directly as individual files on a large disk, I'm going to get killed by the block size in most filesystems.

(I presently have 6x 700 GB data drives/box times 4 boxes, using ext3, block/fragment size is 4096. So I'd waste 75% of my disk if I'm writing 1kB files.)

Tokyo Cabinet is an interesting suggestion. At first glance, it seems an interesting alternative to BerkeleyDB -- promising performance close to cdb . Tyrant looks like a straightforward network interface to a DB instance, too.

I'm sure it's possible to weave these together with tcerl and make a new persistent backend for Scalaris. But would it be a net win? I am not interested in forking Scalaris; I'd rather see the Scalaris folks express an interest in developing a persistent backend, and giving the nod to this as a potential solution.

To me, an open-source project is only useful if, three years after I've launched a system, there is still a community of people talking about that project and available to help support it. I want to launch a system, then hand it off to someone else for the maintenance phase. If the project doesn't have "legs", then I will the only person who can answer those support calls down the road, and I'd like to avoid that. :)