Over the last few months I've been summarizing my experiences with NoSQL products. I have been evaluating these products as alternatives to SQL Server to save some licensing costs for one of my clients. I tried to be as objective as possible as I've built my proofs of concept on these products. In every case I'm happy to say that the POCs have been a success but I believe my client will be staying with SQL Server for now. Some of these POCs and posts I have been working on for over a year.
Here are all of the posts in the series:
[[Will MS Licensing Drive Customers to NoSQL?]]: A summary of why I'm doing these POCs and what I hope to accomplish.
[[Are some new SQL Server features a response to the NoSQL movement?]]: Covers some interesting new features of recent SQL Server releases that appear to be directly challenging some of the features of various NoSQL solutions.
[[What exactly is wrong with SQL and RDBMSs?]]: What makes these products so enticing to developers and management?
[[Tutorial D, D, Rel and Their Relation to NoSQL]]: What is driving the NoSQL solution...is it that SQL is just to darn how to use and not really expressive enough for relational problems. I explore some shortcomings of SQL in this post.
[[Data Models and Data Organization Methods]]: compares how data is persisted and modeled in these non-relational models. Don't try to shoehorn a relational design into a NoSQL solution.
[[Eventual Consistency or ACIDs and BASEs]]: You have to give up ACID properties (some of them anyway) when you adopt a NoSQL solution. In their place you get BASE properties. I cover those in this post.
[[Handling Conflicts with Eventual Consistency and Distributed Systems]]: One of the keep tenants of BASE is "eventual consistency". This freaks out ACID people. In this post I'll cover why this isn't so scary if you understand how it works under the covers, and some limitations.
[[The CAP Theorem]]: Consistency, Availability, and Partition Tolerance...you can have 2 of these 3 with any data management platform...RDBMS included. We'll go over which of these you may be able to sacrifice and then which NoSQL products will support your requirements.
[[Sharding]]: Sharding is one of key methods used by NoSQL products to handle CAP and BASE issues. Sharding is more than horizontal partitioning across nodes. I cover sharding in this post.
[[SAP HANA Evaluation]]: This is the first POC I did and it was wildly successful. The SQL syntax is much like TSQL and it really is blazing fast. I'll show you how to setup your own HANA evaluation instance in the cloud.
[[Graph Datastores]]: covers what a graph datastore is and when you might opt to use one.
[[Hekaton]]: briefly goes over this new feature in SQL 2014 and how it is good for some NoSQL applications.
[[Windows Azure Table Service]]: this is a schema-less key-value store that Microsoft offers in the cloud.
[[MapReduce for the RDBMS Guy]]: I go over the minimum that every good relational data architect needs to know about MapReduce.
[[Parallel Data Warehouse as a NoSQL Alternative]]: this is another specialized offering from Microsoft that is very NoSQL-like. It essentially gives you parallelized query execution on multiple nodes.
[[MongoDB and CouchDB]]: this briefly covers my evaluation of schema-less document stores.
[[HBase]]: is a step-up from Hadoop, IMO, for cases where you expect a lot of random reads.
[[Querying NoSQL with Hive and Pig]]: I found HiveQL to be very easy to learn if you understand SQL. This makes MapReduce SO MUCH EASIER to use when you need to get up to speed quickly.
[[More NoSQL Solutions]]: is a brief write-up on some other products we evaluated. We found quickly that they did not meet our requirements so we did not pursue them in earnest, but it's good to know they are available.
[[Apache Flume]]: is how you "stream" data into your Hadoop instance. This is also the easiest way to load test data for POCs.
[[SQL and PostgreSQL as NoSQL alternatives]]: if you are just looking to save on licensing fees you may want to consider an open source alternative to your RDBMS vendor. Or, consider forking the source code and making these alternatives fit your exact requirements...if you are THAT bold.
[[On the Future of NoSQL]]: I make some predictions about the bright future for NoSQL by briefly looking at the history of data management that led us to the ubiquity of relational data management and SQL.
data architecture nosql