Txs Sylvain. Interesting feedback
For now higher consistency level is not fault tolerant (two node setup) but
worth to consider for other deployments.
Further investigation learns that system has quit some iowaits. It seems
that we are pushing it to far.
It is obvious that counter cf's increments
Hi
We are running a Cassandra 1.0.7, 2 node setup on EC2 using ephemeral
disks for storage.
Debugging inconsistent dara between 2 nodes we saw logging below.
Following the counter CF design, I assume this means the READ step
reconciliating the memtable value with the SSTables on the replica
rec
ne row with N columns for each N rows in the original
> CF.
>
>
>
>
> On 05/16/2012 02:58 PM, David Vanderfeesten wrote:
>
> Txs Jeremiah,
> But I am not sure I am following " number of columns could be equal to
> number of rows ". Is native index implement
ning...
- David
On Wed, May 16, 2012 at 6:23 PM, Jeremiah Jordan <
jeremiah.jor...@morningstar.com> wrote:
> The limitation is because number of columns could be equal to number of
> rows. If number of rows is large this can become an issue.
>
> -Jeremiah
>
> --
Hi
I like to better understand the limitations of native indexes, potential
side effects and scenarios where they are required.
My understanding so far :
- Is that indexes on each node are storing indexes for data locally on the
node itself.
- Indexes do not return values in a sorted way (hashes
About this linear scaling of throughput(with keys perfectly distributed +
requests balanced over all nodes):
I would assume that this is not the case for small number of nodes because
starting from 2 nodes onwards a part of the requests have to be handled by a
proxy node + the actual node responsib
On the scaleability and performance side, I found Yahoo's paper about the
YCSB project interesting (benchmarking some NoSQL solutions with MySQL). See
research.yahoo.com/files/*ycsb*.*pdf.
*My concern with the denormalization approach is that it shouldn't be
managed by the client side because this
