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.

"disco", a new map-reduce framework - in erlang+python

Woo! Another alternative to Hadoop crawls out of Nokia Labs:

Disco - discoproject.org

It's yet another Map-Reduce framework. This time the core is written in Erlang, and tasks are implemented in Python. Data transfer between nodes happens simply via HTTP.

There's no DFS implemented at all yet. It seems intended to run on Amazon EC2, where you'd just use S3 as your data store.

This feels like it might be a good fit for our needs, since we're a Python shop, and I'd rather hack on Erlang than Java. :)

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.

My talk last night at WebTechNY User Group

Here are the slides to a talk I gave last night at the WebTechNY User Group

Google App Engine - WebTechNY Aug 2008 - Google Docs

The audience was mostly HTML/CSS developers, not the seasoned server-side developers that Google's own App Engine docs presume, so my pitch was very introductory-level.

Considering that I finished the slide deck at 4PM and my talk started at 6:30PM, I didn't really want to advertise this much. :) Still, and in spite of it being August, I think we had 17 people in the audience. Several folks peppered me with some very astute questions. Privacy, whether to trust Google to our data, was a big concern. I told them my personal opinion on the matter -- but I am not a lawyer, so please use your own judgment.

I met Ashod, the founder of the WebTechNY user group, at the NYC App Engine "hackathon" back in (May?). He was enthusiastic but seemed a bit out of his element, so I tried to help him. I must have impressed him somehow as being an expert, so this talk is the result. :)

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. :)