2

I am familiar (on a newbie level) with one-to-many modeling using the concept of "wide rows" and composite keys/columns).

E.g. CREATE TABLE (A text, B text, C text static, D text, PRIMARY KEY ((A),B));

This will make Cassandra store data in a wide row and as an effect a one-to-many model can be used. This article explains it quite well:

http://www.ipponusa.com/blog/modeling-data-with-cassandra-what-cql-hides-away-from-you/

Now, lets say I want to model data as an Aggregate Root, to embrace Eric Evans Domain Driven Design concept, to create a transaction boundary around this aggregate root. An example:

An order has order items, this can easily be modelled using the "wide row" concept out-of-the-box using Cassandra's composite keys/column mentioned above. In this model I can put customer info, payment info and, of course, order items as a "one-to-many relation", all stored in one Cassandra row.

However, what if I want the aggregate root to be a little more complex than that? An aggregate root stored in one Cassandra row with two different one-to-many "relations", an example again:

Object A has many B's and A also has many C's. Is it possible to represent this in Cassandra using the "wide row" concept using composite keys/columns and store such "aggregate root" in one row and then be able to fulfill the "transaction boundary" contract?

Community
  • 1
  • 1
nicgul
  • 237
  • 1
  • 2
  • 10

1 Answers1

0

I'm not familiar with Eric Evans Domain Driven Design concept, but you might want to look into the collection types in Cassandra (i.e. set, list, and maps). They allow you to express multiple one to many relationships in a single row.

You can create user defined types (i.e. structures of data fields), and then use them in the collections. This allows you to create a little database within a single row, and is a way to work around not having joins in Cassandra.

For an example, see this.

Community
  • 1
  • 1
Jim Meyer
  • 9,275
  • 1
  • 24
  • 49
  • So I assume your answer to my question is no, doing it using composite keys/columns? Your answer is interesting though, since I thought of this myself. But, I think there is a limitation on such set/list with UDTs. It is not possible to search on just a single field on the UDT, one has to search on all fields to get a match in the where clause. – nicgul Sep 14 '15 at 16:18
  • This link discusses this limitation, hence I am wondering if it is possible to do this using "wide rows". http://stackoverflow.com/questions/29012661/querying-with-contains-on-a-list-of-user-defined-type-udt – nicgul Sep 14 '15 at 16:25
  • If you want to use partitions (a.k.a. wide rows) instead of collections, then you'd probably be looking at multiple tables, where each table used a different clustering column that you wanted to query on. If you go that route then materialized views might help you to create the extra tables as views. – Jim Meyer Sep 14 '15 at 16:57
  • Alright, thanks Jim! This looks very interesting. With this I probably have to give up the idea of a "complex data model in one row" to maintain the "ACID" "transaction boundary" as mentioned by Evans in Domain Driven Design. I got in to this track since I saw a webinar with Martin Fowler who mentions nosql and aggregate roots in one row to come to come to rescue to accomplish "ACID" transactions. Guess multiple one-to-many is not possible then? – nicgul Sep 14 '15 at 17:27
  • Well I'm not sure why you feel you need ACID transactions or would need extensive search capabilities within collections. Those features are strengths of traditional RDBMS systems, but in many cases they are not actually needed and can be worked around in a distributed model. – Jim Meyer Sep 14 '15 at 23:54
  • I am of course from the RDBMS world and the passage from this world to Cassandra is is hard since it is a fundamental change when designing the application. I need to be comfortable with a lot of writes and make query/view based tables with redundant data. I just thought that in some cases it could be good to have the option, if it exists (and it does to a certain degree with composite key/column). Those cases are most likely rare and one should try to take another approach on the application layer regarding business processes. Domain Driven Design tackles this quite nicely together with CQRS. – nicgul Sep 15 '15 at 05:17