incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neophytos Demetriou <>
Subject Re: Per-Namespace / Per-Table Partitioner
Date Wed, 01 Apr 2009 01:26:38 GMT
> I can think of plenty of reasons why you would want or need to go
> beyond mere namespaces. In my opinion "table" or possibly "database"
> are the only sensible terms to describe such a division.

Just a quick message to clarify that, to my understanding, Jonathan was,
in fact, in favor of the per-table division. Having said that, I do
agree with the stated reasons for such a division to exist.

> For example, tables ought to support different replication factors
> (BigTable and HBase both support this). You might also want to specify
> different database directories for each table, eg. to distribute them
> across several disks.
> There are all sorts of settings you will want to apply differently to
> different tables due to usage semantics; for example, I imagine
> Cassandra could be improved to more efficiently supporting streaming
> of large blobs of binary data, GFS-style; and that some of that
> support may be enabled by table-level settings (eg., flags to set
> streaming buffers, append semantics or whatever). I also imagine the
> partitioning and compaction algorithms could mature into providing
> user-definable settings that could be tweaked according to load
> requirements.
> It should also be possible to easily delete an entire table without
> touching other tables. For testing purposes, for example, I would like
> to be able to load an entire table into the system, play with it, then
> drop the entire thing, without having to go through the process of a
> whole new, separate Cassandra. Using temporary tables to store result
> sets is also very common in MapReduce applications.
> Alexander.

View raw message