You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2016/02/15 12:42:18 UTC

[jira] [Resolved] (CASSANDRA-9149) nodes slow down when having too many column families

     [ https://issues.apache.org/jira/browse/CASSANDRA-9149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne resolved CASSANDRA-9149.
-----------------------------------------
    Resolution: Later

I'm closing this because there is no particular interest in focusing on improving working with multiple thousands of tables. There is definitively implementation details that make this unsuitable in C*, like the fact each memtable pre-allocate some memory, or the fact that schema manipulation is currently pretty inefficient with too many table in a given keyspace.  

Don't get me wrong, I'm not saying that if you come up with patches that improve performance with thousands of tables (_without_ impacting performance when you have less table) we won't be interested (and please do feel free to open more specific tickets if you have specific suggestions), just that this is not something that is being actively looked at, mostly because we believe it is always possible to model things so they don't need that many tables.

> nodes slow down when having too many column families
> ----------------------------------------------------
>
>                 Key: CASSANDRA-9149
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9149
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: ZhaoYang
>
> When working with a few thousand column families, the nodes(2-3) slow down a lot.  In my case, the number of column families will continue increase. 
> Currently, some advice is like modeling(*hacking*) data to fit in smaller number of column families. But this method really didn't work well due to lack of atomicity and bad performance.  
> Is there a way to solve it or improve it in future release? It's okay to make the cluster a bit slower, as long as not too slow. Any suggestions are welcome.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)