On 10 Jan 2013, at 01:30, Edward Capriolo <edlinuxg...@gmail.com> wrote:
> Column families that mix static and dynamic columns are pretty common. In
> fact it is pretty much the default case, you have a default validator then
> some columns have specific validators. In the old days people used to say
> "You only need one column family" you would subdivide your row key into parts
> username=username, password=password, friend-friene = friends, pet-pets =
> pets. It's very efficient and very easy if you understand what a slice is. Is
> everyone else just adding a column family every time they have new data? :)
> Sounds very un-no-sql-like.
Well, we for sure are heavily mixing static and dynamic columns; it's quite
useful, really. Which is why upgrading to CQL3 isn't really something I've
considered seriously at any point.
> Most people are probably going to store column names as tersely as possible.
> Your not going to store "password" as a multibyte UTF8("password"). You store
> it as ascii("password"). (or really ascii('pw')
UTF8('password') === ascii('password'), actually - as long as you're within
ascii range, UTF8 and ascii are equal byte for byte. It's not until code points
> 128 where you start getting multibytes.
Having said that, doesn't the sparse storage lend itself really well for
further column name optimisation - like using a single byte to denote the
column name and then have a lookup table? The server could do a lot of nice
tricks in this area, when afforded so by a tighter schema. Also, I think that
compression pretty much does this already - effect is the same even if
mechanism is different.
/Janne
