NoSQL DBMS Platform
(Redirected from NoSQL)
- It can be used to create NoSQL Database Instance.
- It can range from being an In-Memory NoSQL DBMS Framework (in-memory DBMS) to being a ...
- It can range from being a Key-Value DBMS to being a Document-Oriented DBMS.
- It can range from being an On-Prem NoSQL DBMS Platform to being a Cloud-based NoSQL DBMS Platform.
- See: Document-Oriented DBMS, BASE Transaction, NoSQL Service, Data Loss, Horizontal Scaling, Cluster Computing.
- Kiran Thapa, February 21, 2018
- QUOTE: To begin with, there are not a lot of differences between Key Value and Document Type No-SQL databases. Key Value DBs are considered for more ‘primitive’ data type agnostic use cases i.e it really does not matter to your application whether you store a blob, xml, json or any other data types. Document Type databases, on the other hand offer specialized capabilities built around the pre-understanding of data types in the value field. Eg. MongoDB/Mapr-DB supports JSON and offer auto-indexing of JSON fields. ...
- QUOTE: Then two new Internet giants made breakthroughs, and developed their own distributed non-relational systems to help with this new onslaught of data: MapReduce (published 2004) and Bigtable (published 2006) by Google, and Dynamo (published 2007) by Amazon. These seminal papers led to even more non-relational databases, including Hadoop (based on the MapReduce paper, 2006), Cassandra (heavily inspired by both the Bigtable and Dynamo papers, 2008) and MongoDB (2009). Because these were new systems largely written from scratch, they also eschewed SQL, leading to the rise of the NoSQL movement.
- (Wikipedia, 2016) ⇒ http://wikipedia.org/wiki/NoSQL Retrieved:2016-3-2.
- A NoSQL (originally referring to "non SQL" or "non relational"  ) database provides a mechanism for storage and retrieval of data which is modeled in means other than the tabular relations used in relational databases. Such databases have existed since the late 1960s, but did not obtain the "NoSQL" moniker until a surge of popularity in the early twenty-first century,triggered by the needs of Web 2.0 companies such as Facebook, Google and Amazon.com.   Motivations for this approach include: simplicity of design, simpler "horizontal" scaling to clusters of machines (which is a problem for relational databases), and finer control over availability. The data structures used by NoSQL databases (e.g. key-value, wide column, graph, or document) are different from those used by default in relational databases, making some operations faster in NoSQL. The particular suitability of a given NoSQL database depends on the problem it must solve. Sometimes the data structures used by NoSQL databases are also viewed as "more flexible" than relational database tables.  NoSQL databases are increasingly used in big data and real-time web applications. NoSQL systems are also sometimes called "Not only SQL" to emphasize that they may support SQL-like query languages. Many NoSQL stores compromise consistency (in the sense of the CAP theorem) in favor of availability, partition tolerance, and speed. Barriers to the greater adoption of NoSQL stores include the use of low-level query languages (instead of SQL, for instance the lack of ability to perform ad-hoc JOINs across tables), lack of standardized interfaces, and huge previous investments in existing relational databases. Most NoSQL stores lack true ACID transactions, although a few databases, such as MarkLogic, Aerospike, FairCom c-treeACE, Google Spanner (though technically a NewSQL database), Symas LMDB and OrientDB have made them central to their designs. (See ACID and JOIN Support.) Instead, most NoSQL databases offer a concept of "eventual consistency" in which database changes are propagated to all nodes "eventually" (typically within milliseconds) so queries for data might not return updated data immediately or might result in reading data that is not accurate, a problem known as stale reads.  Additionally, some NoSQL systems may exhibit lost writes and other forms of data loss.  Fortunately, some NoSQL systems provide concepts such as write-ahead logging to avoid data loss.  For distributed transaction processing across multiple databases, data consistency is an even bigger challenge that is difficult for both NoSQL and relational databases. Even current relational databases "do not allow referential integrity constraints to span databases."  There are few systems that maintain both ACID transactions and X/Open XA standards for distributed transaction processing.
- http://nosql-database.org/ "NoSQL DEFINITION: Next Generation Databases mostly addressing some of the points: being non-relational, distributed, open-source and horizontally scalable"
- http://www.eventbrite.com/e/nosql-meetup-tickets-341739151 "Dynamo clones and BigTables"
- http://www.wired.com/2012/01/amazon-dynamodb/ "Amazon helped start the “NoSQL” movement."
- http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html "Customers like SimpleDB’s table interface and its flexible data model. Not having to update their schemas when their systems evolve makes life much easier"
- Martin Zapletal: Large volume data analysis on the Typesafe Reactive Platform, ScalaDays 2015, Slides
- http://www.dummies.com/how-to/content/10-nosql-misconceptions.html "NoSQL databases lose data" section