25

So I have a website that could eventually get some pretty high traffic. My DB implementation is in SQL Server 2008 at the moment. I really only have 2 tables and a few stored procs. Most of the DB could be re-designed to work without joining (although it wouldn't make sense when I can join so easily within SQL Server).

I heard that sites like Digg and Facebook use NoSQL databases for a lot of their basic data access. Is this something worth looking into, or will SQL Server not really slow me down that bad?

I use paging on my site (although this might change in the future), and I also use AJAX'd data access for most of the "live" stuff, so it doesn't really seem to be a performance hindrance at the moment, but I'm afraid it will be as the data starts expanding exponentially.

Am I going to gain a lot of performance my moving to NoSQL? Honestly, right now I don't even completely understand NoSQL, so any tips on how this will help me improve the better.

Thanks guys.

slandau
  • 23,528
  • 42
  • 122
  • 184
  • Possible duplicate: http://stackoverflow.com/questions/1145726/what-is-nosql-how-does-it-work-and-what-benefits-does-it-provide – RThomas Jun 06 '11 at 20:54
  • Possible duplicate of [What is NoSQL, how does it work, and what benefits does it provide?](http://stackoverflow.com/questions/1145726/what-is-nosql-how-does-it-work-and-what-benefits-does-it-provide) – Trevor Boyd Smith Feb 20 '17 at 15:42

5 Answers5

43

Actually Facebook use a relational database at its core, see SOCC Keynote Address: Building Facebook: Performance at Massive Scale. And so do many other web-scale sites, see Why does Quora use MySQL as the data store instead of NoSQLs such as Cassandra, MongoDB, CouchDB etc?. There is also a discussion of how to scale SQL Server to web-scale size, see How do large-scale sites and applications remain SQL-based? which is based on MySpace's architecture (more details at Scale out SQL Server by using Reliable Messaging). I'm not saying that NoSQL doesn't have its use cases, I just want to point out that there are many shades of gray between white and black.

If you're afraid that your current solution will not scale then perhaps you should look at what are the factors that prevent scalability with your current solution. Test data is cheap to produce, load the 'exponentially increased' data volume and run your test harness, see where it cracks. None of the NoSQL solutions will bring magic off-the-shelf scalability, they all require you to understand how to use them effectively and deploy them correctly. And they also require you to test with large volumes if you want to ensure success at scale. Same for traditional relational solutions.

Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
  • 1
    Yes, yes, a million times yes. – HLGEM Jun 07 '11 at 18:08
  • Another interesting SQL case study (newrelic using mysql to store 200 Billion Data Points a Day to Disk) - http://www.slideshare.net/jthurman42/getting-100b-metrics-to-disk – Anoop Jun 10 '15 at 05:56
8

Sql Server scales pretty well. For example, Stack Overflow used it to serve you this very page. Facebook and Google might use a form of nosql, but even if you make it really big you're unlikely to rise to that level.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
7

With a simple table structure and data that fits on one server, it doesn't matter much what platform you use. There are a several possible reasons to need to move to NoSQL:

  • Data scaling - SQL works best when all the data fits on one server (up to a few TB). The reason a lot of NoSQL stores don't have join is that they were designed not to require all the objects to be on one server.

  • Performance scaling - NoSQL stores do tend to be faster at handling high traffic, but not necessarily by enough to matter. You can improve SQL performance quite a lot with replication and caching as long as you aren't running into data size issues. Writes generally do have to run on the one server, but in most cases you will need to improve read performance long before write performance becomes an issue.

  • Complex data access - some types of queries simply don't fit well into a relational model. Graph and set stores work quite differently from relational databases so are a better fit for some applications.

  • Easier development - If you don't already have a SQL database and all the code to support it, using a schemaless datastore can save quite a bit of development time.

Tom Clarkson
  • 16,074
  • 2
  • 43
  • 51
  • You can benefit a lot from a NoSQL also in a one-server small-data scenario. Usually due to the scema-less nature of NoSQLs which results in shorter development cycles and faster data access (no ORMs) – synhershko Jun 07 '11 at 10:12
  • NoSQLs like RavenDB for example would let you write your Model for serving website content via MVC, and then just use the same POCOs for storage. You practically have no datalayer, so 75% of development time that is usually spent on DB modelling is saved. Performance and data scaling are very good by default, but can be easily tuned since it was designed to support sharding and replication, where in SQL it seems more like a hack. – synhershko Jun 07 '11 at 10:21
  • Pretty much what I meant with the 4th point. Being hundreds of times faster than the previous SQL based solution is the main reason I use redis, but the development experience comes close. It doesn't remove the data layer as much as you suggest though - I have some objects that exist in both the data store and the MVC views, but for anything beyond basic CRUD view models end up with quite different requirements from data objects. – Tom Clarkson Jun 07 '11 at 12:35
  • Perhaps for some NoSQL solutions more than others... the sample I brought up was a real-world one... – synhershko Jun 07 '11 at 12:40
  • As is mine - though admittedly my system is fairly complex and what the user sees is quite different from the internal structure that is optimised for search and data aggregation rather than a one to one mapping to pages. It does still help a lot with the more basic objects though, and there are certainly plenty of sites out there that don't really need a complex data layer. Not quite none, but a lot closer to it than you get with SQL infrastructure requirements. – Tom Clarkson Jun 07 '11 at 12:51
1

I don't think so you have to move your database from SQL to NoSQL unless and untill you are serving thousands of TB data. If you properly normalize your tables and serve the data and also need to set proper archive mechanism it should work.

If you still have question what to choose and how, than check this. Let's assume that you have decided to move on to NoSQL database than there are lot of market player. Just have a look at the list which is again depending upon your need and type of data you have.

Virat Gaywala - CSM
  • 657
  • 1
  • 8
  • 11
0

Am I going to gain a lot of performance my moving to NoSQL?

It depends.

Check out this article for 7 reasons when you DON'T want to use NoSQL. If none is your case, then read further.

The main advantage of Document-based NoSQL for the traditional enterprise needs is cheaper hosting at high scale due to lower CPU usage on querying denormalised data (the most often request). Key points:

  • The CPU is going nuts on JOINs and GROUP BYs in the SQL queries, when a denormilised data structure implies no/less JOINs, hence less stress on CPU.
  • CPU is the most expensive resource in the cloud, then storage is the cheapest. And denormalised data trades higher storage for lower CPU.

How to get there?

  1. Master the DDD (Domain-Driven Design).
  2. Gain good understanding of CQRS (Command Query Responsibility Segregation) and Eventual consistency.
  3. Understand your domain and business processes.
  4. Design model, which is tuned to the access patterns.
  5. Review.
  6. Repeat steps 3 - 5.
Alex Klaus
  • 8,168
  • 8
  • 71
  • 87