2011/1/25 Wangpei (Peter)
> for your 1-node cluster, ANY is the only consistency level that client
> may returns BEFORE node write to memory table.
>
> And read op on the node read both the memory table and SSTable.
>
>
>
> It real puzzle me. :(
>
Please don't be puzzled just yet. :-)
As I sa
@cassandra.apache.org; hector-us...@googlegroups.com
主题: Re: Basic question on a write operation immediately followed by a read
2011/1/25 Wangpei (Peter)
mailto:peter.wang...@huawei.com>>
What is the ConsistencyLevel value? Is it ConsistencyLevel.ANY?
I am using Hector 0.7.0-22 and getting keysp
2011/1/25 Wangpei (Peter)
> What is the ConsistencyLevel value? Is it ConsistencyLevel.ANY?
>
>
I am using Hector 0.7.0-22 and getting keyspace as *
HFactory.createKeyspace()*, which seems to be defaulting the consistency
level to QUORAM for both reads and writes.
Nowhere else, it is explicitly
> Is there a possibility that my read operation may miss the data that just got
inserted?
If write operation did not resulted in exception and there was no other clients
writing to the same row/column concurrently - you will read exactly what you
just written.
>
> Since there are no DB transactio
han Dawrani [mailto:roshandawr...@gmail.com]
发送时间: 2011年1月25日 10:57
收件人: user@cassandra.apache.org; hector-us...@googlegroups.com
主题: Basic question on a write operation immediately followed by a read
Hi,
I have a basic question - maybe silly too.
Say, I have a 1-node Cassandra setup (no replication, eventual
2011/1/25 Patricio Echagüe
> Roshan, when a client invoke a write, the write goes first to commit log
> and later to memtable. After that it returns to the client.
>
> After it reaches the memtable, that data is ready to be read.
>
> The reads consolidates de data from the memtables and sstables
Roshan, when a client invoke a write, the write goes first to commit log and
later to memtable. After that it returns to the client.
After it reaches the memtable, that data is ready to be read.
The reads consolidates de data from the memtables and sstables unless there
is a hit in the row cache.
Thanks for your inputs, Victor.
In my app, it's a bit event driven.
We do writes and fire events and listeners then read - so we can't predict
how soon the reads will come. Sometimes they came too fast, which is better
for our app, if we can have a Cassandra DB level understanding that they
won't
On Tue, Jan 25, 2011 at 9:57 AM, Victor Kabdebon
wrote:
> As far as I remember, please correct me if I am wrong, on a one node
> cluster :
> First Commitlog is updated then almost immediatly after order is send to
> the memtable to add this new insert. You might have a very short delay
> between t
to
memtables both have happened?
I am asking because if it is a), then is it is possible that a read
operation happens after commit log has been written to, but memtables are
not updated yet? (I assume reads are off memtables and not take into account
what is in commit logs)
Basic question again is
On Tue, Jan 25, 2011 at 9:32 AM, Victor Kabdebon
wrote:
> Roshan, just remember, what you do on a one node cluster might not be valid
> on a 5 node cluster. Depending on the way your insert and query (QUORUM,
> ALL, ... ) your data might not be available to get, yet it will be in your
> cluster. I
dvantage of Cassandra : the data is inserted and
> "ready to use" immediately after it has been received by the node.
>
> Best Regards,
> Victor Kabdebon
> http://www.voxnucleus.fr
>
> 2011/1/24 Roshan Dawrani
>
> Hi,
>>
>> I have a basic quest
Hi,
I have a basic question - maybe silly too.
Say, I have a 1-node Cassandra setup (no replication, eventual consistency,
etc) and I do an insert into a column family and then very close in time to
the insert, I do a read on it for the same data.
Is there a possibility that my read operation
Even without machines being down, the guarantee Cassandra gives you is
exactly the ConsistencyLevel. Everything else is best-effort. In
particular if you hammer Cassandra with more requests than it can
fulfill, it will drop some instead of, say, running out of memory
trying to queue them all up.
Okay, this helps. Cassandra works as I expected in the theoretically "pure"
case (writing to the rest of the replicas in a background thread).
I asked the question because we've been struggling to understand why we're
seeing inconsistencies when we haven't had nodes go down, etc. (However,
even
> When we do a delete on a column in the above configuration, the call to the
> server won't return until 2 of the 3 replicas are written to unless there's
> an error. That part is well-documented and understood. The question I have
> is whether or not the last of the 3 replica nodes gets the del
I've been searching on wikis and FAQs for a definitive answer to this and
haven't found it yet so I thought I'd ask people here.
We have a 5-node cluster set up with a replication factor of 3. We're doing
write operations (using batch mutates that include deletions) with a QUORUM
consistency leve
On Thu, Apr 8, 2010 at 12:09 AM, Palaniappan Thiyagarajan
wrote:
> I am investigating how we can use Cassandra in our application. We have
> tokens and session information stored in db now and I am thinking of moving
> to Cassandra. Currently it’s write and read intensive and having
> performan
All,
I am investigating how we can use Cassandra in our application. We have tokens
and session information stored in db now and I am thinking of moving to
Cassandra. Currently it's write and read intensive and having performance
issue. Is it good idea to move couple of tables and integrate
19 matches
Mail list logo
