CODEWITHSUNDEEP
mysqlsqldatabaseperformancenosql
Rajat Gupta
Rajat Gupta

Reputation: 26617

Two types of data, so two type of databases?

For a social network site, I need to propose a DB. The application is written in Java & will be hosted on VPS(s) initially.

Broadly classified there is two type of data to be stored at backend:

 1. dynamic lists which are:

     - frequently appended to   
     - frequently read       
     - sometimes reduced    

 2. fixed set of data keyed by a primary key(sometimes modified).

 "For serving any page, I need to have access to both kind of data!"

As demanded by every other SN site, we need to consider for easy scaling in the future, but in addition to that our team & resources are also very very limited. We would like to start with a 1 or 2 medium sized VPS(s) & add more servers as data & load grows.

Personally I usually prefer something that is used by a large community, so ofcourse MySQL is big option but it doesn't fit our entire needs. It could be used for 2nd kind of data(among the list above) ie for storing fixed set of columns/data but not ideal for storing dynamic lists(ie 1st kind). So should I use a 2nd database just to fit in only that type of data (two database each containing only data best suited for them)? (Some suggested Cassandra to store the 2nd kind of data.) What is the way to go ?

Upvotes: 1

Views: 134

Answers (1)

Burhan Khalid
Burhan Khalid

Reputation: 174758

Use a traditional database when you need transactional integrity and you have a fixed set of relations to map.

Use a document database when you have multiple properties of objects to store in a flat structure; or where the schema (the properties of the objects) may change over time. This is one of the weaknesses of traditional database systems; changing schemas is possible but has lots of performance side-effects. In document databases, the properties of the object being stored have little impact on the overall performance of the system - and more practically the information stored about objects (their properties or "columns") can be modified without having to worry about schemas.

Use a key value store for ephemeral data.

From what you have described, I don't see any use case that would require a relational database.

Upvotes: 1

Related Questions