every table.)
>>>> The practical table limit I have heard is in the low hundreds – maybe 200
>>>> as a rough estimate.
>>>>
>>>>
>>>>
>>>> In general, we create a new cluster (instead of a new keyspace) for
>>>
200
>>> as a rough estimate.
>>>
>>>
>>>
>>> In general, we create a new cluster (instead of a new keyspace) for each
>>> application.
>>>
>>>
>>>
>>>
>>>
>>> Sean Durity
>>>
>>&g
limit I have heard is in the low hundreds – maybe 200 as a
>> rough estimate.
>>
>>
>>
>> In general, we create a new cluster (instead of a new keyspace) for each
>> application.
>>
>>
>>
>>
>>
>> Sean Durity
>>
&g
gt; rough estimate.
>
>
>
> In general, we create a new cluster (instead of a new keyspace) for each
> application.
>
>
>
>
>
> Sean Durity
>
> *From:* Abdul Patel
> *Sent:* Thursday, May 03, 2018 5:56 PM
> *To:* User@cassandra.apache.org
> *Sub
] Cassandra limitations
Hi ,
In my environment, we are coming up with 3 to 4 new projects , hence new
keyspaces will be coming into picture.
Do we have any limitations or performance issues when we hit to a number of
keyspaces or number of nodes vs keyspaces?
Also connections limitations if any?
I
Hi ,
In my environment, we are coming up with 3 to 4 new projects , hence new
keyspaces will be coming into picture.
Do we have any limitations or performance issues when we hit to a number of
keyspaces or number of nodes vs keyspaces?
Also connections limitations if any?
I know as data grows we
On Wed, May 12, 2010 at 2:02 AM, David Vanderfeesten wrote:
>...
>
> My concern with the denormalization approach is that it shouldn't be managed
> by the client side because this has big impact on your throughput. Is the
> map-reduce in that respect any better?
> Wouldn't it be nice to support a
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
On Mon, May 10, 2010 at 1:23 PM, Peter Hsu wrote:
> Thanks for the response, Paul.
> ...
>
> * Cassandra and its siblings are weak at ad hoc queries on tables
> that you did not think to index in advance
>
> What is the normal way of dealing with this in Cassandra? Would you just
> create a new "
Thanks for the response, Paul.
Very helpful, but very general at the same time. I'm still having trouble
translating these into actual use cases.Let me think of some better
questions before I continue the thread, but I'd like to address one of the
weaknesses you brought up:
> * Cassandra
Also:
* you should Google "eventual consistency" to learn about the
strengths and weaknesses of that.
On Mon, May 10, 2010 at 11:22 AM, Paul Prescod wrote:
> This is a very, very big topic. For the most part, the issues are
> covered in the various SQL versus NoSQL debates all over the Internet
This is a very, very big topic. For the most part, the issues are
covered in the various SQL versus NoSQL debates all over the Internet.
For example:
* Cassandra and its NoSQL siblings have no concept of an in-database "join"
* Cassandra and its NoSQL siblings do not allow you to update
multipl
I've seen a lot of threads and posts about why Cassandra is great. I'm fairly
sold on the features, and the few big deployments on Cassandra give it a lot of
credibility.
However, I don't believe in magic bullets, so I really want to understand the
potential downsides of Cassandra. Right now,
13 matches
Mail list logo
