Jump to content

NoSQL

Википедиа — Чөлөөт нэвтэрхий толь
12:01, 8 Дөрөвдүгээр сар 2017-ий байдлаарх ErkaIS (хэлэлцүүлэг | оруулсан хувь нэмэр) хэрэглэгчийн хийсэн залруулга

NoSQL("SQL бус", "Дан ганц SQL ч биш", "харьцаа хамаарлын бус" хэмээн нэрлэгдэх нь бий) өгөгдлийн сан нь[1] харьцаа өгөгдлийн сангийн хүснэгтэн загвараас загвар, ажиллагааны хувьд өөр байдлаар өгөгдлийг хадгалах, буцаан татаж авах механизмаар хангадаг. Ийм төрлийн өгөгдлийн сан нь 1960 - аад оноос хойш оршиж байсан авч, Web 2.0(Facebook, Google, Amazon.com гэх мэт) - ын хэрэгцээнээс үүдэн 21 - р зууны эхэн үеэс "NoSQL" хэмээх нэршил нь олон нийтийн дунд өргөн тархасан юм..[2][3][4] Өнөө үед NoSQL өгөгдлийн сангууд нь их-өгөгдөл, бодит-хугацааны веб аппликейшнүүд дээр өргөнөөр ашиглагдаж байгаа.[5] NoSQL системүүдийг зарим тохиолдолд "Дан ганц SQL ч биш" хэмээн дууддаг нь  SQL-төсөөт квери хэлнүүдийг дэмждэгтэй холбоотой.[6][7]

Уг аргачлалыг хэрэглэх үндэслэл: Энгийн загвар, тархсан төхөөрөмжүүдийн хувьд "босоо" өргөжүүлэлт хийхэд хялбар (харьцаа өгөгдлийн сангийн хувьд хэцүү),[8] and finer control over availability. NoSQL өгөгдлийн сан дээр хэрэглэгддэг өгөгдлийн бүтэц(түлхүүр-утга, өргөн багана, граф, баримт бичиг гэх мэт) нь энгийн харьцаа өгөгдлийн сангууд дээр хэрэглэгддэгээс өөр бөгөөд тэр утгаараа зарим үйлдлүүд NoSQL дээр илүү хурдан гүйцэтгэгддэг. NoSQL өгөгдлийн санг ашиглах нь зохимжтой эсэх нь тухайн шийдэх гэж буй асуудлаас хамаарна. NoSQL өгөгдлийн санд хэрэглэгддэг өгөглийн бүтэц нь харьцаа өгөгдлийн сангийн хүснэгтэн бүтцээс ч уян хатан хэмээн тодорхойлогдох тохиолдол бий.[9]

Ихэнх NoSQL агуулах нь тогтвортой(CAP - ын теоромын хувьд) байдлын хувьд тогтмол байдаг бөгөөд   (in the sense of the CAP theorem) in favor of availability, partition tolerance, and speed. NoSQL агуулахыг нэвтрүүлэхэд тулгардаг томоохон саадуудаас нэрлэбэл: доод түвшиний квери хэл ашигладаг(SQL - ын оронд), стандарт интерфэйсийн хувьд дутагдмал, одоо оршин байгаа харьцаа өгөгдлийн сангаас NoSQL рүү шилжихэд ихээхэн хэмжээний хөрөнгө оруулалт шаардана.[10] Ихэнх NoSQL агуулах нь ACID гүйлгээний хувьд дутагдалтай байдаг ч, MarkLogic, AeroSpike,  airCom c-treeACE, Google Spanner (техникийн талаасаа бол NewSQL өгөгдлийн сан), Symas LMDB, OrientDB хэмээх хэд хэдэн агуулах нь ACID - ыг гол төвөө болгосон.

Үүний оронд, ихэнх NoSQL өгөгдлийн сан нь "хожим тогтворжилт" хэмээх концептийг хэрэгсдэг бөгөөд өгөгдлийн сангийн өөрчлөлт нь бүхий л зангилаа(node) - нууд руу "аажимдаа" хуулагдах юм. Тэгснээр квери шинэчлэгдсэн өгөгдлийг тэр даруй илгээхгүй байх магадлалтай бөгөөд, квериний хүсэлтийн дагуу ирсэн үр дүн оновчтой биш байж болох юм(энэхүү асуудлыг хожуу уншилт хэмээн нэрийддэг). [11] Мөн түүнчлэн, зарим нэг NoSQL систем нь дутуу бичилт хийх, эсхүл өөр төрлийн өгөгдлийн алдагдал үүсгэдэг .[12] Азаар зарим нэг NoSQL систем нь өгөгдөл алдагдлаас сэргийлэх үүднээс "бичихээс-урьтаж тэмдэглэ" хэмээх зарчимыг ашигладаг.[13] Нэгээс олон өгөгдлийн сан дээр хийгдэх тархсан гүйлгээ боловсруулалтын хувьд, өгөгдлийн тогтвортой байдал нь NoSQL битгий хэл харьцаа өгөгдлийн санд хүртэл томоохон асуудлын тоонд ордог. Бүр одоо хэрэглэгдэж байгаа харьцаа өгөгдлийн сангийн хувьд хүртэл тархсан өгөгдлийн сангуудын хувьд нягт хамаарлыг(ө.х гадаад түлхүүрээр холбогдох) зөвшөөрдөггүй.[14] ACID гүйлгээ, X/Open Xa стандартыг тархсан гүйлгээ боловсруулалтын хувьд хангадаг цөөн хэдхэн систем бий.

Үүсэл хөгжил

The term NoSQL was used by Carlo Strozzi in 1998 to name his lightweight, Strozzi NoSQL open-source relational database that did not expose the standard Structured Query Language (SQL) interface, but was still relational.[15] His NoSQL RDBMS is distinct from the circa-2009 general concept of NoSQL databases. Strozzi suggests that, because the current NoSQL movement "departs from the relational model altogether, it should therefore have been called more appropriately 'NoREL'",[16] referring to 'No Relational'.

Johan Oskarsson, then a developer at Last.fm, reintroduced the term NoSQL in early 2009 when he organized an event to discuss "open source distributed, non relational databases".[17] The name attempted to label the emergence of an increasing number of non-relational, distributed data stores, including open source clones of Google's BigTable/MapReduce and Amazon's Dynamo. Most of the early NoSQL systems did not attempt to provide atomicity, consistency, isolation and durability guarantees, contrary to the prevailing practice among relational database systems.[18]

Based on 2014 revenue, the NoSQL market leaders are MarkLogic, MongoDB, and Datastax.[19] Based on 2015 popularity rankings, the most popular NoSQL databases are MongoDB, Apache Cassandra, and Redis.[20]

Төрөл, жишээ NoSQL өгөгдлийн сан

There have been various approaches to classify NoSQL databases, each with different categories and subcategories, some of which overlap. What follows is a basic classification by data model, with examples:

  • Column: Accumulo, Cassandra, Druid, HBase, Vertica, SAP HANA
  • Document: Apache CouchDB, ArangoDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB
  • Key-value: Aerospike, ArangoDB, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, InfinityDB, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB
  • Graph: AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog
  • Multi-model: Alchemy Database, ArangoDB, CortexDB, Couchbase, FoundationDB, InfinityDB, MarkLogic, OrientDB

A more detailed classification is the following, based on one from Stephen Yen:[21]

Төрөл Жишээ(харгалзах төрлийн)
Key-Value Cache Coherence, eXtreme Scale, GigaSpaces, GemFire, Hazelcast, Infinispan, JBoss Cache, Memcached, Repcached, Terracotta, Velocity
Key-Value Store ArangoDB, Flare, Keyspace, RAMCloud, SchemaFree, Hyperdex, Aerospike, quasardb
Key-Value Store (Eventually-Consistent) DovetailDB, Oracle NoSQL Database, Dynamo, Riak, Dynomite, MotionDb, Voldemort, SubRecord
Key-Value Store (Ordered) Actord, FoundationDB, InfinityDB, Lightcloud, LMDB, Luxio, MemcacheDB, NMDB, Scalaris, TokyoTyrant
Data-Structures Server Redis
Tuple Store Apache River, Coord, GigaSpaces
Object Database DB4O, Objectivity/DB, Perst, Shoal, ZopeDB
Document Store ArangoDB, Clusterpoint, Couchbase, CouchDB, DocumentDB, IBM Domino, MarkLogic, MongoDB, Qizx, RethinkDB, XML-databases
Wide Column Store BigTable, Cassandra, Druid, HBase, Hypertable, KAI, KDI, OpenNeptune, Qbase

Correlation databases are model-independent, and instead of row-based or column-based storage, use value-based storage.

Key-value(түлхүүр-утгат) агуулах

Key-value(KV) агуулах нь холбоот массивыг(мап, dictionary/толь бичиг гэдгээрээ мөн танигдсан) өгөгдлийн загварынхаа гол цөм болгож ашигладаг . Энэ загварт, өгөгдөл нь түлхүүр түүнд харгалзах утгын хосмогуудын бүрдлээр дүрслэгддэг бөгөөд боломжит түлхүүр бүр бүрдэлд нэг л оршино.[22][23]

Key-value загвар нь энгийн хэрнээ гүйцэтгэл сайтай буюу баялаг өгөгдлийн загвар нь ихэвчлэн үүний extension буюу нэмэлт байдлаар орж ирдэг. Key-value загвар нь толь зүйн эрэмбээр түлхүүрүүдийг хадгалдаг салангид эрэмбэлэгдсэн загвар руу өргөжих боломжтой. Энэ нэмэлт нь сонгосон түлхүүрийн завсардах утгыг үр бүтээмжтэйгээр илгээхдээ тооцооллын хувьд хүчирхэг юм .[24]

Key-value stores can use consistency models ranging from eventual consistency to serializability. Some databases support ordering of keys. There are various hardware implementations, and some users maintain data in memory (RAM), while others employ solid-state drives or rotating disks.

Жишээ систем: ArangoDB, InfinityDB, Oracle NoSQL Database, Redis, dbm.

Баримт бичигт агуулах(Document store)

Баримт бичигт агуулахын гол ойлголт нь "баримт бичиг" юм. While each document-oriented database implementation differs on the details of this definition, in general, they all assume that documents encapsulate and encode data (or information) in some standard formats or encodings. Encodings in use include XML, YAML, and JSON as well as binary forms like BSON. Documents are addressed in the database via a unique key that represents that document. One of the other defining characteristics of a document-oriented database is that in addition to the key lookup performed by a key-value store, the database offers an API or query language that retrieves documents based on their contents.

Different implementations offer different ways of organizing and/or grouping documents:

  • Collections
  • Tags
  • Non-visible metadata
  • Directory hierarchies

Compared to relational databases, for example, collections could be considered analogous to tables and documents analogous to records. But they are different: every record in a table has the same sequence of fields, while documents in a collection may have fields that are completely different.

Граф

This kind of database is designed for data whose relations are well represented as a graph consisting of elements interconnected with a finite number of relations between them. The type of data could be social relations, public transport links, road maps or network topologies.

Граф өгөгдлийн сан ба түүний квери хэл
Нэр Хэл(нүүд) Тэмдэглэл
AllegroGraph SPARQL RDF triple store
ArangoDB AQL, JavaScript Multi-model DBMS Document, Graph database and Key-value store
DEX/Sparksee C++, Java, .NET, Python Graph database
FlockDB Scala Graph database
IBM DB2 SPARQL RDF triple store added in DB2 10
InfiniteGraph Java Graph database
MarkLogic Java, JavaScript, SPARQL, XQuery Multi-model document database and RDF triple store
Neo4j Cypher Graph database
OWLIM Java, SPARQL 1.1 RDF triple store
Oracle SPARQL 1.1 RDF triple store added in 11g
OrientDB Java, SQL Multi-model document and graph database
Sqrrl Enterprise Java Graph database
OpenLink Virtuoso C++, C#, Java, SPARQL Middleware and database engine hybrid
Stardog Java, SPARQL Graph database

Объект өгөгдлийн сан

  • db4o
  • GemStone/S
  • InterSystems Caché
  • JADE
  • ObjectDatabase++
  • ObjectDB
  • Objectivity/DB
  • ObjectStore
  • ODABA
  • Perst
  • OpenLink Virtuoso
  • Versant Object Database
  • ZODB

Хүснэгтэн

  • Apache Accumulo
  • BigTable
  • Apache Hbase
  • Hypertable
  • Mnesia
  • OpenLink Virtuoso

Тюпл агуулах

  • Apache Голын
  • GigaSpaces
  • Tarantool
  • TIBCO ActiveSpaces
  • OpenLink Virtuoso

Гурвалсан агуулах (RDF) өгөгдлийн сан

  • AllegroGraph
  • Apache JENA (фрэймворк, өгөгдлийн сан биш)
  • MarkLogic
  • Ontotext-OWLIM
  • Oracle NoSQL өгөгдлийн сан
  • Virtuoso Бүх Нийтийн Сервер
  • Stardog

Hosted

  • Amazon DynamoDB
  • Amazon SimpleDB
  • Datastore on Google Appengine
  • Clusterpoint database
  • Cloudant Data Layer (CouchDB)
  • Freebase
  • Microsoft Azure Tables[25]
  • Microsoft Azure DocumentDB[26]
  • OpenLink Virtuoso

Олон утгат өгөгдлийн сан

  • D3 Pick database
  • Extensible Storage Engine (ESE/NT)
  • InfinityDB
  • InterSystems Caché
  • jBASE Pick database
  • Northgate Information Solutions Reality, the original Pick/MV Database
  • OpenQM
  • Revelation Software's OpenInsight
  • Rocket U2

Олон загварт өгөгдлийн сан

  • ArangoDB
  • Couchbase
  • FoundationDB
  • MarkLogic
  • OrientDB

Чадамж

Бэн Скофилд NoSQL өгөгдлийн сангийн төрлүүдийг дараах байдлаар үнэлжээ:[27]

Өгөгдлийн загвар Чадамж Өргөсгөх боломж Уян хатан чанар Төвөгтэй байдал Функциональ хамаарал
Key–value store сайн сайн сайн байхгүй олон янз (байхгүй)
Column-oriented store сайн сайн дунд муу маш бага
Document-oriented store сайн олон янз (сайн) сайн муу олон янз (муу)
Graph database олон янз олон янз сайн сайн графын онол
Relational database олон янз олон янз муу дунд харьцаа алгебр


Харьцаа өгөгдлийг зохицуулах нь

Ихэнх NoSQL өгөгдлийн сан нь квериний хувьд холбох чадвараар дутмаг байдаг тул, өгөгдлийн сангийн схем нь өөр байдлаар загварчлагдах хэрэгцээ гарна. NoSQL өгөгдлийн санд харьцаа өгөгдлийг зохицуулах үндсэн 3 техник бий.

Давхар квери

Бүх өгөгдлийг нэг кверигээр татаж авахын оронд, хүссэн өгөгдлөө хэд хэдэн квери ашиглан татаж авах юм. NoSQL квери нь ихэвчлэн уламжлалт SQL кверинээс хурдан байдаг тул, нэмэлт квери ажиллуулах нь зардлын(цаг зарцуулалт г.м) хувьд хүлээн зөвшөөрөгдөхүйц хэмжээнд байх магадлалтай . If an excessive number of queries would be necessary, one of the other two approaches is more appropriate.

Кэшлэлт, хуулбарлалт, энгийн хэлбэрт шилжээгүй өгөгдөл

Дан ганц гадаад түлхүүрийг хадгалахгүйгээр, загварын өгөгдөлтэй хамт бодит гадаад утгыг хадгалах нь олонтаа. Жишээлбэл, блог дээрх коммент бүрд хэрэглэгчийн ID - аас гадна хэрэглэгчийн нэр багтсан гэж үзье, хэрэв зээ тэгж давхар хадгалсан бол хэрэглэгчийн нэр рүү нэмэлт хайлт хийхгүйгээр маш хялбараар хандах боломжтой болно. Хэдий тийм ч, хэрэглэгчийн нэр өөрчлөгдвөөс, өгөгдлийн сан дахь маш олон хэсгүүд дээр давхар өөрчлөгдөх хэрэг гарна. Тиймээс энэхүү аргыг өгөгдлийн сан дээр бичилтээс илүүтэй уншилт ихээр хийгдэж байгаа үед ашиглах нь тохиромжтой.[28]

Өгөгдлийг шигтгэх

MongoDB мэтийн баримт бичигт өгөгдлийн сангуудийн хувьд жижиг хэмжээний цуглуулганд илүү их хэмжээний өгөгдөл хийх нь олонтаа. Жишээ нь, блогийн аппликейшний хувьд үзвэл, one might choose to store comments within the blog post document so that with a single retrieval one gets all the comments. Тиймээс энэ аргын хувьд тодорхой үйлдлийн хувьд хэрэгтэй бүх мэдээллийг нэг баримт бичигт хадгалах юм.

ACID, холболт дэмждэг эсэх

Өгөгдлийн сан нь ACID, эсхүл холболтийг дэмждэг хэмээн тэмдэглэгдсэн байвал, тухайн өгөгдлийн сангийн баримт бичиг нь түүний баталгаа нь болно. 

Database ACID Joins
Aerospike Тийм Үгүй
ArangoDB Тийм Тийм
CouchDB Тийм Тийм
c-treeACE Тийм Тийм
HyperDex Тийм[nb 1] Тийм
InfinityDB Тийм Үгүй
LMDB Тийм Үгүй
MarkLogic Тийм Тийм[nb 2]
OrientDB Тийм Тийм
  1. ↑ HyperDex дээр худалдааны add-on болох Warp нэмэлтийг ашиглан ACID - ыг дэмждэг болгох боломжтой
  2. ↑ Баримт бичигт өгөгдлийн сан дээр холболт хийх шаардлагагүй ч, MarkLogic дээр семантик(утга зүй) ашиглан холболт хийх боломжтой.[29]

Уншвал зохих

  • CAP - ын тёором
  • Объект өгөгдлийн сан удирдах системүүдийн харьцуулалт
  • Бүтэцлэгдсэн хадгалах програм хангамжуудын харьцуулалт 
  • Хамаарлын өгөгдлийн сан
  • Тархсан кеш
  • Талстат хайлт
  • Олон утгат өгөгдлийн сан
  • Олон-загварт өгөгдлийн сан
  • Гурвалсан агуулах
  • Схемийн-агностик өгөгдлийн сан

Ашиглагдсан материалууд

  1. ↑ http://nosql-database.org/ "NoSQL DEFINITION: Next Generation Databases mostly addressing some of the points: being non-relational, distributed, open-source and horizontally scalable"
  2. ↑ Mohan, C. (2013). "History Repeats Itself: Sensible and NonsenSQL Aspects of the NoSQL Hoopla" in Proc. 16th Int'l Conf. on Extending Database Technology.. 
  3. ↑ "NOSQL meetup Tickets, Thu, Jun 11, 2009 at 10:00 AM". Eventbrite.com. Татаж авсан: 2017-03-06.
  4. ↑ "Amazon Goes Back to the Future With 'NoSQL' Database". WIRED. 2012-01-19. Татаж авсан: 2017-03-06.
  5. ↑ "RDBMS dominate the database market, but NoSQL systems are catching up". DB-Engines.com. 21 Nov 2013. Татаж авсан: 24 Nov 2013.
  6. ↑ "NoSQL (Not Only SQL)". NoSQL database, also called Not Only SQL
  7. ↑ Fowler, Martin. "NosqlDefinition". many advocates of NoSQL say that it does not mean a "no" to SQL, rather it means Not Only SQL
  8. ↑ Leavitt, Neal (2010). "Will NoSQL Databases Live Up to Their Promise?" (PDF). IEEE Computer.
  9. ↑ Vogels, Werner (2012-01-18). "Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications". All Things Distributed. Татаж авсан: 2017-03-06.
  10. ↑ Grolinger, K.; Higashino, W. A.; Tiwari, A.; Capretz, M. A. M. (2013). "Data management in cloud environments: NoSQL and NewSQL data stores" (PDF). Aira, Springer. Татаж авсан: 8 Jan 2014.
  11. ↑ "Jepsen: MongoDB stale reads". Aphyr.com. 2015-04-20. Татаж авсан: 2017-03-06.
  12. ↑ "Large volume data analysis on the Typesafe Reactive Platform". Slideshare.net. Татаж авсан: 2017-03-06.
  13. ↑ Fowler, Adam. "10 NoSQL Misconceptions". Dummies.com. Татаж авсан: 2017-03-06.
  14. ↑ "No! to SQL and No! to NoSQL | So Many Oracle Manuals, So Little Time". Iggyfernandez.wordpress.com. Татаж авсан: 2017-03-06.
  15. ↑ Lith, Adam; Mattson, Jakob (2010). "Investigating storage solutions for large data: A comparison of well performing and scalable data storage solutions for real time extraction and batch insertion of data" (PDF). Göteborg: Department of Computer Science and Engineering, Chalmers University of Technology. p. 70. Татаж авсан: 12 May 2011. Carlo Strozzi first used the term NoSQL in 1998 as a name for his open source relational database that did not offer a SQL interface[...]
  16. ↑ "NoSQL Relational Database Management System: Home Page". Strozzi.it. 2 October 2007. Татаж авсан: 29 March 2010.
  17. ↑ "NoSQL 2009". Blog.sym-link.com. 12 May 2009. Татаж авсан: 29 March 2010.
  18. ↑ Chapple, Mike. "The ACID Model".
  19. ↑ "Hadoop-NoSQL-rankings". Татаж авсан: 2015-11-17.
  20. ↑ "DB-Engines Ranking". Татаж авсан: 2015-07-31.
  21. ↑ Yen, Stephen. "NoSQL is a Horseless Carriage" (PDF). NorthScale. Татаж авсан: 2014-06-26.
  22. ↑ Sandy (14 January 2011). "Key Value stores and the NoSQL movement". http://dba.stackexchange.com/questions/607/what-is-a-key-value-store-database: Stackexchange. Татаж авсан: 1 January 2012. Key-value stores allow the application developer to store schema-less data. This data usually consists of a string that represents the key, and the actual data that is considered the value in the "key-value" relationship. The data itself is usually some kind of primitive of the programming language (a string, an integer, or an array) or an object that is being marshaled by the programming language's bindings to the key-value store. This structure replaces the need for a fixed data model and allows proper formatting. {{cite web}}: External link in |location= (help)CS1 maint: location (link)
  23. ↑ Seeger, Marc (21 September 2009). "Key-Value Stores: a practical overview" (PDF). http://blog.marc-seeger.de/2009/09/21/key-value-stores-a-practical-overview/: Marc Seeger. Татаж авсан: 1 January 2012. Key-value stores provide a high-performance alternative to relational database systems with respect to storing and accessing data. This paper provides a short overview of some of the currently available key-value stores and their interface to the Ruby programming language. {{cite web}}: External link in |location= (help)CS1 maint: location (link)
  24. ↑ Katsov, Ilya (1 March 2012). "NoSQL Data Modeling Techniques". Ilya Katsov. Татаж авсан: 8 May 2014.
  25. ↑ "Table storage | Microsoft Azure". Azure.microsoft.com. Татаж авсан: 2017-03-06.
  26. ↑ "DocumentDB – NoSQL Database Service | Microsoft Azure". Azure.microsoft.com. Татаж авсан: 2017-03-06.
  27. ↑ Scofield, Ben (2010-01-14). "NoSQL - Death to Relational Databases(?)". Татаж авсан: 2014-06-26.
  28. ↑ "Making the Shift from Relational to NoSQL" (PDF). Couchbase.com. Татаж авсан: December 5, 2014.
  29. ↑ "Can’t do joins with MarkLogic? It’s just a matter of Semantics! - General Networks". Gennet.com. Татаж авсан: 2017-03-06.

Цааш уншваас...

  • Sadalage, Pramod (2012). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley. ISBN 0-321-82662-0.
  • McCreary, Dan (2013). Making Sense of NoSQL: A guide for managers and the rest of us. ISBN 9781617291074.
  • Wiese, Lena (2015). Advanced Data Management for SQL, NoSQL, Cloud and Distributed Databases. DeGruyter/Oldenbourg. ISBN 978-3-11-044140-6.
  • Strauch, Christof (2012). "NoSQL Databases" (PDF).
  • Moniruzzaman, A. B. (2013). "NoSQL Database: New Era of Databases for Big data Analytics - Classification, Characteristics and Comparison". {{cite journal}}: Cite journal requires |journal= (help)
  • Orend, Kai (2013). "Analysis and Classification of NoSQL Databases and Evaluation of their Ability to Replace an Object-relational Persistence Layer". {{cite journal}}: Cite journal requires |journal= (help)
  • Krishnan, Ganesh. "Method and system for versioned sharing, consolidating and reporting information".

Нэмэлт линк

"https://mn.wikipedia.org/w/index.php?title=NoSQL&oldid=504686"-с авсан