Re: chunkd design genesis, storage tech, and support for multiple key/value tables

[Pete Zaitcev <zaitcev@redhat.com>]

On Tue, 10 Nov 2009 15:46:27 -0500, Jeff Garzik <jeff@garzik.org> wrote:

> Now the world has figured out giving a storage device the flexibility to 
> manage data on a per-object granular basis simplifies applications, and 
> gives underlying storage more ability to optimize.

This is a sleught of hand by OSD vendors, interested in selling for
more dollars per gigabyte.

> Thus, moving to generic key/value storage actually simplified 
> applications, by eliminating that mapping.

You're so sure about this, I wonder where it comes from.

The fact in case of tabled is, it must maintain a database of keys
of its own, primarily because (a) it cannot afford round-trips into
Chunk for every operation, and (b) to locate the chunks. Both of
these databases may be in RAM, but it does not make them non-existing.

> However, one glaring difference from SCSI OSD was chunkd's lack of 
> administrative partitions.  SCSI OSDs provide "partitions" within each 
> logical unit (LUN), each of contains a set of objects within a single 
> object id namespace.  Therefore, if you consider SCSI OSD object id as 
> the key, then SCSI OSD definitely has multiple key/value tables.

This is a completely bogus analogy. OSD vendors want to push their
wares into PC space, where one unit is all a computer has. But in
the cloud we have thousands of Chunk nodes per each application.
That is your partitioning right there: it's called <Cell></Cell>.

Look, I would not mind if all this partition stuff was free, but
it's not. You decided to embed a partition into a session, so
 - There's a round trip that you excuse by telling applications
   to keep long-living connections, thanks a lot
 - requests to different partitions cannot be pipelined (well,
   not easily).

-- Pete