Re: GUI clients for Cassandra

[Christophe Schmitz]

MV yes,
SASI not sure, I would guess yes.

On 2 May 2018 at 18:00, Hannu Kröger  wrote:

> Ah, you are correct!
>
> However, it’s not being updated anymore AFAIK. Do you know if it support
> the latest 3.x features? SASI, MV, etc. ?
>
> Hannu
>
>
> On 24 Apr 2018, at 03:45, Christophe Schmitz 
> wrote:
>
> Hi Hannu ;)
>
>
>
>>
>> I have been asked many times that what is a good GUI client for
>>> Cassandra. DevCenter is not available anymore and DataStax has a DevStudio
>>> but that’s for DSE only.
>>>
>>
>  DevCenter is still available, I just downloaded it.
>
> Cheers,
> Christophe
>
>
>
> --
>
> *Christophe Schmitz - **VP Consulting*
>
> AU: +61 4 03751980 / FR: +33 7 82022899
>
>
> 
> 
>
> Read our latest technical blog posts here
> . This email has been sent on behalf
> of Instaclustr Pty. Limited (Australia) and Instaclustr Inc (USA). This
> email and any attachments may contain confidential and legally
> privileged information.  If you are not the intended recipient, do not copy
> or disclose its content, but please reply to this email immediately and
> highlight the error to the sender and then immediately delete the message.
>
>
>


-- 

*Christophe Schmitz - **VP Consulting*

AU: +61 4 03751980 / FR: +33 7 82022899

   



Read our latest technical blog posts here
. This email has been sent on behalf
of Instaclustr Pty. Limited (Australia) and Instaclustr Inc (USA). This
email and any attachments may contain confidential and legally
privileged information.  If you are not the intended recipient, do not copy
or disclose its content, but please reply to this email immediately and
highlight the error to the sender and then immediately delete the message.

RE: [EXTERNAL] Cassandra limitations

[Durity, Sean R]

The issue is more with the number of tables, not the number of keyspaces. 
Because each table has a memTable, there is a practical limit to the number of 
memtables that a node can hold in its memory. (And scaling out doesn’t help, 
because every node still has a memTable for 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 each 
application.


Sean Durity
From: Abdul Patel 
Sent: Thursday, May 03, 2018 5:56 PM
To: User@cassandra.apache.org
Subject: [EXTERNAL] 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 know as data grows we can add more nodes and memory but nor sure about 
somethinh else which need to take into consideration.





The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.

Re: Cassandra limitations

[Abdul Patel]

I have 3 projects in pipeline adding 3 different cluster  across all
environwments would too costly option :)

So 200 tables per keyspace or per cluster?


On Friday, May 4, 2018, Durity, Sean R  wrote:

> The issue is more with the number of tables, not the number of keyspaces.
> Because each table has a memTable, there is a practical limit to the number
> of memtables that a node can hold in its memory. (And scaling out doesn’t
> help, because every node still has a memTable for 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 each
> application.
>
>
>
>
>
> Sean Durity
>
> *From:* Abdul Patel 
> *Sent:* Thursday, May 03, 2018 5:56 PM
> *To:* User@cassandra.apache.org
> *Subject:* [EXTERNAL] 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 know as data grows we can add more nodes and memory but nor sure about
> somethinh else which need to take into consideration.
>
>
>
>
>
> --
>
> The information in this Internet Email is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this Email
> by anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is prohibited and may be unlawful. When addressed
> to our clients any opinions or advice contained in this Email are subject
> to the terms and conditions expressed in any applicable governing The Home
> Depot terms of business or client engagement letter. The Home Depot
> disclaims all responsibility and liability for the accuracy and content of
> this attachment and for any damages or losses arising from any
> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
> items of a destructive nature, which may be contained in this attachment
> and shall not be liable for direct, indirect, consequential or special
> damages in connection with this e-mail message or its attachment.
>

Re: Cassandra limitations

[Jeff Jirsa]

Cluster. The overhead is per cluster.

There are two places you'll run into scaling pain here.

1) Size of the schema (which we have to serialize to send around) - too
many tables, or too many columns in tables, can cause serializing schema to
get really expensive and cause problems
2) Too many memtables - assume that all of them will have some tiny trivial
amount of data in them, maybe 1MB. 200 * 1MB = 200MB of heap just for empty
memtables. If you have a thousand tables, that's a gigabyte of heap, just
for EMPTY memtables.





On Fri, May 4, 2018 at 11:17 AM, Abdul Patel  wrote:

> I have 3 projects in pipeline adding 3 different cluster  across all
> environwments would too costly option :)
>
> So 200 tables per keyspace or per cluster?
>
>
> On Friday, May 4, 2018, Durity, Sean R 
> wrote:
>
>> The issue is more with the number of tables, not the number of keyspaces.
>> Because each table has a memTable, there is a practical limit to the number
>> of memtables that a node can hold in its memory. (And scaling out doesn’t
>> help, because every node still has a memTable for 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 each
>> application.
>>
>>
>>
>>
>>
>> Sean Durity
>>
>> *From:* Abdul Patel 
>> *Sent:* Thursday, May 03, 2018 5:56 PM
>> *To:* User@cassandra.apache.org
>> *Subject:* [EXTERNAL] 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 know as data grows we can add more nodes and memory but nor sure about
>> somethinh else which need to take into consideration.
>>
>>
>>
>>
>>
>> --
>>
>> The information in this Internet Email is confidential and may be legally
>> privileged. It is intended solely for the addressee. Access to this Email
>> by anyone else is unauthorized. If you are not the intended recipient, any
>> disclosure, copying, distribution or any action taken or omitted to be
>> taken in reliance on it, is prohibited and may be unlawful. When addressed
>> to our clients any opinions or advice contained in this Email are subject
>> to the terms and conditions expressed in any applicable governing The Home
>> Depot terms of business or client engagement letter. The Home Depot
>> disclaims all responsibility and liability for the accuracy and content of
>> this attachment and for any damages or losses arising from any
>> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
>> items of a destructive nature, which may be contained in this attachment
>> and shall not be liable for direct, indirect, consequential or special
>> damages in connection with this e-mail message or its attachment.
>>
>

Re: Cassandra limitations

[Abdul Patel]

Thanks ..
So whats ideal number when we should stop ..say 100 ?

On Friday, May 4, 2018, Jeff Jirsa  wrote:

> Cluster. The overhead is per cluster.
>
> There are two places you'll run into scaling pain here.
>
> 1) Size of the schema (which we have to serialize to send around) - too
> many tables, or too many columns in tables, can cause serializing schema to
> get really expensive and cause problems
> 2) Too many memtables - assume that all of them will have some tiny
> trivial amount of data in them, maybe 1MB. 200 * 1MB = 200MB of heap just
> for empty memtables. If you have a thousand tables, that's a gigabyte of
> heap, just for EMPTY memtables.
>
>
>
>
>
> On Fri, May 4, 2018 at 11:17 AM, Abdul Patel  wrote:
>
>> I have 3 projects in pipeline adding 3 different cluster  across all
>> environwments would too costly option :)
>>
>> So 200 tables per keyspace or per cluster?
>>
>>
>> On Friday, May 4, 2018, Durity, Sean R 
>> wrote:
>>
>>> The issue is more with the number of tables, not the number of
>>> keyspaces. Because each table has a memTable, there is a practical limit to
>>> the number of memtables that a node can hold in its memory. (And scaling
>>> out doesn’t help, because every node still has a memTable for 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 each
>>> application.
>>>
>>>
>>>
>>>
>>>
>>> Sean Durity
>>>
>>> *From:* Abdul Patel 
>>> *Sent:* Thursday, May 03, 2018 5:56 PM
>>> *To:* User@cassandra.apache.org
>>> *Subject:* [EXTERNAL] 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 know as data grows we can add more nodes and memory but nor sure about
>>> somethinh else which need to take into consideration.
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> The information in this Internet Email is confidential and may be
>>> legally privileged. It is intended solely for the addressee. Access to this
>>> Email by anyone else is unauthorized. If you are not the intended
>>> recipient, any disclosure, copying, distribution or any action taken or
>>> omitted to be taken in reliance on it, is prohibited and may be unlawful.
>>> When addressed to our clients any opinions or advice contained in this
>>> Email are subject to the terms and conditions expressed in any applicable
>>> governing The Home Depot terms of business or client engagement letter. The
>>> Home Depot disclaims all responsibility and liability for the accuracy and
>>> content of this attachment and for any damages or losses arising from any
>>> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
>>> items of a destructive nature, which may be contained in this attachment
>>> and shall not be liable for direct, indirect, consequential or special
>>> damages in connection with this e-mail message or its attachment.
>>>
>>
>

Re: Cassandra limitations

[Jeff Jirsa]

Depends on heap and size of tables (how many columns).

Have seen many hundreds work fine. Could think of scenarios where dozens
would fail (especially weird schemas or especially small heaps).

On Fri, May 4, 2018 at 11:39 AM, Abdul Patel  wrote:

> Thanks ..
> So whats ideal number when we should stop ..say 100 ?
>
>
> On Friday, May 4, 2018, Jeff Jirsa  wrote:
>
>> Cluster. The overhead is per cluster.
>>
>> There are two places you'll run into scaling pain here.
>>
>> 1) Size of the schema (which we have to serialize to send around) - too
>> many tables, or too many columns in tables, can cause serializing schema to
>> get really expensive and cause problems
>> 2) Too many memtables - assume that all of them will have some tiny
>> trivial amount of data in them, maybe 1MB. 200 * 1MB = 200MB of heap just
>> for empty memtables. If you have a thousand tables, that's a gigabyte of
>> heap, just for EMPTY memtables.
>>
>>
>>
>>
>>
>> On Fri, May 4, 2018 at 11:17 AM, Abdul Patel  wrote:
>>
>>> I have 3 projects in pipeline adding 3 different cluster  across all
>>> environwments would too costly option :)
>>>
>>> So 200 tables per keyspace or per cluster?
>>>
>>>
>>> On Friday, May 4, 2018, Durity, Sean R 
>>> wrote:
>>>
 The issue is more with the number of tables, not the number of
 keyspaces. Because each table has a memTable, there is a practical limit to
 the number of memtables that a node can hold in its memory. (And scaling
 out doesn’t help, because every node still has a memTable for 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
 each application.





 Sean Durity

 *From:* Abdul Patel 
 *Sent:* Thursday, May 03, 2018 5:56 PM
 *To:* User@cassandra.apache.org
 *Subject:* [EXTERNAL] 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 know as data grows we can add more nodes and memory but nor sure
 about somethinh else which need to take into consideration.





 --

 The information in this Internet Email is confidential and may be
 legally privileged. It is intended solely for the addressee. Access to this
 Email by anyone else is unauthorized. If you are not the intended
 recipient, any disclosure, copying, distribution or any action taken or
 omitted to be taken in reliance on it, is prohibited and may be unlawful.
 When addressed to our clients any opinions or advice contained in this
 Email are subject to the terms and conditions expressed in any applicable
 governing The Home Depot terms of business or client engagement letter. The
 Home Depot disclaims all responsibility and liability for the accuracy and
 content of this attachment and for any damages or losses arising from any
 inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
 items of a destructive nature, which may be contained in this attachment
 and shall not be liable for direct, indirect, consequential or special
 damages in connection with this e-mail message or its attachment.

>>>
>>