Dr. Edgar Codd, the inventor of relational theory wrote in 1986 (thirty years ago): “Only if the performance requirements are extremely severe should buyers rule out present relational DBMS products on this basis.” Of course, he was comparing relational databases with pre-relational databases (which had the performance advantage over relational databases in 1986). But Dr. Codd’s argument are equally valid today in the SQL v/s NoSQL debate. Oracle Corporation openly admits that NoSQL database management systems have the performance advantage over relational database management systems “when data access is ‘simple’ in nature and application demands exceed the volume or latency capability of traditional data management solutions.” In other words, Oracle Corporation admits that there are use cases which current relational database management systems cannot handle well. Click-stream data from high-volume web sites, high-throughput event processing, social networking communications, monitoring online retail behavior, accessing customer profiles, pulling up appropriate customer ads, and storing, and forwarding real-time communication are the examples listed by Oracle Corporation. Database professionals should therefore look seriously at NoSQL technology.
Where to start? I recommend that you read my article The Rise and Fall of the NoSQL Empire. It is very negative about NoSQL but I recommend that you treat it as the starting point of your investigation. My article is based on a twelve-part series of blog posts called “The Twelve Days of NoSQL” (also recommended reading) written in December 2013. Chris Date had some comments on my article which you can read in the May 2015 issue of the NoCOUG Journal. The chief concept that you need to understand is “functional segmentation” though I find that it is hardly—if ever—used in discussions of NoSQL. If you don’t understand functional segmentation, you will not understand NoSQL. Another reason to start with my article is that NoSQL database management systems are rapidly changing in ways that you will find extremely hard to understand if you are not well grounded in what NoSQL is about. For example, Amazon DynamoDB looks very different than its parent Amazon Dynamo and supports what it calls “tables” but each such “table” is—strictly speaking—a “functional segment.” There are even NoSQL query languages that mimic SQL: CQL (Cassandra Query Language), N1QL (Non-1st Query Language) (pronounced Nickel), and UnQL (Unstructured Query Language) (pronounced Uncle).
Once you have a proper grounding in NoSQL fundamentals, you are ready to get your feet wet. You could take Oracle NoSQL Database for a spin. Check out the resources page. There is also a Five-Minute Quickstart. Note that Oracle NoSQL Database divides a key into “major path” or “minor path” (all "records" with the same major path are stored in the same shard) because its developers did not understand the whole NoSQL concept—they confused NoSQL with the “entity-attribute-value” model (as evidenced in the examples provided to explain the concept).