Also I have to say I do not get that blank sparse column. Ghost ranges are a little weird but they don't bother me.
1 its a row of nothing. The definition of a waste. 2 suppose of have 1 billion rows and my distribution is mostly rows of 1 or 2 columns. My database is now significantly bigger. That stinks. 3 suppose I write columns frequently. Well do I have to constantly need to keep writing this sparse empty row? It seems like I would. Worst case each stable with a write to a rowkey also has this sparse column, meaning multiple blank empty wasteful columns on disk to solve ghosts, that do not bother me anyway. 4 are these sparse columns also taking memtable space? This questions would give me serious pause to use sparse tables On Wednesday, January 9, 2013, Edward Capriolo <edlinuxg...@gmail.com> wrote: > "By no upgrade path" I mean to say if I have a table with compact storage I can not upgrade it to sparse storage. If i have an existing COMPACT table and I want to add a Map to it, I can not. This is what I mean by no upgrade path. > > 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. > 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') > Also for the rest of my comment I meant that the comparator of any sparse tables always seems to be a COMPOSITE even if it is only one part (last I checked). Everything is -COMPOSITE(UTF-8(colname))- at minimum, when in a compact table it is -colname- > My overarching point is the 5 things I listed do have a cost, the user by default gets sparse storage unless they are smart enough to know they do not want it. This is naturally going to force people away from compact storage. > Basically for any column family: two possible decision paths: > 1) use compact > 2) use sparse > Other then ease of use why would I chose sparse? Why should it be the default? > On Wed, Jan 9, 2013 at 5:14 PM, Sylvain Lebresne <sylv...@datastax.com> wrote: >> >> c way. Now I can't pretend knowing what every user is doing, but from >> my experience and what I've seen, this is not such a common thing and CF are >> either static or dynamic in nature, not both. >