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