Why nosql with cassandra instead of mysql?

问题:

I work on large database (hundreds of GB) and Mysql now gives me more or less satisfaction. I hesitate to cassandra on launch.

What I want to know everything before, so this kind of DBMS NoSQL is supposed to be faster than MySQL?

Several points:

• The change in the number of column on a row In Mysql, they must all be defined in advance. The columns set in the structure of the table. NoSQL in, they can be varied. There is real difference performance on a fixed structure ? and why ?

• Do not make the relationship is beneficial for performance. Ok but I am not obliged to make a relational table Mysql. I use aggregated tables, ie tables that contain only data derived from other tables, I to prevent the joints which are too expensive. Again what level performance differences if I use this model in Mysql? To take one example, the author of http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/ insert X number of times the follower in the message USERLINE pusher. I could do that in MySQL.

• Scalability, scalability, scalability ... I like it, do cassandra allow me to store my data on different servers (without SAN) ? I am not talking here of replication, I speak of a single NoSQL server across multiple physical server.

• Live at the calculations. MySQL provides functions like me as SUM, AVG ... that are very useful to avoid me to re-aggregating my data in other tables. I have not seen equivalent cassandra ?

• What about the indexes. On Mysql I index several fields in one. For example my tables have a primary key on multiple columns and I select are in functionaly. cassandra on how to write it? The concatenated for a single identifier for each row? I think I have not completely grasped the management of indexes. Are recalculated for the integration or upstream?

• The asynchronous requests. A false argument that it seems to me, Mysql can be done with INSERT / UPDATE LOW_PRIORITY.

I think I go around. Thank you to enlighten me.

回答1:

I really don't understand why people compare data providers like Cassandra and MySQL together -- you're really comparing apples and oranges here.

Yes, NoSQL solutions can give better performance than SQL in some cases. But don't forget the reason they provide that speed -- they give up on several of the checks that you often take for granted in SQL. For example, you will not see things like transactions in a NoSQL system, nor are you going to have the kinds of joins and data aggregation features that you get as part of a SQL system. You get very few guarantees with respect to consistency of the data.

For 99% of applications it's simply not worth the time and effort. If you are facebook or twitter, where you have enormous quantities of unstructured data, where you don't care if you actually lose some data in the shuffle of things, or have delays with respect to when data is available after it is inserted, NoSQL is just fine. However, for the vast majority of applications, you should still be sticking with SQL.

As for scalability, if an enormous site like Stack Overflow or Ebay can run on top of SQL, I don't see why your application cannot run on top of SQL.

回答2:

Yes, you can definitely tune a MySQL to give you performance by cutting down a lot of the overheads. NoSQL cuts out the overheads by not having the feature to enable them in the first place.

The applications of NoSQL are very different from traditional SQL structure. SQLs are by default tuned for OLTP performance with normalized schema structures and the ability to have join queries etc. NoSQL on the other hand is a good fast read/write structure. A really good example would be an activity feed on twitter/facebook (I don't know if Twitter/FB use NoSQL I'm just taking an example).

回答3:

playOrm is helping more and more OLTP systems get on top of noSQL systems. It is very SQL like but there are differences. You do need to partition tables that you expect to grow to VERY LARGE sizes and can then query into those partitions. You can even do joins on partitions. You keep your partition sizes the same size as typical RDBMS tables and you can scale to your hearts desire.

so for you indexing and calculation questions, I think more and more tools will be built on nosql systems. Anyways, that may be one solution to your issues.