@Tyler,
Going back to your earlier proposal i.e.
--
Instead, make the version part of the primary key:
CREATE TABLE document_store (document_id bigint, version int, document
text, PRIMARY KEY (document_id, version)) WITH CLUSTERING ORDER BY (version
desc)
---
My concern with this approach
On Mon, Apr 20, 2015 at 4:02 PM, Sachin Nikam skni...@gmail.com wrote:
#1. We have 2 data centers located close by with plans to expand to more
data centers which are even further away geographically.
#2. How will this impact light weight transactions when there is high
level of network
Tyler,
I can consider trying out light weight transactions, but here are my
concerns
#1. We have 2 data centers located close by with plans to expand to more
data centers which are even further away geographically.
#2. How will this impact light weight transactions when there is high level
of
do you just mean that it's easy to forget to always set your timestamp
correctly, and if you goof it up, it makes it difficult to recover from
(i.e. you issue a delete with system timestamp instead of document version,
and that's way larger than your document version would ever be, so you can
@Eric Stevens
Thanks for representing my position while I came back to this thread.
@Tyler
With your recommendation, won't I end up saving all the version(s) of the
document. In my case the document is pretty huge (~5mb) and each document
has up to 10 versions. And you already highlighted that
I agree with Tyler, in the normal run of a live application I would not
recommend the use of the timestamp, and use other ways to *version*
*inserts*. Otherwise you may fall in the *upsert* pitfalls that Tyler
mentions.
However I find there’s a legitimate use the USING TIMESTAMP trick, when
It's possible, but you'll end up with problems when attempting to
overwrite or delete entries
I'm wondering if you can elucidate on that a little bit, do you just mean
that it's easy to forget to always set your timestamp correctly, and if you
goof it up, it makes it difficult to recover from
In most datacenters you're going to see significant variance in your server
times. Likely 20ms between servers in the same rack. Even google, using
atomic clocks, has 1-7ms variance. [1]
I would +1 Tyler's advice here, as using the clocks is only valid if clocks
are perfectly sync'ed, which
Ok, but if you're using a system of time that isn't server clock oriented
(Sachin's document revision ID, and my fixed and necessarily consistent
base timestamp [B's always know their parent A's exact recorded
timestamp]), isn't the principle of using timestamps to force a particular
update out of
Don't use the version as your timestamp. It's possible, but you'll end up
with problems when attempting to overwrite or delete entries.
Instead, make the version part of the primary key:
CREATE TABLE document_store (document_id bigint, version int, document
text, PRIMARY KEY (document_id,
I am planning to use the Update...USING TIMESTAMP... statement to make sure
that I do not overwrite fresh data with stale data while having to avoid
doing at least LOCAL_QUORUM writes.
Here is my table structure.
Table=DocumentStore
DocumentID (primaryKey, bigint)
Document(text)
Version(int)
If
11 matches
Mail list logo
