A problem of many keyspaces is clients are bound to a keyspace so
connection pooling multiple keyspaces is an issue. Cql has support for some
limited cross keyspace operations.
On Sunday, July 8, 2012, aaron morton wrote:
> I would do a test to see the latency difference under load between having
I would do a test to see the latency difference under load between having 1 KS
with 5 CF's and 50 KS with 5 CF's.
Your test will need to read and write to all the CF's. Having many CF's may
result in more frequent memtables flushes.
(Personally it's not an approach I would take.)
Cheers
--
Aaron
I am going to have many (over 50 eventually) keyspaces with limited number
of CFs (5-6) do you think this one can cause a problem too.
Thanks
On Fri, Jul 6, 2012 at 2:28 PM, aaron morton wrote:
> Also, all CF's in the same KS share one commit log. So all writes for the
> row row key, acro
Also, all CF's in the same KS share one commit log. So all writes for the row
row key, across all CF's, are committed at the same time.
Some other settings, such as caches in 1.1, are machine wide.
If you have a small KS for something like app config, I'd say go with whatever
feels right. If
Hi Ben,
The amount of keyspaces is not the problem: the amount of column families
is. Each column family adds a certain amount of memory usage to the system.
You can cope with this by adding memory or using generic column families
that store different types of data.
With kind regards,
Robin Verl
