Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Shifting from SQL to NoSQL and to which DB?

Tags:

nosql

We recently are having major performance related issues in our current SQL Server DB. Our application is pretty heavy on a single table we did some analysis and about 90% of our db data is in a single table. We run lot of queries on this table as well for analyticall purposes we are experiencing major performance issues now even with a single column addition sometimes slows our current Sp. Most of our teams are developers and we don't have access to a dba which might help in retuning our current db and make things work faster.

Cause of these constraints we are thinking of moving this part of the app to a NoSQL db. My Questions are :

  1. If this is the right direction we are heading ? As we are expecting exponential growth on this table. With loads of analytic's running on it.
  2. Which would be best option for us CouchDB , Cassandra , MongoDB ? With stress on scalability and performance
  3. For real time analysis and support similar to SQL how things work in a NoSQL is there a facility through which we can view current data being stored? I had read somewhere about Hadoop’s HIVE can be used to write and retreive data as SQL from NoSQL db's am I right?
  4. What might be things which we would be losing out of while shifting from SQL to NoSQL ?
like image 327
Nikshep Avatar asked Oct 16 '11 05:10

Nikshep


People also ask

Can you migrate from SQL to NoSQL?

When migrating from SQL to NoSQL, the primary key in the relational table becomes the partition key in the NoSQL table. If the RDBMS table must be joined to additional tables to retrieve the business object, those closely related tables should combine into a single NoSQL table.

When should I move to a NoSQL database?

The structure of many different forms of data is more easily handled and evolved with a NoSQL database. NoSQL databases are often better suited to storing and modeling structured, semi-structured, and unstructured data in one database.

Which scenario you prefer NoSQL DB instead of SQL DB?

NoSQL makes it easy to store all different types of data together and without having to invest time into defining what type of data you're storing in advance. Your data needs scale up, out, and down. As discussed above, NoSQL provides much greater flexibility and the ability to control costs as your data needs change.

In what ways is an SQL database different from a NoSQL database?

SQL databases are vertically scalable, while NoSQL databases are horizontally scalable. SQL databases are table-based, while NoSQL databases are document, key-value, graph, or wide-column stores. SQL databases are better for multi-row transactions, while NoSQL is better for unstructured data like documents or JSON.


3 Answers

To your questions:

1.. If this is the right direction we are heading ? As we are expecting exponential growth on this table. With loads of analytic's running on it.

Yes, most of the noSQL systems are developed specifically to address scalability and availability, if you use them in the intended way.

2.. Which would be best option for us CouchDB , Cassandra , MongoDB ? With stress on scalability and performance

This depends entirely on what does your data looks like and how you will use it. The noSQL db you mentioned are implemented and behaves very differently from each other, see this link for a more detailed overview comparing the few you mentioned. Comparisons of noSQL solution

3.. For real time analysis and support similar to SQL how things work in a NoSQL is there a facility through which we can view current data being stored? I had read somewhere about Hadoop’s HIVE can be used to write and retreive data as SQL from NoSQL db's am I right?

This depends on the system you go with, because some noSQL db doesn't support range queries or joins, you are restricted in what you can view and how fast you can view.

4.. What might be things which we would be losing out of while shifting from SQL to NoSQL?

There are two major considerations for noSQL:

Query/Structure: NoSQL means no SQL. If your system actually requires structured and complex queries but you went with one of these cool new solution (especially a key-value storage, which is basically a giant hash table), you may soon find yourself in the middle of re-implementing a amateurish, ill-designed RDBMS, with all of your original problems.

Consistency: If you choose a eventual consistent system to scale horizontally, then you will have to accept your data being outdated, which may be harmless to some applications (forums?) or horrible in some other systems (bank).

like image 193
Desmond Zhou Avatar answered Nov 03 '22 00:11

Desmond Zhou


I think you should stay relational and tune the table, its indexes, and the tables it joins to. You should also consider the use of aggregated (summarized data). Perhaps a more denormalized design would help or even re-designing the data into more of a star structure. Also, operational processing and decision support (or reporting) analyses should not be run on the same tables.

like image 43
TomFH Avatar answered Nov 03 '22 01:11

TomFH


It might be possible to improve the SQL approach by checking for missing indexes etc and also seeing if the isolation level you are using is optimal. It may be possible to use snapshot isolation etc to improve performance. MSDN link

Read up on OLTP vs OLAP also.

NoSQL may still be a better option but you would still need to learn how to work with the database properly, it will come with another different set of issues.

like image 32
Steven Avatar answered Nov 03 '22 02:11

Steven