I have a 30+ node cluster that is under heavy read and write load. Based on
the fact that we never delete data, and all data is inserted with TTLs and is
somewhat temporal if not upserted, and we are fine with the consistency of one
and read repair chance, we elected to never repair. The
I have to come up with a “event dupe check” system that handles race conditions
where two requests come in at the same time. Obviously this can be solved with
lightweight transactions (if not exists), however I am concerned that there may
be costs/issues hidden to me for doing significant
in that regard?
Wayne
On Aug 13, 2014, at 1:10 PM, Robert Coli
rc...@eventbrite.commailto:rc...@eventbrite.com wrote:
On Wed, Aug 13, 2014 at 9:16 AM, Wayne Schroeder
wschroe...@pinsightmedia.commailto:wschroe...@pinsightmedia.com wrote:
Are there hidden costs to LWT (paxos
I've been doing a lot of reading on SSTable fragmentation due to updates and
the costs associated with reconstructing the end data from multiple SSTables
that have been created over time and not yet compacted. One question is stuck
in my head: If you re-insert entire rows instead of updating
I found a lot of documentation about the read path for key and row caches, but
I haven't found anything in regard to the write path. My app has the need to
record a large quantity of very short lived temporal data that will expire
within seconds and only have a small percentage of the rows
Perhaps I should clarify my question. Is this possible / how might I
accomplish this with cassandra?
Wayne
On Mar 31, 2014, at 12:58 PM, Robert Coli
rc...@eventbrite.commailto:rc...@eventbrite.com
wrote:
On Mon, Mar 31, 2014 at 9:37 AM, Wayne Schroeder
wschroe
As I understand it, even though a quorum write fails, the data is still (more
than likely) saved and will become eventually consistent through the well known
mechanisms. I have a case where I would rather this not happen--where I would
prefer that if the quorum write fails, that data NEVER
The plan IS to do the whole write as a lightweight transaction because I do
need to rely on the behavior. I am just vetting the expected behavior--that
doing it as a conditional update, i.e. a light weight transaction, that I am
not missing something and it will behave as I outlined without
After upgrading to the 2.0 driver branch, I received a lot of warnings about
re-preparing previously prepared statements. I read about this issue, and my
work around was to cache my prepared statements in a MapString,
PreparedStatement internally in my app via a common prepare method, where
that I am expecting. This is obviously
specific to my application, but hopefully it helps anyone who has followed that
pattern as well.
Wayne
On Feb 28, 2014, at 12:18 PM, Wayne Schroeder wschroe...@pinsightmedia.com
wrote:
After upgrading to the 2.0 driver branch, I received a lot
I have some conditional insert/update operations that set quorum consistency.
I was using this with the 1.0 driver, back before the 2.0 features required the
2.0 driver. Now that I'm on the 2.0 driver, I have found the new
setSerialConsistencyLevel routine for statements. Multiple places it
11 matches
Mail list logo
