Note that there are some explanatory texts on larger screens.

plurals
  1. POModeling order managment in cassandra
    text
    copied!<p>I am new to cassandra &amp; nosql modeling, I had a usecase where in I wish to model an order management solution, a very common usecase in RDBMs to Cassandra. In our use cases our application receives multiple order items at different span of time. Each needs to be stored for auditing puropse and needs to be grouped to detail out the order summary and other business details. Also, we wish to keep the order items attributes to be searchable so that this can be looked up.</p> <p>I have thought of two approaches:</p> <p>1) <strong>Based on composite key pattern</strong>: Here I shall save the order items as is with all order items attributes as column and one column family 'order items' with key as (orderid + timestamp).</p> <ul> <li>oid1:01012012 -> oid:oid1, event:new, type:request, ...</li> <li>oid1:01012012 -> oid:oid1, event:ok, type:response, ...</li> <li>oid1:02012012 -> oid:oid1, event:modified, type:request, ...</li> </ul> <p>2) <strong>Fat row design</strong>: Here keeping orderid as row key and all the order items are persisted as json strings. This will be used for auditing purpose. Another column family shall be used to keep a structure as ( Rowkey -> colA1:a1, colB1:b1, colA2:a2, colB2:b2, ...) with 1,2.. index we shall be able to track all the order items.</p> <p>A friend of mine has suggested #1 will not be very good at performance. Since different rows with same orderid can reside on different nodes of cassandra ring. While I am finding #2 to be a clumsy design where I need to keep multiple copy of the same data. Also could not think of how searching can be implemented on top of #2 design.</p> <p>Any idea on how can this be designed better?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload