A few quick comments:
* its not clear what column family the super column you're using is in.
* it might be useful to include the timestamps in the columns (since
they're user-supplied)
* given that the colon-delimited api has been removed, it might be
easier to explain the data model without
It's impossible to implement offset either performantly or safely in a
distributed log-structured merge system that supports deletes. The
original API punted on all three of those. 0.4 doesn't. See
https://issues.apache.org/jira/browse/CASSANDRA-261 for a discussion
of performance (we decided
Pagination is an extremely common use case scenario in web app programming.
almost every web app need “one to many” data model. when the “many” part is
too many to fit in one page, paginate is the best way to resolve it. in most
case, we don't need query or sort the result in a complicated
Thanks for taking a stab at this, Mark.
I'm not a fan of teaching this by showing CF-spanning rows. (The
bigtable paper does this IIRC but it's wrong. :)
You can have data in different CFs with the same key, yes, but all
that means is they will be stored on the same nodes. Each CF is
stored
FWIW: I find that the only sane way to visually represent a data model
is to use a JSON-ish notation.
Picture type visualizations confuse me even more.
I don't mean to be a downer but me and a lot of my peers found all the
picture type visual aides even more confusing
-arin
aka: phatduckk
On
On Thu, Aug 13, 2009 at 5:12 PM, Arin Sarkissiana...@rspot.net wrote:
FWIW: I find that the only sane way to visually represent a data model
is to use a JSON-ish notation.
Picture type visualizations confuse me even more.
I don't mean to be a downer but me and a lot of my peers found all the
