2

I am developing a system which has multiple modules,

  1. Social Media User Demography - (Document) - Name, loc, interests, work, education
  2. Social Media User Connections - (Graph) - friends
  3. CRM - (Rows and Columns) - telecom + banking etc

to name a few. I'm pretty sure that I have already crossed millions of records in each one of them.

When I look for a NoSql database to choose from I have at least 10 in each category. For Document database I have a arraylist right from MongoDB to DjonDB. Its the same case when I look for a graph database, so on and so forth. And also I have seen other key value store databases, columnar databases etc to name a few at http://nosql-database.org/.

So I wanted to know are there any generic thumb rules that I should follow to choose among these databases, when a columnar DB is optimized, to what type of data does a key value store suits best etc..

What are the best suited databases for what type of data and why? and most importantly What are the worst suited databases for what type of data and why?

Thanks

Ken White
  • 123,280
  • 14
  • 225
  • 444
rishiehari
  • 384
  • 5
  • 13

1 Answers1

2

This is a very open question, but I'll give it a shot.

Some things to keep in mind:

  1. Pick a database that has a great (not good, great) community around it. You might find FooDB and it claims to do everything you want, but it no one is contributing to it, then you'll have built your application around a dead technology. You want active contributions, lots of customers with production deployments and ideally something not in its first version.

  2. Try to find technologies that play well together. For example, Elastic Search, MongoDB, CouchDB, Couchbase all more or less work with JSON. That should help you narrow your choices of technologies.

  3. I wouldn't try and spread myself too thin. Each type of database (graph, document, row/column, key value pair) has it's own learning curve. It takes quite a while to learn how to model data in a denormalized fashion. The more variety you have, the harder it will be to maintain all those different databases.

  4. I don't know why I rarely see this as advice, but I would pick something you actually like developing in. Does the query syntax seem intuitive and fun? If not, you're going to hate developing in it. This isn't the most important factor, but I think it should be considered.

ryan1234
  • 7,237
  • 6
  • 25
  • 36