On Fri, Feb 21, 2014 at 11:51 AM, Sylvain Lebresne <sylv...@datastax.com>wrote:
> On Thu, Feb 20, 2014 at 10:49 PM, Rüdiger Klaehn <rkla...@gmail.com>wrote: > >> Hi Sylvain, >> >> I applied the patch to the cassandra-2.0 branch (this required some >> manual work since I could not figure out which commit it was supposed to >> apply for, and it did not apply to the head of cassandra-2.0). >> > > Yeah, some commit yesterday made the patch not apply cleanly anymore. In > any case, It's not committed to the cassandra-2.0 branch and will be part > of 2.0.6. > > >> The benchmark now runs in pretty much identical time to the thrift based >> benchmark. ~30s for 1000 inserts of 10000 key/value pairs each. Great work! >> > > Glad that it helped. > > Thanks for the quick fix. I was really starting to get irritated when the people at SO basically told me that there is something wrong in my code. > >> I still have some questions regarding the mapping. Please bear with me if >> these are stupid questions. I am quite new to Cassandra. >> >> The basic cassandra data model for a keyspace is something like this, >> right? >> >> SortedMap<byte[], SortedMap<byte[], Pair<Long, byte[]>> >> ^ row key. determines which server(s) the rest is stored >> on >> ^ column key >> ^ >> timestamp (latest one wins) >> ^ >> value (can be size 0) >> > > It's a reasonable way to think of how things are stored internally, yes. > Though as DuyHai mentioned, the first map is really sorting by token and in > general that means you use mostly the sorting of the second map concretely. > > Yes, understood. So the first SortedMap is sorted on some kind of hash of the actual key to make sure the data gets evenly distributed along the nodes? What if my key is already a good hash: is there a way to use an identity function as a hash function (in CQL)? I am thinking about some kind of content addressed storage, where the key is a 20 byte SHA1 hash of the data (like in git). Obviously this is already a pretty good hash. > >> So if I have a table like the one in my benchmark (using blobs) >> >> CREATE TABLE IF NOT EXISTS test.wide ( >> time blob, >> name blob, >> value blob, >> PRIMARY KEY (time,name)) >> WITH COMPACT STORAGE >> >> From reading http://www.datastax.com/dev/blog/thrift-to-cql3 it seems >> that >> >> - time maps to the row key and name maps to the column key without any >> overhead >> - value directly maps to value in the model above without any prefix >> >> is that correct, or is there some overhead involved in CQL over the raw >> model as described above? If so, where exactly? >> > > That's correct. > For completeness sake, if you were to remove the COMPACT STORAGE, there > would be some overhead in how it maps to the underlying column key, but > that overhead would buy you much more flexibility in how you could evolve > this table schema (you could add more CQL columns later if needs be, have > collections or have static columns following CASSANDRA-6561 that comes in > 2.0.6; none of which you can have with COMPACT STORAGE). Note that it's > perfectly fine to use COMPACT STORAGE if you know you don't and won't need > the additional flexibility, but I generally advise people to actually check > first that using COMPACT STORAGE does make a concrete and meaningful > difference for their use case (be careful with premature optimization > really). > In this case I am confident that the schema will not change. But there will be other tables built from the same data where I am not going to use compact storage. cheers, Rüdiger
