近期总是提到NoSQL这个词汇。起初仅仅知道,应该是一种数据库而已,仅仅是这样的数据库眼下符合当前互联网的需求,应用比較广泛。逐渐发现,当前的各个公司在招聘信息中会有掌握NoSQL的优先等要求。于是,抱着好奇的心理,来查了一些资料,并进行了整理,来分享给大家!

以下的内容来源于百度百科
NoSQL泛指非关系型的数据库

随着互联网web2.0站点的兴起,传统的关系数据库在应付web2.0站点,特别是超大规模和高并发SNS类型的web2.0纯动态网站已经显得力不从心,暴露了非常多难以克服的问题。而非关系型的数据库则因为其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题。

虽然NoSQL流行语火起来才短短一年的时间,可是不可否认,如今已经開始了第二代运动。虽然早期的堆栈代码仅仅能算是一种实验,然而如今的系统已经更加的成熟、稳定。只是如今也面临着一个严酷的事实:技术越来越成熟——以至于原来非常好的NoSQL数据存储不得不进行重写。也有少数人觉得这就是所谓的2.0版本号。这里列出一些比較知名的工具。能够为大数据建立高速、可扩展的存储库。


基本含义
NoSQL(NoSQL = Not Only SQL ),意即“不不过SQL”,是一项全新的数据库革命性运动,早期就有人提出,发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储,相对于铺天盖地的关系型数据库运用,这一概念无疑是一种全新的思维的注入。

NNoSQL数据库的四大分类

键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。

可是假设DBA仅仅对部分值进行查询或更新的时候。Key/value就显得效率低下了。[3]举比如:Tokyo
Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.

列存储数据库。

这部分数据库一般是用来应对分布式存储的海量数据。键仍然存在,可是它们的特点是指向了多个列。这些列是由列家族来安排的。如:Cassandra, HBase, Riak.
文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的,并且它同第一种键值存储相类似。

该类型的数据模型是版本号化的文档。半结构化的文档以特定的格式存储,比方JSON。文档型数据库可 以看作是键值数据库的升级版,同意之间嵌套键值。

并且文档型数据库比键值数据库的查询效率更高。如:CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB,已经开源。

图形(Graph)数据库
图形结构的数据库同其它行列以及刚性结构的SQL数据库不同,它是使用灵活的图形模型。而且可以扩展到多个server上。

NoSQL数据库没有标准的查询语言(SQL),因此进行数据库查询须要制定数据模型。很多NoSQL数据库都有REST式的数据接口或者查询API。

[2]如:Neo4J,
InfoGrid, Infinite Graph.

因此,我们总结NoSQL数据库在下面的这几种情况下比較适用:1、数据模型比較简单;2、须要灵活性更强的IT系统;3、对数据库性能要求较高。4、不须要高度的数据一致性。5、对于给定key,比較easy映射复杂值的环境。

3NoSQL数据库的四大分类表格分析

分类 Examples举例 典型应用场景 数据模型 长处 缺点
键值(key-value) Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB 内容缓存,主要用于处理大量数据的高訪问负载,也用于一些日志系统等等。 Key 指向 Value 的键值对,通经常使用hash table来实现 查找速度快 数据无结构化,通常仅仅被当作字符串或者二进制数据
列存储数据库 Cassandra, HBase, Riak 分布式的文件系统 以列簇式存储,将同一列数据存在一起 查找速度快。可扩展性强。更easy进行分布式扩展 功能相对局限
文档型数据库 CouchDB, MongoDb Web应用(与Key-Value类似,Value是结构化的,不同的是数据库可以了解Value的内容) Key-Value相应的键值对,Value为结构化数据 数据结构要求不严格。表结构可变,不须要像关系型数据库一样须要预先定义表结构 查询性能不高。并且缺乏统一的查询语法。
图形(Graph)数据库 Neo4J, InfoGrid, Infinite Graph 社交网络,推荐系统等。

专注于构建关系图谱

图结构 利用图结构相关算法。比方最短路径寻址,N度关系查找等 非常多时候须要对整个图做计算才干得出须要的信息,并且这样的结构不太好做分布式的集群方案。

[3]

4

对于NoSQL并没有一个明白的范围和定义,可是他们都普遍存在以下一些共同特征:
  1. 不须要提前定义模式:不须要共同特征事先定义数据模式,提前定义表结构。数据中的每条记录都可能有不同的属性和格式。

    当插入数据时,并不须要预先定义它们的模式。

  2. 无共享架构:相对于将全部数据存储的存储区域网络中的全共享架构。NoSQL往往将数据 划分后存储在各个本地server上。由于从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能,从而提高了系统的性能。
  3. 弹性可扩展:能够在系统执行的时候,动态添加或者删除结点。不须要停机维护。数据能够自己主动迁移。
  4. 分区:相对于将数据存放于同一个节点,NoSQL数据库须要将数据进行分区。将记录分散在多个节点上面。而且通常分区的同一时候还要做复制。这样既提高了并行性能,又能保证没有单点失效的问题。
  5. 异步复制:和RAID存储系统不同的是。NoSQL中的复制,往往是基于日志的异步复制。

    这样。数据就能够尽快地写入一个节点,而不会被网络传输引起拖延。缺点是并不总是能保证一致性,这种方式在出现问题的时候。可能会丢失少量的数据。

  6. BASE:相对于事务严格的ACID特性,NoSQL数据库保证的是BASE特性。

    BASE是终于一致性和软事务。

NoSQL数据库并没有一个统一的架构,两种NoSQL数据库之间的不同,甚至远远超过两种关系型数据库的不同。

能够说,NoSQL各有所长。成功的NoSQL必定特别适用于某些场合或者某些应用,在这些场合中会远远胜过关系型数据库和其它的NoSQL。

NoSQL数据库的四大分类



键值(Key-Value)存储数据库

这一类数据库主要会使用到一个哈希表。这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。可是假设DBA仅仅对部分值进行查询或更新的时候,Key/value就显得效率低下了。

[3] 举比如:Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.

列存储数据库。

这部分数据库一般是用来应对分布式存储的海量数据。键仍然存在。可是它们的特点是指向了多个列。这些列是由列家族来安排的。

如:Cassandra, HBase, Riak.

文档型数据库

文档型数据库的灵感是来自于Lotus Notes办公软件的,并且它同第一种键值存储相类似。该类型的数据模型是版本号化的文档。半结构化的文档以特定的格式存储,比方JSON。文档型数据库可 以看作是键值数据库的升级版。同意之间嵌套键值。并且文档型数据库比键值数据库的查询效率更高。如:CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB,已经开源。

图形(Graph)数据库

图形结构的数据库同其它行列以及刚性结构的SQL数据库不同,它是使用灵活的图形模型,而且可以扩展到多个server上。

NoSQL数据库没有标准的查询语言(SQL),因此进行数据库查询须要制定数据模型。很多NoSQL数据库都有REST式的数据接口或者查询API。

[2] 如:Neo4J, InfoGrid, Infinite Graph.

因此,我们总结NoSQL数据库在下面的这几种情况下比較适用:1、数据模型比較简单;2、须要灵活性更强的IT系统。3、对数据库性能要求较高;4、不须要高度的数据一致性;5、对于给定key,比較easy映射复杂值的环境。

3NoSQL数据库的四大分类表格分析



分类 Examples举例 典型应用场景 数据模型 长处 缺点

键值(key-value)[3] Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB 内容缓存,主要用于处理大量数据的高訪问负载,也用于一些日志系统等等。[3] Key 指向 Value 的键值对。通经常使用hash table来实现[3] 查找速度快 数据无结构化,通常仅仅被当作字符串或者二进制数据[3]


列存储数据库[3] Cassandra, HBase, Riak 分布式的文件系统 以列簇式存储。将同一列数据存在一起 查找速度快,可扩展性强。更easy进行分布式扩展 功能相对局限

文档型数据库[3] CouchDB, MongoDb Web应用(与Key-Value类似,Value是结构化的,不同的是数据库可以了解Value的内容) Key-Value相应的键值对,Value为结构化数据 数据结构要求不严格。表结构可变。不须要像关系型数据库一样须要预先定义表结构 查询性能不高,并且缺乏统一的查询语法。

图形(Graph)数据库[3] Neo4J, InfoGrid, Infinite Graph 社交网络。推荐系统等。

专注于构建关系图谱 图结构 利用图结构相关算法。比方最短路径寻址,N度关系查找等 非常多时候须要对整个图做计算才干得出须要的信息,并且这样的结构不太好做分布式的集群方案。[3]


4共同特征



对于NoSQL并没有一个明白的范围和定义。可是他们都普遍存在以下一些共同特征:

不须要提前定义模式:不须要事先定义数据模式,提前定义表结构。

数据中的每条记录都可能有不同的属性和格式。当插入数据时。并不须要预先定义它们的模式。

无共享架构:相对于将全部数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地server上。

由于从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能,从而提高了系统的性能。

弹性可扩展:能够在系统执行的时候。动态添加或者删除结点。不须要停机维护,数据能够自己主动迁移。

分区:相对于将数据存放于同一个节点,NoSQL数据库须要将数据进行分区,将记录分散在多个节点上面。而且通常分区的同一时候还要做复制。这样既提高了并行性能。又能保证没有单点失效的问题。

异步复制:和RAID存储系统不同的是,NoSQL中的复制,往往是基于日志的异步复制。

这样,数据就能够尽快地写入一个节点。而不会被网络传输引起拖延。缺点是并不总是能保证一致性。这种方式在出现问题的时候。可能会丢失少量的数据。

BASE:相对于事务严格的ACID特性,NoSQL数据库保证的是BASE特性。BASE是终于一致性和软事务。

NoSQL数据库并没有一个统一的架构,两种NoSQL数据库之间的不同,甚至远远超过两种关系型数据库的不同。能够说,NoSQL各有所长。成功的NoSQL必定特别适用于某些场合或者某些应用,在这些场合中会远远胜过关系型数据库和其它的NoSQL。

5适用场景



NoSQL数据库在下面的这几种情况下比較适用:1、数据模型比較简单;2、须要灵活性更强的IT系统;3、对数据库性能要求较高。4、不须要高度的数据一致性。5、对于给定key。比較easy映射复杂值的环境。

6发展现状



计算机体系结构在数据存储方面要求具备庞大的水平扩展性。而NoSQL致力于改变这一现状。Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。

NoSQL项目的名字上看不出什么同样之处,可是,它们通常在某些方面同样:它们能够处理超大量的数据。

这场革命仍然须要等待。的确,NoSQL对大型企业来说还不是主流,可是,一两年之后非常可能就会变个样子。在NoSQL运动的最新一次聚会中,来自世界各地的150人挤满了CBS Interactive的一间会议室。

分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验。如何使用更有效和更廉价的方法来管理数据。

“关系型数据库给你强加了太多东西。它们要你强行改动对象数据。以满足RDBMS (relational database management system。关系型数据库管理系统)的须要,”在NoSQL拥护者们看来,基于NoSQL的替代方案“仅仅是给你所须要的”。

水平扩展性(horizontal scalability)指可以连接多个软硬件的特性,这样可以将多个server从逻辑上看成一个实体。

7挑战



虽然大多数NoSQL数据存储系统都已被部署于实际应用中,但归纳其研究现状,还有很多挑战性问题。

已有key-value数据库产品大多是面向特定应用自治构建的,缺乏通用性;

已有产品支持的功能有限(不支持事务特性),导致其应用具有一定的局限性;

已有一些研究成果和改进的NoSQL数据存储系统,但它们都是针对不同应用需求而提出的对应解决方式,如支持组内事务特性、弹性事务等,非常少从全局考虑系统的通用性。也没有形成系列化的研究成果;

缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术(如成熟的基于启示式的优化策略、两段封锁协议等)、标准规范(如SQL语言)的支持。

眼下,HBase数据库时安全特性最完好的NoSQL数据库产品之中的一个,而其它的NoSQL数据库多数没有提供内建的安全机制,但随着NoSQL的发展,越来越多的人開始意识到安全的重要。部分NoSQL产品逐渐開始提供一些安全方面的支持。

随着云计算、互联网等技术的发展,大数据广泛存在,同一时候也呈现出了很多云环境下的新型应用,如社交网络网、移动服务、协作编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求。如事务的支持、系统的弹性等。同一时候云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。

眼下,已有系统通过支持可任意增减节点来满足可扩展性;通过副本策略保证系统的容错性。基于监測的状态消息协调实现系统的自管理性。“弹性”的目标是满足Pay-per-use 模型,以提高系统资源的利用率。该特性是已有典型NoSQL数据库系统所不完好的,但却是云系统应具有的典型特点;“强一致性”主要是新应用的需求。

NoSQL数据库在下面的这几种情况下比較适用:1、数据模型比較简单。2、须要灵活性更强的IT系统;3、对数据库性能要求较高;4、不须要高度的数据一致性;5、对于给定key。比較easy映射复杂值的环境。

6发展现状

计算机体系结构在数据存储方面要求具备庞大的水平扩展性,而NoSQL致力于改变这一现状。

Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。

NoSQL项目的名字上看不出什么同样之处。可是,它们通常在某些方面同样:它们能够处理超大量的数据。
这场革命仍然须要等待。

的确,NoSQL对大型企业来说还不是主流,可是,一两年之后非常可能就会变个样子。在NoSQL运动的最新一次聚会中。来自世界各地的150人挤满了CBS Interactive的一间会议室。

分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验,如何使用更有效和更廉价的方法来管理数据。

关系型数据库给你强加了太多东西。

它们要你强行改动对象数据。以满足RDBMS (relational database management system。关系型数据库管理系统)的须要。”在NoSQL拥护者们看来。基于NoSQL的替代方案“仅仅是给你所须要的”。

水平扩展性(horizontal scalability)指可以连接多个软硬件的特性,这样可以将多个server从逻辑上看成一个实体。

7挑战

虽然大多数NoSQL数据存储系统都已被部署于实际应用中。但归纳其研究现状,还有很多挑战性问题。
  1. 已有key-value数据库产品大多是面向特定应用自治构建的。缺乏通用性。
  2. 已有产品支持的功能有限(不支持事务特性),导致其应用具有一定的局限性;
  3. 已有一些研究成果和改进的NoSQL数据存储系统,但它们都是针对不同应用需求而提出的对应解决方式,如支持组内事务特性、弹性事务等,非常少从全局考虑系统的通用性。也没有形成系列化的研究成果;
  4. 缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术(如成熟的基于启示式的优化策略、两段封锁协议等)、标准规范(如SQL语言)的支持。
  5. 眼下,HBase数据库时安全特性最完好的NoSQL数据库产品之中的一个,而其它的NoSQL数据库多数没有提供内建的安全机制,但随着NoSQL的发展,越来越多的人開始意识到安全的重要,部分NoSQL产品逐渐開始提供一些安全方面的支持。
随着云计算、互联网等技术的发展。大数据广泛存在,同一时候也呈现出了很多云环境下的新型应用,如社交网络网、移动服务、协作编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求,如事务的支持、系统的弹性等。同一时候云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。眼下,已有系统通过支持可任意增减节点来满足可扩展性;通过副本策略保证系统的容错性。基于监測的状态消息协调实现系统的自管理性。“弹性”的目标是满足Pay-per-use
模型。以提高系统资源的利用率。该特性是已有典型NoSQL数据库系统所不完好的,但却是云系统应具有的典型特点。“强一致性”主要是新应用的需求。

以下的内容借鉴:http://www.infoq.com/cn/news/2011/01/nosql-why/

NOSQL的优势

易扩展

NoSQL数据库种类繁多,可是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就很easy扩展。

也无形之间。在架构的层面上带来了可扩展的能力。

大数据量,高性能

NoSQL数据库都具有非常高的读写性能,尤其在大数据量下。相同表现优秀。这得益于它的无关系性,数据库的结构简单。

一般MySQL使用Query Cache。每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用。Cache性能不高。而NoSQL的Cache是记录级的。是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高非常多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段,随时能够存储自己定义的数据格式。而在关系数据库里,增删字段是一件很麻烦的事情。假设是很大数据量的表。添加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用

NoSQL在不太影响性能的情况,就能够方便的实现高可用的架构。比方Cassandra,HBase模型,通过复制模型也能实现高可用。

总结

NoSQL数据库的出现。弥补了关系数据(比方MySQL)在某些方面的不足,在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景,两者的紧密结合将会给web2.0的数据库发展带来新的思路。

让关系数据库关注在关系上。NoSQL关注在存储上。

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能。高稳定型,久经历史考验,并且使用简单,功能强大。同一时候也积累了大量的成功案例。

在互联网领域,MySQL成为了绝对靠前的王者,毫不夸张的说,MySQL为互联网的发展做出了卓越的贡献。

在90年代,一个站点的訪问量一般都不大,用单个数据库全然能够轻松应付。在那个时候,很多其它的都是静态网页,动态交互类型的站点不多。

到了近期10年。站点開始高速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。

在初期。论坛的流量事实上也不大。假设你接触网络比較早。你可能还记得那个时候还有文本型存储的论坛程序,能够想象一般的论坛的流量有多大。

Memcached+MySQL

后来。随着訪问量的上升。差点儿大部分使用MySQL架构的站点在数据库上都開始出现了性能问题,web程序不再只专注在功能上。同一时候也在追求性能。

程序猿们開始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。開始比較流行的是通过文件缓存来缓解数据库压力。可是当訪问量继续增大的时候,多台web机器通过文件缓存不能共享。大量的小文件缓存也带了了比較高的IO压力。在这个时候,Memcached就自然的成为一个很时尚的技术产品。

Memcached作为一个独立的分布式的缓存server,为多个webserver提供了一个共享的高性能缓存服务。在Memcachedserver上,又发展了依据hash算法来进行多台Memcached缓存服务的扩展,然后又出现了一致性hash来解决添加或降低缓存server导致又一次hash带来的大量缓存失效的弊端。当时,假设你去面试,你说你有Memcached经验,肯定会加分的。

Mysql主从读写分离

因为数据库的写入压力添加。Memcached仅仅能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分站点開始使用主从复制技术来达到读写分离。以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的站点标配了。

分表分库

随着web2.0的继续快速发展。在Memcached的快速缓存,MySQL的主从复制,读写分离的基础之上。这时MySQL主库的写压力開始出现瓶颈。而数据量的持续猛增,因为MyISAM使用表锁。在高并发下会出现严重的锁问题。大量的高并发MySQL应用開始使用InnoDB引擎取代MyISAM。

同一时候。開始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候。分表分库成了一个热门技术。是面试的热门问题也是业界讨论的热门技术问题。

也就在这个时候,MySQL推出了还不太稳定的表分区。这也给技术实力一般的公司带来了希望。

尽管MySQL推出了MySQL
Cluster集群,可是因为在互联网差点儿没有成功案例,性能也不能满足互联网的要求,仅仅是在高可靠性上提供了很大的保证。

MySQL的扩展性瓶颈

在互联网,大部分的MySQL都应该是IO密集型的,其实,假设你的MySQL是个CPU密集型的话,那么非常可能你的MySQL设计得有性能问题,须要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂,也越来越具有技术挑战性。分表分库的规则把握都是须要经验的。

尽管有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发人员的复杂性,可是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更,可能又须要一种新的分库方式。

MySQL数据库也常常存储一些大文本字段。导致数据库表很的大。在做数据库恢复的时候就导致很的慢。不easy高速恢复数据库。比方1000万4KB大小的文本就接近40GB的大小,假设能把这些数据从MySQL省去,MySQL将变得很的小。

关系数据库非常强大。可是它并不能非常好的应付全部的应用场景。

MySQL的扩展性差(须要复杂的技术来实现)。大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发者面临的问题。

以上的就是我总结的有关NoSQL的内容,从以上的内容能够看出,NoSQL必定会引起一次数据库的潮流

了解NoSQL的更多相关文章

  1. NoSql数据库使用半年后在设计上面的一些心得

    NoSql数据库这个概念听闻许久了,也陆续看到很多公司和产品都在使用,优缺点似乎都被分析的清清楚楚.但我心里一直存有一个疑惑,它的出现究竟是为了解决什么问题? 这个疑惑非常大,为此我看了很多分析文章, ...

  2. 非关系型数据库(NoSql)

    最近了解了一点非关系型数据库,刚刚接触,觉得这是一个很好的方向,对于大数据 方面的处理,非关系型数据库能起到至关重要的地位.这里我主要是整理了一些前辈的经验,仅供参考. 关系型数据库的特点 1.关系型 ...

  3. 关系型数据库与NoSQL数据库

    关系型数据库的优缺点 优点: 可以做事务处理,从而保证了数据的一致性: 可以进行JOIN等多表查询: 由于以SQL标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处). 缺点: 大量数据的写 ...

  4. 几款主流 NoSql 数据库的对比

    最近小组准备启动一个 node 开源项目,从前端亲和力.大数据下的IO性能.可扩展性几点入手挑选了 NoSql 数据库,但具体使用哪一款产品还需要做一次选型. 我们最终把选项范围缩窄在 HBase.R ...

  5. “NOSQL” 杂谈

    引言: nosql 的兴起和革命,在我看来已经开始逐渐影响到了传统的sql的地位,但是仅仅是影响而已,取代是不太可能的. 正文: 两年前,一个偶然的机会开始接触到 nosql ( mongodb ). ...

  6. Squirrel: 通用SQL、NoSQL客户端

    安装 配置数据库 配置驱动 配置连接 如果你的工作中,需要使用到多个数据库,又不想在多种客户端之间切换来切换去.那么就需要找一款支持多数据库的客户端工具了.如果你要连接多个关系型数据库,你就可以使用N ...

  7. NoSQL和MongoDB

     NoSQL(NoSQL=Not Only SQL),意即“不仅仅是SQL”.关系数据库关注在关系上,NoSQL关注在存储上. 发展背景 (1)传统关系型数据库遇到了性能瓶颈. 高并发读写(High ...

  8. NoSQL指南

    一.数据库发展 1.早期出现的数据库包括平面文件数据管理系统.分层数据管理系统和网络数据管理系统,分别对应的数据结构是线性表.树和图. 平面文件数据管理系统是使用磁带对数据进行顺序存储的,带来的问题不 ...

  9. NoSQL与RDBMS的九点区别联系

    原文链接:http://blog.sina.com.cn/s/blog_5373fb0b0101ft8a.html     1 理解ACID与BASE的区别(ACID是关系型数据库强一致性的四个要求, ...

  10. 本人为巨杉数据库(开源NoSQL)写的C#驱动,支持Linq,全部开源,已提交github

    一.关于NoSQL的项目需求 这些年在做AgileEAS.NET SOA 中间件平台的推广.技术咨询服务过程之中,特别是针对我们最熟悉的医疗行业应用之中,针对大数据分析,大并发性能的需求,我们也在慢慢 ...

随机推荐

  1. 浅谈ThinkPHP3.2的子域名部署和路由优化(一)

    前言:建立一个网站系统,往往包含多个子网站,例如PC官网,移动端官网,后台管理,数据源自一个相同的数据库,整个架构上,从ThinkPHP来看,可以大体理解为Model(M)是一样的,Controlle ...

  2. [BZOJ 1297][SCOI 2009]迷路(矩阵快速幂)

    题目:http://www.lydsy.com:808/JudgeOnline/problem.php?id=1297 分析:如果每条边的边权都是1,那么就相当于对邻接矩阵自乘T次(因为写一下递推式子 ...

  3. c#创建ISS站点

    private void CreateWebSite() { try { string installPath = "C:\\Program Files\\MyWeb"; stri ...

  4. Java for LeetCode 191 Number of 1 Bits

    Write a function that takes an unsigned integer and returns the number of ’1' bits it has (also know ...

  5. HDU 1016 Prime Ring Problem 题解

    Problem Description A ring is compose of n circles as shown in diagram. Put natural number 1, 2, ... ...

  6. Linux 操作命令列表记录

    Linux 操作命令列表记录 SSH登录 登录 ## 范式 ssh [username]@[host] ## 例 ssh -p 1222 root@10.0.0.1 使用非默认端口(ssh默认端口22 ...

  7. Jquery获取input=text 的值

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/ ...

  8. 在vue生命周期中及时销毁全局作用的代码

    一.纯客户端中 对于全局的代码,比如定时器等,在 beforeDestroy或 destroyed 生命周期时将其销毁.如果在跳转路由时候,组件销毁了,全局的定时器却没有销毁,这会使得页面产生卡顿. ...

  9. java应用健康检查

    本文主要针对自己手写shell监控应用状态,有可系统解决方案的,比如K8S,可以略过 #!/bin/sh#health_check.sh count=`ps -ef | grep test.jar | ...

  10. HiveQL之Database相关操作

    1.Create Database(创建数据库语法) CREATE (DATABASE|SCHEMA) [IF NOT EXISTS] database_name [COMMENT database_ ...