NoSQL
![]() | Википедиагийн чанарын стандартад нийцүүлэхийн тулд энэ өгүүллийг хянан тохиолдуулах хэрэгтэй байна. Энэ талаар хэлэлцүүлгийн хуудас дээр юм уу энэ тэмдгийг илүү нарийвчилсан тэмдгээр солино уу. |
NoSQL (англ. Not only SQL буюу "SQL бус", "Дан ганц SQL ч биш", "харьцаа хамаарлын бус" хэмээн нэрлэгдэх нь бий) өгөгдлийн сан нь харьцаа өгөгдлийн сангийн хүснэгтэн загвараас загвар, ажиллагааны хувьд өөр байдлаар өгөгдлийг хадгалах, буцаан татаж авах механизмаар хангадаг. Ийм төрлийн өгөгдлийн сан нь 1960 - аад оноос хойш оршиж байсан авч, Web 2.0(Facebook, Google, Amazon.com гэх мэт) - ын хэрэгцээнээс үүдэн 21 - р зууны эхэн үеэс "NoSQL" хэмээх нэршил нь олон нийтийн дунд өргөн тархсан юм. Өдгөө NoSQL өгөгдлийн сангууд нь их-өгөгдөл, бодит-хугацааны веб аппликейшнүүд дээр өргөнөөр ашиглагдаж байна. NoSQL системүүдийг зарим тохиолдолд "Дан ганц SQL ч биш" хэмээн дууддаг нь SQL-төсөөт квери(query) хэлийг дэмжих хандлагатай байдагтай холбоотой.
Уг аргачлалыг хэрэглэх үндэслэл: Энгийн загвартай, тархсан төхөөрөмжүүдийн хувьд "босоо" өргөжүүлэлт хийхэд хялбар (харьцаа өгөгдлийн сангийн хувьд шүдний өвчин нь), байгаа өгөгдөл дээр хийгдэх хяналт/удирдлага илүү сайн. NoSQL өгөгдлийн сан дээр хэрэглэгддэг өгөгдлийн бүтэц(түлхүүр-утга, өргөн багана, граф, баримт бичиг гэх мэт) нь энгийн харьцаа өгөгдлийн сангууд дээр хэрэглэгддэгээс өөр бөгөөд тэр утгаараа зарим үйлдлүүд NoSQL дээр илүү хурдан гүйцэтгэгддэг. NoSQL өгөгдлийн санг ашиглах зохимжтой эсэх нь тухайн шийдэх гэж буй асуудлаас хамаарна. NoSQL өгөгдлийн санд хэрэглэгддэг өгөгдлийн бүтэц нь харьцаа өгөгдлийн сангийн хүснэгтэн бүтцээс ч уян хатан хэмээн тодорхойлогдох тохиолдол бий.
Ихэнх NoSQL агуулах/store нь хүртээмжтэй байдал/availability(уншилт бүрийн хувьд хариу ирэх), хурд, хуваалтын тэсвэртэй байдлын хүрээнд тогтвортой байдлыг олгодог(CAP - ын теоремын хувьд) . NoSQL агуулахыг нэвтрүүлэхэд тулгардаг томоохон саадуудаас нэрлэвэл: доод түвшний квери хэл ашигладаг(SQL - ын оронд ашигладаг), стандарт интерфейсээр дутмаг, одоо оршин байгаа харьцаа өгөгдлийн сангаас NoSQL рүү шилжихэд ихээхэн хэмжээний хөрөнгө оруулалт шаардана. Ихэнх NoSQL агуулах нь ACID гүйлгээний хувьд дутагдалтай байдаг ч, MarkLogic, AeroSpike, airCom c-treeACE, Google Spanner (техникийн талаасаа бол NewSQL өгөгдлийн сан), Symas LMDB, OrientDB хэмээх хэд хэдэн агуулах нь ACID - ыг загварынхаа гол төв болгосон.
Ихэнх NoSQL өгөгдлийн сан нь "хожим тогтворжилт" хэмээх концептийг хэрэгсдэг бөгөөд өгөгдлийн сангийн өөрчлөлт нь бүхий л зангилаа(node) - нууд руу "аажимдаа" хуулагдах юм. Тэгснээр квери шинэчлэгдсэн өгөгдлийг тэр даруй татаж чадахгүй байх магадлалтай,мөн квериний хүсэлтийн дагуу ирсэн үр дүн оновчтой биш байж болох юм(энэхүү асуудлыг хожуу уншилт хэмээн нэрийддэг). Мөн түүнчлэн, зарим нэг NoSQL систем нь дутуу бичилт хийх, эсхүл өөр төрлийн өгөгдлийн алдагдал үүсгэдэг . Азаар зарим нэг NoSQL систем нь өгөгдөл алдагдлаас сэргийлэх үүднээс "бичихээс-урьтаж тэмдэглэ" хэмээх концептийг(зарчимийг) ашигладаг. Нэгээс олон өгөгдлийн сан дээр хийгдэх тархсан гүйлгээ боловсруулалтын хувьд, өгөгдлийн тогтвортой байдал нь NoSQL битгий хэл харьцаа өгөгдлийн санд хүртэл томоохон асуудлын тоонд ордог. Бүр одоо хэрэглэгдэж байгаа харьцаа өгөгдлийн сангуудын хувьд хүртэл тархсан өгөгдлийн сангуудад нягт хамаарал(ө.х гадаад түлхүүрээр холбогдох) үүсгэхийг зөвшөөрдөггүй. ACID гүйлгээ, X/Open Xa стандартыг тархсан гүйлгээ боловсруулалтын хувьд хангадаг цөөн хэдхэн систем бий.
Үүсэл хөгжил
[засварлах | кодоор засварлах]NoSQL гэх нэр томьёог анх 1998 онд Карл Стрози өөрийнхөө хөгжүүлсэн "Стрози NoSQL нээлттэй эхийн харьцаа өгөгдлийн сан" гэх стандарт SQL интерфейсийг ашиглаагүй харьцаа өгөгдлийн сан дээр ашиглаж байсан юм. Түүний NoSQL харьцаа өгөгдлийн сан удирдах систем(ХӨСУС) нь 2009 онд гарж ирсэн NoSQL - ын ерөнхий ойлголтоос(ө.х стандарт) ялгаатай. Стрози одоогийн NoSQL нь харьцаа загвараас эрс хазайж(салж) байгаа учраас, "NoRel" буюу "Холбоо хамааралгүй(харьцаагүй)" хэмээн нэрлэсэн нь илүү дөхөм гэж үзэж байгаа юм.
Жон Оскарсон 2009 оны эхээр "нээлттэй эхийн тархсан, харьцаа өгөгдлийн сангууд" - ын талаар хэлэлцэхээр зохион байгуулсан арга хэмжээн дээрээ NoSQL - ыг ахин танилцуулсан юм. Хуучны ихэнх NoSQL системүүд нь цул, тогтвортой, тусгаарлагдсан, бат бөх(ACID) - аар хангадаггүй байсан бөгөөд, энэ нь харьцаа өгөгдлийн сангийн системүүд дунд ноёлж байсан уг дадал/практикт харшилж байсан юм.
2014 оны ашиг орлогоос үндэслэвэл, NoSQL - ын зах зээл дээр MarkLogic, MongoDB, Datastax тэргүүн байранд орж байна. 2015 оны олон нийтийн үнэлгээнээс үзэхэд, хамгийн их хүн хэрэглэж байгаа NoSQL өгөгдлийн сангуудаар MongoDB, Apache Cassandra, Redis орж байна.
NoSQL өгөгдлийн сангийн төрөл ба жишээ
[засварлах | кодоор засварлах]NoSQL өгөгдлийн санг ангилах маш олон аргачлал байдаг бөгөөд, аргачлал бүр нь өөр өөр категори, дэд-категориудтай. Өгөгдлийн загвараар нь ангилбаас:
- Баганан(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
Степе Ены судалгаан дээр үндэслээд, илүү нарийн ангилвал :
Төрөл | Жишээ(харгалзах төрлийн) |
---|---|
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 |
Хамаарлын өгөгдлийн сан нь тогтсон-загваргүй буюу мөр, баганад суурилсан хадгалалтын оронд, value/утгад суурилсан хадгалалтыг хийдэг.
Key-value(түлхүүр-утгат) агуулах
[засварлах | кодоор засварлах]Key-value(KV) агуулах нь холбоот массивыг(мап, dictionary/толь бичиг гэдгээрээ мөн танигдсан) өгөгдлийн загварынхаа гол цөм болгож ашигладаг . Энэ загварт, өгөгдөл нь түлхүүр түүнд харгалзах утгын хосмогуудын бүрдлээр дүрслэгддэг бөгөөд боломжит түлхүүр бүр цуглуулгад нэг л оршино.
Key-value загвар нь энгийн хэрнээ гүйцэтгэл сайтай бөгөөд баялаг өгөгдлийн загварууд нь ихэвчлэн үүний extension буюу нэмэлт байдлаар орж ирдэг. Key-value загвар нь толь зүйн эрэмбээр түлхүүрүүдийг хадгалдаг салангид эрэмбэлэгдсэн загвар руу өргөжих боломжтой. Энэ нэмэлт нь сонгосон түлхүүрүүд хоорондох утгыг илгээхдээ тун сайн.
Зарим өгөгдлийн сангууд нь түлхүүрийн эрэмбэлэлтийг дэмждэг. Мөн маш олон техник хангамжийн хэрэгжүүлэлт байдаг бөгөөд зарим хэрэглэгчид өгөгдлөө санах ой(RAM) дээрээ хадгалж байхад, зарим нь SSD, эргэлдэгч дискнүүд(ө.х HDD) дээр хадгалах жишээний.
Жишээ систем: ArangoDB, InfinityDB, Oracle NoSQL Database, Redis, dbm.
Баримт бичигт агуулах(Document store)
[засварлах | кодоор засварлах]Баримт бичигт агуулахын гол ойлголт нь "баримт бичиг" юм. Баримт бичигт-суурилсан өгөгдлийн сангууд нь хоорондоо өөр өөр мэт боловч, бүгд нэгэн стандарт формат дор баримт бичгийг нууцалж(encapsulate), өгөгдлийг кодчилдог. Өгөгдлийн кодчилолд XML, YAML, JSON, BSON орно. Баримт бичиг нь өгөгдлийн санд дахин давтагдахгүй түлхүүр дор хадгалагдана. Баримт-бичигт суурилсан өгөгдлийн сангийн өөр нэгэн шинж чанар нь түлхүүрийн хайлт key-value store - оор гүйцэтгэгддэг бөгөөд, доторх агуулгад нь суурилаад API эсхүл квери хэлээр баримт бичгийг татаж авах боломжтойд оршино.
Баримт бичгийг зохион байгуулж, бүлэглэх доорх аргууд бий:
- Цуглуулга(collection)
- Тэг(tag)
- Үл-харагдах мета-өгөгдөл
- Дироктерийн шатлал
Харьцаа өгөгдлийн сантай харьцуулбал, цуглуулга нь хүснэгттэй, баримт бичиг нь бичлэгүүдтэй төстэй юм. Юугаараа өөр вэ гэхээр, хүснэгт дэх бичлэг бүр талбарын(баганын) ижил дараалалтай. Харин цуглуулга дахь баримт бичгүүд шал ондоо талбар(багана) - уудтай байж болно.
Граф
[засварлах | кодоор засварлах]Энэ төрлийн өгөгдлийн сан нь элементүүд нь өөр хоорондоо төгсгөлөг холбоосоор холбогдсон, "граф" - аар үзүүлэхэд тохиромжтой өгөгдлийг загварчлахад зориулагдсан байдаг. Өгөгдлийн төрөл нь нийгмийн хамаарал/харилцаа, нийтийн тээврийн холбоо, авто замын зураг, сүлжээний топологи гэх зэрэг байж болох юм.
- Граф өгөгдлийн сан ба түүний квери хэл
Нэр | Хэл(нүүд) | Тэмдэглэл |
---|---|---|
AllegroGraph | SPARQL | RDF гурвалсан агуулах |
ArangoDB | AQL, JavaScript | Олон-загварт ӨСУС, Баримт-бичигт, Граф өгөгдлийн сан, Түлхүүр-утгат агуулах. |
DEX/Sparksee | C , Java, .NET, Python | Граф өгөгдлийн сан |
FlockDB | Scala | Граф өгөгдлийн сан |
IBM DB2 | SPARQL | RDF гурвалсан агуулах DB2 10 дээр нэмэгдсэн |
InfiniteGraph | Java | Граф өгөгдлийн сан |
MarkLogic | Java, JavaScript, SPARQL, XQuery | Олон-загварт баримт бичигт өгөгдлийн сан, RDF гурвалсан агуулах |
Neo4j | Cypher | Граф өгөгдлийн сан |
OWLIM | Java, SPARQL 1.1 | RDF гурвалсан агуулах |
Oracle | SPARQL 1.1 | RDF гурвалсан агуулах 11g дээр нэмэгдсэн |
OrientDB | Java, SQL | Олон-загварт баримт бичиг, граф өгөгдлийн сан |
Sqrrl Enterprise | Java | Граф өгөгдлийн сан |
OpenLink Virtuoso | C , C#, Java, SPARQL | Холбогч програм, холимог өгөгдлийн сангийн механизм |
Stardog | Java, SPARQL | Граф өгөгдлийн сан |
Объект өгөгдлийн сан
[засварлах | кодоор засварлах]- 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
- Microsoft Azure DocumentDB
- 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 өгөгдлийн сангийн төрлүүдийг дараах байдлаар үнэлжээ:
Өгөгдлийн загвар | Чадамж | Өргөсгөх боломж | Уян хатан чанар | Төвөгтэй байдал | Функциональ хамаарал |
---|---|---|---|---|---|
Key–value store | сайн | сайн | сайн | байхгүй | олон янз (байхгүй) |
Column-oriented store | сайн | сайн | дунд | муу | маш бага |
Document-oriented store | сайн | олон янз (сайн) | сайн | муу | олон янз (муу) |
Graph database | олон янз | олон янз | сайн | сайн | графын онол |
Relational database | олон янз | олон янз | муу | дунд | харьцаа алгебр |
Харьцаа өгөгдлийг зохицуулах нь
[засварлах | кодоор засварлах]Ихэнх NoSQL өгөгдлийн сан нь квериний хувьд холбох чадвараар дутмаг байдаг тул, өгөгдлийн сангийн схем нь өөр байдлаар загварчлагдах хэрэгцээ гарна. NoSQL өгөгдлийн санд харьцаа өгөгдлийг зохицуулах үндсэн 3 техник бий.
Давхар квери
[засварлах | кодоор засварлах]Бүх өгөгдлийг нэг кверигээр татаж авахын оронд, хүссэн өгөгдлөө хэд хэдэн квери ашиглан татаж авах юм. NoSQL квери нь ихэвчлэн уламжлалт SQL кверинээс хурдан байдаг тул, нэмэлт квери ажиллуулах нь зардлын(цаг зарцуулалт г.м) хувьд өндөр биш байх боломжтой. Хэрэв квериний тоо хэт их бол доорх хоёр арга тохиромжтой.
Кэшлэлт, хуулбарлалт, энгийн хэлбэрт шилжээгүй өгөгдөл
[засварлах | кодоор засварлах]Дан ганц гадаад түлхүүрийг хадгалахгүйгээр, загварын өгөгдөлтэй нь хамт бодит гадаад утгыг(жишээ нь: лавлах хүснэгтийн ID - д харгалзах тайлбар утга) хадгалах нь олонтаа. Жишээлбэл, блог дээрх сэтгэгдэл бүрд хэрэглэгчийн ID - аас гадна хэрэглэгчийн нэр багтсан гэж үзье, хэрэв зээ тэгж давхар хадгалсан бол хэрэглэгчийн нэрийг татан авах хайлт хийхгүйгээр хялбархаан хандах боломжтой болно. Хэдий тийм ч, хэрэглэгчийн нэр өөрчлөгдвөөс, өгөгдлийн сан дахь маш олон хэсгүүд дээр давхар өөрчлөгдөх хэрэг гарна. Тиймээс энэхүү аргыг өгөгдлийн сан дээр бичилтээс илүүтэй уншилт ихээр хийгдэж байгаа үед ашиглах нь тохиромжтой.
Өгөгдлийг шигтгэх
[засварлах | кодоор засварлах]MongoDB мэтийн баримт бичигт өгөгдлийн сангуудийн хувьд жижиг хэмжээний цуглуулганд илүү их хэмжээний өгөгдөл хийх нь олонтаа. Жишээ нь, блогийн аппликейшн байлаа гэж үзье. Хэрэв блог дахь сэтгэгдлийг блогийн нийтлэлийн баримт бичиг дотор хадгалвал нэг л татан авалтаар бүхий л сэтгэгдлийг авах боломжтой болно. Тиймээс энэ аргийн гол зорилго нь тодорхой үйлдлийн хувьд хэрэгцээтэй бүхий л мэдээллийг нэг баримт бичигт хадгалахад оршино.
ACID, холболт дэмждэг эсэх
[засварлах | кодоор засварлах]Тухайн өгөгдлийн сан ACID, эсхүл холболт/join дэмждэг эсэхийг өгөгдлийн сангийн баримт бичгээс нь харсан болно.
Өгөгдлийн сан | ACID | Холболт |
---|---|---|
Aerospike | Үгүй | Тийм |
ArangoDB | Тийм | Тийм |
CouchDB | Тийм | Тийм |
c-treeACE | Тийм | Тийм |
HyperDex | Тийм | Тийм[nb 1] |
InfinityDB | Тийм | Үгүй |
LMDB | Тийм | Үгүй |
MarkLogic | Тийм | Тийм[nb 2] |
OrientDB | Тийм | Тийм |
Уншвал зохих
[засварлах | кодоор засварлах]- CAP - ын тёором
- Объект өгөгдлийн сан удирдах системүүдийн харьцуулалт
- Бүтэцлэгдсэн хадгалах програм хангамжуудын харьцуулалт
- Хамаарлын өгөгдлийн сан
- Тархсан кеш
- Талстат хайлт
- Олон утгат өгөгдлийн сан
- Олон-загварт өгөгдлийн сан
- Гурвалсан агуулах
- Схемийн-агностик өгөгдлийн сан
Ашиглагдсан материалууд
[засварлах | кодоор засварлах]Sadalage, Pramod (2012). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley. ISBN 0-321-82662-0.
Нэмэлт линк
[засварлах | кодоор засварлах]- Strauch, Christoph. [www.christof-strauch.de/nosqldbs.pdf NoSQL whitepaper]. Hochschule der Medien.
- Edlich, Stefan (2010). NoSQL database List.
- Neubauer, Peter (2010). Graph Databases, NOSQL and Neo4j. NetworkWorld.
- Bushik, Sergey (2012). vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak. NetworkWorld[permanent dead link].
- Zicari, Roberto V. (2014). Data Stores – Articles, Papers, Presentations[permanent dead link].
- McCreary, Dan (2012). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley. ISBN 0-321-82662-0.
- Wiese, Lena (2013). Making Sense of NoSQL: A guide for managers and the rest of us. DeGruyter/Oldenbourg. ISBN 9781617291074.
- Strauch, Christof (2015). "Advanced Data Management for SQL, NoSQL, Cloud and Distributed Databases" (PDF). DeGruyter/Oldenbourg.
- Strauch, Christof (2012). "NoSQL Databases" (PDF).
{{cite journal}}
: Cite journal requires|journal=
(help) - Orend, Kai (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".
- Krishnan, Ganesh. "Method and system for versioned sharing, consolidating and reporting information". Hochschule der Medien.
Эшлэл
[засварлах | кодоор засварлах]Мэдээлэл оруулсан
[засварлах | кодоор засварлах]B140920583
- ↑ "Can’t do joins with MarkLogic? It’s just a matter of Semantics! - General Networks". Gennet.com. Archived from the original on 2017-03-03. Retrieved 2017-03-06.