On Wed, May 11, 2011 at 8:06 AM, aaron morton aa...@thelastpickle.comwrote:
For a reasonable large amount of use cases (for me, 2 out of 3 at the
moment) supercolumns will be units of data where the columns (attributes)
will never change by themselves or where the data does not change anyway
Hi,
If you make a supercolumn today, what you end up with is:
- short + Super Column name
- int (local deletion time)
- long (delete time)
Byte array of columns each with:
- short + column name
- int (TTL)
- int (local deletion time)
- long (timestamp)
- int + value of column
That
On Tue, May 10, 2011 at 3:44 PM, Terje Marthinussen
tmarthinus...@gmail.com wrote:
Hi,
If you make a supercolumn today, what you end up with is:
- short + Super Column name
- int (local deletion time)
- long (delete time)
Byte array of columns each with:
- short + column name
- int
Anyway, to sum that up, expiring columns are 1 byte more and
non-expiring ones are 7 bytes
less. Not arguing, it's still fairly verbose, especially with tons of
very small columns.
Yes, you are right, sorry.
Trying to do one thing to many at the same time.
My brain filtered out part of the
For a reasonable large amount of use cases (for me, 2 out of 3 at the moment)
supercolumns will be units of data where the columns (attributes) will never
change by themselves or where the data does not change anyway (archived data).
Can you use a standard CF and pack the multiple columns
