NOSQLI数据库是甚么？

术语nosql包罗了范固普遍的数据库，每回种数据库都有本身的长处和缺乏，而且大多都有十分差别的方针和用例。在察看今日的 nosol共生零碎时，可以将数据库划分为5大类:地道的键/值、数据结构、图、面向文档、高度散布。每品种此外数据库都面向差别的应用情况，而且每一个种别也都做了差别的折衷。咱们将别离考查这些数据库，并看看此中的折衷情况。
地道的键/值
地道的键值数据库理论上曾经存在很永劫间了。以至在sql数据库风行以前，dbm(一个地道的键/值数据库)就活着界上的不少unx零碎中运用了。之后是 berkeley db，今朝依然是一个维护中的富裕生命活气的数据库解决计划。今日，这些地道的键值存储库正在从头风行起来，部分起因是一切的 nosql数据库都在变得风行起来，但也是由于开发了一些速率更快、更为现代的数据库实现，如 tokyo cabinet、 kyoto cabinet、 memcachedb。
恰是它们的简略性界说了这组数据库。向数据库存入一个键和一个值，而后用统一个键查询数据库，则会获得沟通的值。没有结构或类型零碎逐个常规所处置的只是字节或字符串。由于这类简略性，这些数据库的开消极小，以是十分快。事实上，这些数据库常规都是实现为磁盘上的b树或哈希表。
对一个地道的键值数据库进行分片是含糊其辞的逐个简略地选一个哈希算法，以键作为参数运转该算法，输出就是要查询或写入的数据库节点。另外一方面，对付庞大查询就彻底不是这么简略了。醫如对付如许的查询:年龄大于50的用户，就没法直接查询，不克不及不维持另外一个键/值对，此中值是一个序列化的用户键列表，这些用户的年龄大于50，每次要创立新用户或更新用户信息，都要更新这个列表。
对付纯料的键/值存储库，能够的应用包括http会话、用户爱好以及url缩写(shorteners)。我在前面曾经形容过http会话，http会话应该以一种十分直接的体式格局存储在能/值摩中。此中键就是用户的会话关键字( session key)，而值是包罗用户会话信息的一个序列化了的对象。对付用户爱好，可以如许来实现:键是用户1d连贯上用户爱好的名称，值就是用户理论的爱好。对付url缩写，url途径就是键，而值就是途径重定向的位置。
数据结构
数据结构数据库对键/值数据库做了些修改。在地道键值数据库中，常规只是将键和值作为字符串或字节来存储，而数据结构数据库则将其存储为特定的数据结构，如列表、汇合或哈希表。由于有了这些附加的结构，就能够对值执行一些原子操纵。对付列表，可以对值进行压入或弹出操纵。对付汇合，可以执行并集和交加操纵。可以对数据库执行在应用程序中对数据结构进行的各类操纵。本色上，这些都是应用程序曾经在运用的数据结构只不外由外部进程维护罢了。
理论上这个领域独一的竞争者就是redis。某些实现细节使得redis颇有。redis默许是在内存中存储其全部内容的，只是周期性地将内容的快照存储到磁盘。这使得redist出奇得快，但假设数据库瓦解了，就会对数据形成一些损失。同时也象征着必需有足够的内存(ram)存储整个数据库。值得指出的是，这些默许配置是可以改动的一可以以速率为价值来添加数据的可连续性，还可以运用虚拟内存形式，如许就能够存储比理论内存更多的数据(尽管依然是有限定的)。
数器、任务队列或趋向阐明，是很抱负的。想象一下，给每一个登陆进来的用户一个独一的鍵，映射到一张空表上，该用户访问的每一个页面的每一个url都从尾部压人这张表。而后就能够获取任何用户的这些信息，察看该用户的访问途径，并对该途径进行阐明。经由过程这张表的长度就能够得出该用户的活跃水平。这是一个人为的例子，但依然展现了极快的内存操纵和丰硕的数据结构能做甚么工作。
图
图数据库险些就是数据结构数据库的一个特定实现，由于图本就是一种数据结构。区分是图数据库再也不是基于键/值，数据是作为图的节点和边存储的。图数据库不是用键来查询值，而是给出根节点的句柄，而后就能够遍历整个图以找到需求的节点或者边。这会十分有价值，由于不少应用程序都大量运用了图这类数据结构，将这些数据结构映射为图数据库上的操纵是至关容易的。就像数据结构数据库同样，数据库的图也跟应用程序运用的图是同样的，只不外是由外部进程维护的罢了。
这个领域的主要竞争者是neo4j，这是是一个嵌入式的ava图数据库，但可以用好几种言语进行访同。除了neo4以外，其余开源的图数据库包括hypergraphdb、infogrid、vertexdb hypergraphdb定位在对图的一种更为通用的暗示上，此中之一就是边可以指向多个节点。vertex的乏味的地方是显现了一个restfull的httpapi，经由过程这个api可以直接访问数据库，而其余几种数据库主要都是经由过程java要领来访问的。
图数据库的劣势应该恰是你所冀望的:存储图或树形的数据。比方，假设网站想要维护一个交际图(social graph)，则运用图数据库会发生一些乏味的应用。警如，发现或向用户引荐新朋友，传统上实现起来既庞大，速率又慢，而运用图数据库则既简略，效力又高逐个仅仅运转一下宽度优先搜索或最短途径遍历，工作就搞定了。
面向文档
面向文档的数据库又雷同于键值数据库，但值再也不是字节、字符串、列表、汇合，而是文档”。甚么是文档?在咱们要谈到的两个面向文档数据库 couchdb和mongodb中，文档是作为json(或雷同于json)对象存储的，本色上是一种哈希表或字典。这些值都有沟通的结构，象征着可以用查询来探测这类结构，并只返回所需求的文档。要记住的是，这类查询威力是建立在经由过程键来查找文档的威力之上的。
couchdb是一个面向文档的数据库，是用 erlang开发的，有一些乏味的实现细节，警如说是一种只附加(append-only)的数据结构，而且能够在数据库中直接向应用程序提供服务。mongodb是另外一个面向文档的数据库，是用c++开发的，在速率上做了不少优化，提供了一个愈加传统的查询层。尽管这两个零碎在纸上看起来很像，但方针倒是差别的。在我写这些东西的时辰，couchdb的趋向是作为桌面数据库或阅读器中的数据库，由用户下载装置，而mongodb则趋向于更多地用在数据中心。
在不克不及切当地知道能获得甚么数据时，如在糊口串流应用中那样，面向文档的数据库就十分适宜了。在如许的应用中，从一个风行的照片网站上检索的文档应该包罗照片属性，而来自微博网站的文档能够有一些地理属性，而来自博客网站的文档将不会有这些信息。面向文档数据库的另外一个不错的应用是内容管理零碎，在如许的零碎中，每一个文档都暗示一个页面，或页面的一部分。

高度散布
高度散布的数据库几个有些差别逐个有些本色上更濒临于键/值存储，其余则更像大型的多维哈企图。它们的独特性是都为多节点部署优化过。在这些零碎中，简略地在集群中添加一个新节点就会添加更多的容量。此中一个节点失效其实不会招致数据损失，但会失掉一些容量。大都这类零碎城市容许用户就义掉一些一致性而包管高可用性和分区容错性。
hbase是一个高度散布式的数据库，源自于hadoop-项目，而且遭到big table(google专有的高度散布式数据库)的直接影响。 cassandra是另外一个高度散布式数据库，最初是在facebook开发的，尽管数据模子十分雷同于hbase，但集中在不发生单点故障以及写操纵机能上。hbase和cassandra都将数据存储为大型的多维哈企图。 basho公司的riak是另个高度散布式数据库，运用erlang开发，可以经由过程restfull的httpape来访问，和hibase与cassandra比起来，是一个愈加简略的键值模子。voldemort和hypertable项目是另外两个值得说起的高度散布式数据库。
为甚么要运用高度散布的网站制作数据库呢?噢，常规都是没有其余选择的后果。这些数据库都是用在如许的场所，就是其余的数据库(基于sql的数据库或其余数据库)或者对数据没法处置，或者没法处置那些查询。险些每一个问题领域(problem domain)均可以用这些数据库零碎来建模，但有时辰会比许多传统数据库更为诡异。