One issue that will be encountered with this data model is the unbounded
partition growth. Partition will continue to grow indefinitely over time
and there will be a risk to hit the limit of 2 billions columns per
partition.
Consider a composite partition key.
Thanks,
Gedeon
On Wed, May 17,
Hi Nandan,
If there is a requirement to answer a query "What are the changes to a book
made by a particular user?", then yes the schema you have proposed can
work. To obtain the list of updates for a book by a user from the
*book_title_by_user* table will require the partition key (*book_title*),
Hi Jon,
We need to keep tracking of all updates like 'User' of our platform can
check what changes made before.
I am thinking in this way..
CREATE TABLE book_info (
book_id uuid,
book_title text,
author_name text,
updated_at timestamp,
PRIMARY KEY(book_id));
This table will contain details about
Sorry, I hit return a little early. What you want is called "event
sourcing": https://martinfowler.com/eaaDev/EventSourcing.html
Think of it as time series applied to state (instead of mutable state)
CREATE TABLE book (
name text,
ts timeuuid,
author text,
primary key(bookid, ts)
);
for
I don't understand why you need to store the old value a second time. If
you know that the value went from A -> B -> C, just store the new value,
not the old. You can see that it changed from A->B->C without storing it
twice.
On Tue, May 16, 2017 at 6:36 PM @Nandan@
