If you are talking about scaling: Cassandra scaling is absolutely horizontal without namenodes or other Mongo-bulshit-like intermediate daemons. And that’s why one big cluster has the same throughput as many smaller clusters. What will you do when your small clusters will exceed it’s capacity? Cassandra is designed for very large data so feel free to utilize it’s capabilities.
If you are talking in terms of business logic: it make sense to divide, i.e. metadata and really BIG data into different clusters, of course. From: Wz1975 [mailto:wz1...@yahoo.com] Sent: 14 октября 2013 г. 7:20 To: user@cassandra.apache.org Subject: Re: one big cluster vs multiple smaller clusters Importance: Low we have choices of making one big cluster vs a few small clusters. I am trying to get pros and cons for both options in genera. Thanks. -Wei Sent from my Samsung smartphone on AT&T -------- Original message -------- Subject: Re: one big cluster vs multiple smaller clusters From: Jon Haddad <j...@jonhaddad.com<mailto:j...@jonhaddad.com>> To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> CC: This is a pretty vague question. What are you trying to achieve? On Oct 12, 2013, at 9:05 PM, Wei Zhu <wz1...@yahoo.com<mailto:wz1...@yahoo.com>> wrote: Hi, As we bring more use cases to Cassandra, we have been thinking about the best way to host it. Let's say we will have 15 physical machines available, we can use all of them to form a big cluster or divide them into 3 clusters with 5 nodes each. As we will deploy to 1.2, it becomes easier to expand the cluster with vnodes. I really don't see any good reasons to make 3 smaller clusters. Did I miss anything obvious? Thanks. -Wei
