Help me Learn

(5 posts) (2 voices)

• Started 1 year ago by
• Latest reply from
• This topic is not a support question

Tags:

• data model
• key
• noob
• order by
• sort

1. 

   Anonymous
   Unregistered

   Ok... Very new to Cassandra. Still trying to wrap my head around how it works. Let me start with a super simple table.

   This is a table matching car license plates to vehicle owners. Tag numbers are unique and will be the most looked-up value so that will be my primary key. For simplicity's sake, let's also assume people's names are a single word and unique as well. I get this:

   Tag | Owner
   -----------
   211 | Jack
   112 | David
   313 | Suzanne
   114 | Jack
   227 | Mike
   472 | Adam
   552 | Mike
   102 | Jason

   As you can see, Jack and Mike both have two cars, and everyone else only has one.

   Now, here are my questions:

   * How would I get a list of all tag numbers in ascending order?
   * How would I get a list of all tag numbers held by Jack? In ascending order?
   * How would I get a list of all the owners in alphabetical order?
   * What if this was on a web page showing 2 names at a time. How do I get the next two and so on? In order?
   * Knowing I need the above information in the above forms in advance, how do I set this ColumnFamily (???) up in Cassandra in the most optimum fashion?

   Thanks in advance for helping out a Cassandra noob!!!

   Posted 1 year ago #
2. 

   zznate
   

   Read this first: http://www.datastax.com/docs/1.0/ddl/index

   Not intended to be an RTFM, but the above should answer all your questions and give you an overview of how Cassandra stores data on disk (and taking advantage of this in your data model to minimize disk seeks).

   In short, a very good place to start.

   If you have specific questions after reading the above, I will be happy to answer them.

   Posted 1 year ago #
3. 

   Anonymous
   Unregistered

   I read that already... And it gives a nice overview of the structure itself and such, but it is by no means clear. For instance, though there are secondary indexes defined in this example, it doesn't explain if those indexes let me then request sorted data in a response based on those columns. And time_ordered_blogs_by_user??? I understand that this column family has something to do with getting information sorted, but it is not explained just sort of dropped in there, and there are no code examples.

   Given that, I believe all my original questions are still valid and I still need them answered.

   Posted 1 year ago #
4. 

   zznate
   

   To satisfy those queries you are looking at 2 column families:

   TagsByDriver
   - comparator would be the UTF8Type to maintain the columns sorted alphabetically by name
   - column name is the driver name, value could be a serialized list of 1 or more tags

   TagIndex
   - using, in this trivial example, LongType comparator to order the columns by tag
   - column name is the tag, column value the driver name

   Both of these column families need row keys still. In the above example we are treating these as indexes, taking advantage of the comparator sort order to minimize disk seeks. Cassandra can store 2 billiion columns in a single row, but because a row is the unit of distribution in the cluster, this would create hot spots where a single node would hold all the results.

   To avoid this we would have to 'bucket' results in such a way that makes them easier to break up. In the above, the row keys could be the first two characters of the name and tag number respectively. We still have some hotspot potential here, so you would want to play with this bucketing a bit depending on distribution of results.

   If you need a higher level search - say all drivers starting with N, then you would create all the 26 potential combinations and issue a multiget_slice as opposed to a get_slice (the former retrieving N keys at a time). Same with tag: for 102 to 104 you would issue a multiget_slice for 102,103,104.

   There are several other ways to do this, but this example is the most approachable, IMO. Because we are relying on a column index of the comparator, lookups - even for a large number of users in order - only consist of two disk seeks: one to locate the row, the next to seek to the column position. The read is then sequential regardless of the number of results.

   To "page" over results, use the following approach:
   1. initial get_slice with a slicepredicate containing null for start and end with a limit of 2
   2. use the last result of the above get_slice as the "start" for the next get_slice and set the limit to 3 (N+1)
   3. skip the first result (since you displayed it last time [though seemingly dumb, this is sort of fundamental to a distributed columnar datastore where you 'don't know what you have until you have it])
   4. go to step 2 with results from 3

   Posted 1 year ago #
5. 

   Anonymous
   Unregistered

   Ok... So you can have a single "row" with a bunch of "columns" and no "values". I can see how this might be useful... But please elaborate on the contents of the third paragraph (Both of these column fam...). In this example, why would you want to create a setup with just a single row and a ton of columns? Why not make it a single column with a ton of rows?

   Posted 1 year ago #

RSS feed for this topic