views:

725

answers:

5

Hi! I have huge database (kinda wordnet) and want to know if it's easier to use Cassandra instead of MySQL|PostrgreSQL

All my life I was using MySQL and PostrgreSQL and I could easily think in terms of relational algebra, but several weeks ago I learned about cassandra and that it's used in Facebook and Twitter.

Is it more convenient?

What DBMS are usually used nowadays to store social net's data, relationships between objects, wordnet?

A: 

All different products and they all have their pro's and conn's. What kind of problem do you have to solve?

Huge, as in TB's?

Frank Heikens
E.g I have set of objects and weights of connections btw these objects. I want to find all possible paths and their weights btw any 2 objects quickly.
Ivri
+3  A: 

There are many different flavours of "NoSQL" databases. If your application is really like Wordnet perhaps you should look at a graph database such as Neo4j.

APC
+2  A: 

I would suggest to analyse your request.

  1. If you are going with more clusters, machines take NoSQL
  2. If your data model is complicated - require efficient structures take NoSQL (no limits with type of columns)
  3. If you fit in a few machines without scales, and you don't need super performance for multi request (as for example in social network - where lot of users send http request), and you don't think you involve saleability take RDBMS (Postgres have some good functions and structures which you can use, like array column type).

Cassandra should work better with large scales of data, multi purpose. neo4j - would be better for special structures, graphs.

+2  A: 

Cassandra and other NoSQL stores are being used for social based sites because of their need for massive write based operations. Not that MySQL and Postgres can't achieve this but NoSQL requires far less time and money, generally speaking.

Sounds like you may want to look at Neo4J though, just in terms of your object model needs.

Mark
A: 

A nice article about the NoSQL-movement: http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html

Frank Heikens