[
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)
