Chris's answer of MySQL does make a lot of sense, indeed. Based on the data you provided
- 5-6 millions rows is not considered as a very large database. - 1,000 row updates per minute (even with 4 indexes) should not be a problem for sure. You can actually achieve 1.5-2k updates "per sec" easily with MySQL and 2+ indexes. - MySQL Master-Slave replication works quite well - sure you can get slaves behind but with 5.1 this is even less of a problem (replication is no longer single-threaded). In 5.0, you can compensate by using SSD drives on the slaves and using prefetch techniques (e.g. google for 'mk-slave-prefetch'). - Be aware that you better have a good case for moving to Cassandra as you will be giving up on the declarative & expressive power of SQL. . data model paradigm shift (think in terms of queries (NoSQL) rather than relations in the case of SQL) . No free lunch in terms of multi-indexing, complex queries, etc. . Eventual consistency vs strict consistency and the difference in performance cost in Cassandra. I suspect you understand this issue if you are dealing with slaves falling behind with MySQL ;-) - On the other hand, Cassandra is great for: . Very intensive write(s) applications . No single point of failure / automatic fail-over . Load balancing . Great read throughput - keep in mind that with a great set-up, you can achieve 10k reads / sec with MySQL. . Horizontal scaling Disclaimer: I'm not MySQL biased and not in love with it either, we use both Cassandra and MySQL (as in NotOnlySQL) but there is a point where MySQL (and sharding) will be too darn challenging and difficult to maintain & evolve. The move comes with a price and some trade-offs but just be certain you really need to make that jump (or/and use both) based on requirements (in the short and long terms). On Wed, Feb 24, 2010 at 12:53 AM, Cemal <cemalettin....@gmail.com> wrote: > Hi, > > Maybe I have to tell that we are very eager to evaluate NoSQL approaches > and for a simple case we want evaluate and compare each approaches. > > In our case actually our data has not been denormalized yet and we are > suffering from a lot of joins. And because of very much updates in joined > tables we have a great performance problems in some situations. Another > difficulty we are dealing with is scaling problem. By now we have been using > master slaves model but in near future it seems that we will come across a > lot of problems. > > By the way I tried to find an article about use cases, pros and cons of > each NoSQL solution but I could not find a detailed explanation about them. > > Thanks > > > > On Wed, Feb 24, 2010 at 10:15 AM, Nathan McCall <n...@vervewireless.com>wrote: > >> The workload you originally described does not sound like a difficult >> job for a relational database. Do you have any more information on the >> specifics of your access patterns and where you feel that an RDBMS >> might fall short? >> >> -Nate >> >>
