来源：蜘蛛抓取(WebSpider)
时间：2012-03-02 08:34
标签：
oracle nosql
当前访客身份：游客 [
当前位置：
现在NoSQL数据库是不是发展得比较成熟了？
对于Java开发者学哪种数据库比较好？
NoSQL是不是可以替换原有J2EE系统的SQL数据库？或者和原有的Oracle MySQL数据库并存？
共有10个答案
<span class="a_vote_num" id="a_vote_num_
no sql使用的场景是啥？和传统的数据库存储有啥区别？技术成熟度在于使用场景。 哪种数据库都可以学,java并不会限定非要哪种数据库,看项目要求。
<span class="a_vote_num" id="a_vote_num_
不要趋之若鹜
<span class="a_vote_num" id="a_vote_num_
no sql 都没见有什么应用场景的
<span class="a_vote_num" id="a_vote_num_
nosql和sql差别很大的。如果全新开发用nosql可以，如果是旧项目，最好别换
<span class="a_vote_num" id="a_vote_num_
nosql并不能代替关系型数据库
<span class="a_vote_num" id="a_vote_num_
一般认为，RDB也就是SQL用来处理高度结构化的数据，而NoSQL用来处理半结构化的数据，应用范围完全不同，更不会有替代一说。
对于高度结构化的数据，NoSQL用起来就是渣渣。而对于半结构化的数据，SQL十分难受。
<span class="a_vote_num" id="a_vote_num_
redis hadoop
已经很成熟了。NoSQL从来没有想着要取代关系型数据库，而且NoSQL的本意是Not only SQL。用在可用的地方即可，比如session，更新不频繁的List缓存
<span class="a_vote_num" id="a_vote_num_
已经很成熟了，nosql 有很多中，mongodb 可以替代关系型。redis k-v 可以存储访问量大的数据.如果对安全性，等要求高的就用关系型。
<span class="a_vote_num" id="a_vote_num_
在项目完全代替mysql是很难做到的，对nosql数据库技术要求的比较高，以后做数据转移也会很头痛，不过可以接合起来用。
<span class="a_vote_num" id="a_vote_num_
各种级别的事务，Nosql是很难实现的。
更多开发者职位上
有什么技术问题吗？
文心雕码的其它问题
类似的话题[NoSQL]解读NoSQL数据库的四大家族[转]
解读NoSQL数据库的四大家族[转]
原文地址：/art/781.htm在目前的企业IT架构中，系统管理员以及DBA都会考虑使用NoSQL数据库来解决RDBMS所不能解决的问题，特别是互联网行业。传统的关系型数据库主要以表(table)的形式来存储数据，而无法应对非结构化数据的挑战。在进行数据标准化的过程中，关系型数据库性能遭遇了瓶颈。NoSQL顾名思义就是Not-Only SQL，它可以作为关系型数据库的良好补充。在TechTarget数据库之前的报道中，我们也对NoSQL数据库的应用场景做了详细的介绍。NoSQL不像传统的关系型数据库，其种类繁多，且各有各的优势和缺点，对于DBA来说如何区分彼此的不同是一件比较头痛的工作。在本文中，我们就将进一步为您接受关于NoSQL数据库的分类以及各自的优缺点。NoSQL数据库的四大家族键值(Key-Value)存储数据库                                                                                 这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。相关数据库Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB典型应用内容缓存，适合混合工作负载并扩展大的数据集数据模型一系列键值对优势快速查询劣势存储的数据缺少结构化列存储数据库                                                                                                                 这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。相关数据库Cassandra, HBase, Riak典型应用分布式的文件系统数据模型以列簇式存储，将同一列数据存在一起优势查找速度快，可扩展性强，更容易进行分布式扩展劣势功能相对局限 文档型数据库                                                                                                   文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。相关数据库CouchDB、MongoDB典型应用Web应用数据模型一系列键值对优势数据结构要求不严格劣势查询性能不高，而且缺乏统一的查询语法 图形(Graph)数据库                                                                                      图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。相关数据库Neo4J、InfoGrid、Infinite Graph典型应用社交网络，推荐系统等。专注于构建关系图谱数据模型图结构强项利用图结构相关算法。弱项需要对整个图做计算才能得出结果，不容易做分布式的集群方案。因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
17:31:49&查看原网页[1]&
&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&& 5:16:16
&&网站联系: qq: email:&责任申明：本站内容均整理自互联网，若有侵权，请联系我们。使用本站提供的任务技术内容造成不良后果，本站不负任何责任。
欢迎投稿,电子邮件：（#号换成@）&& QQ群1： &&【先锋】SequoiaDB CTO王涛谈打造超越MongoDB的事务、高性能NoSQL
发表于 09:09|
摘要：兼顾事务和性能，并通过连接器实现复杂的SQL，NoSQL数据库SequoiaDB有着很多让人眼前一亮的特性。同时，SequoiaDB还能替代HDFS，作为MapReduce任务的数据存储源。
多样性、大容量给数据的存储和处理带来了巨大的挑战，当传统关系型数据库无法应对应用程序的快速迭代时，天生具备弱数据结构模式、易扩展等特性的NoSQL数据库得以飞速发展，在众多网络及新型应用程序中得以部署。然而，基于其分布式的特性，事务成为了大部分NoSQL数据库系统的致命弱项，也造就了NoSQL与任务关键性场景绝缘的这个现状。时至今日，着眼NoSQL领域，如何才能在高性能下兼顾事务以及更多功能已成为当务之急。为此，笔者近日与SequoiaDB创始人兼CTO王涛取得联系，就NoSQL打造进行了简要采访。同时，值得高兴的是，通过王涛得知，SequoiaDB即将开源。
以下为采访实录：
SequoiaDB创始人兼CTO 王涛
CSDN：请介绍你个人和SequoiaDB。
王涛：大家好，我叫王涛，现在是SequoiaDB的创始人兼CTO。之前我一直在IBM的北美数据库实验室做DB2数据库引擎。我们SequoiaDB是2012年正式成立的，每一行代码都是我们从零打造，并没有基于其他的开源数据库引擎。还记得当初我回国之前，大概用了半年的时间和几个IBM出来的兄弟在北美那边一行行地扣代码，最后整个引擎跑通了并且感觉性能不错，才回国成立的公司。我们SequoiaDB的核心产品就是一款文档类NoSQL数据库，从体系结构与应用场景上看和
MongoDB有些类似，因此很多时候我们会被拿出来和MongoDB作比较。
CSDN：你经历多年RDBMS与NoSQL的开发，是否可以从你的角度谈谈NoSQL运动？
王涛：我认为，NoSQL运动是现在应用程序互联网化和移动化的一个产物。过去，关系型数据库做点什么东西都需要进行复杂的数据模型设计和调整，但是在互联网时代这种玩法已经跟不上节奏了。所以，以互联网的标准数据格式JSON进行对象型数据存储成为一种需求，而这种需求同时也弱化了应用程序对关系模型的依赖。
当然，这并不是说NoSQL会在近期完全取代关系型数据库，而是这两者会有一个长期的共存，分别适用于不同的应用领域。现在我们已经看到，很多传统的企业也都开始慢慢接受互联网的思想，包括其业务模式以及后台所采用的技术，包括NoSQL数据库。
CSDN: 能否谈一下SequoiaDB当下都有哪些重量级的用户？数据库的规模达到什么级别？
王涛：我们现在在企业和互联网领域都有不少的成功案例。传统企业中包括像民生银行、海南航空、电信移动企业等；而互联网行业里面也有像蓝汛、蓝港在线这类企业。我们部署在一些客户的系统还是挺大的，比如有一家客户的日志分析集群系统总量超过PB，每天会产生近10TB的数据，都要近实时入库并且做到同时批处理分析和实时检索。这类集群都是百台节点的规模。
CSDN：同为文档类型NoSQL，对比全球排名第五的MongoDB，SequoiaDB的优势/特点是什么？
王涛：从架构上来讲，MongoDB和我们都是使用分片Sharding机制，每个分片里面做数据的复制和同步。而在具体实现中我们则有很大差异。譬如说我们的日志使用的是日志序列号LSN机制，而MongoDB则是一个capped
collection，所以我们可以做到很多MongoDB根本不可能做到的事情，例如事务这类操作。除了这些功能点以外呢，我们的性能可以说是一大亮点。过去人们通过MongoDB和CouchDB可能都认为文档类NoSQL的性能比较差，至少和Cassandra这类的宽表库比起来差。但是现在在我们的测评中，很多原本HBase和Cassandra最突出的导入操作都被我们甩在了后面。
CSDN：确实，一般人都认为文档类数据库由于结构复杂，相比起宽表和KV类型的NoSQL来说性能不佳。为什么SequoiaDB在能够提供丰富的数据库操作功能以外还达到这么高的性能呢？
王涛：这个问题就要深入到代码的实现中去了。我们在代码优化和精细化设计这部分做了很多工作，譬如并发性和锁的这一部分就非常典型。
在一个并行处理的数据库里面，如果锁控制得不好，会造成很多线程都堵在一个地方。如果大家有兴趣看看mongodb的代码可能会发现，它做了很多非常好的模块化封装，但是相反地对于一些锁的处理则比较粗糙，所以在高并发高压力的情况下总体的吞吐量根本上不去。而我们在设计SequoiaDB的时候，很多代码尽量做到无锁。程序的设计永远秉承一个理念，就是在正常流程下尽可能无锁，异常流程可以使用额外的代码或锁机制保证逻辑正确。所以即使在一个16核、32核的这种大机器下起高压力并发我们也可以把CPU打满，不会在某些代码上造成性能瓶颈。
另一方面，MongoDB实际上很多设计并非最优。譬如说它的日志机制使用了capped collection。可能咋一听起来很新潮很酷，但是实际上会对整体性能有着重大的损害。而我们使用的虽然是比较经典的日志LSN机制，但是正因为这种机制被所有关系型数据库使用了几十年，才从性能和功能上都被完善到了极致。
剩下的还有很多优化细节，譬如说我们在性能敏感的代码里面完全不允许使用string这种STL库，就是避免这种封装得比较深的库会做额外的譬如分配释放内存的操作，造成不必要的损耗。
CSDN：我们知道，分布式数据库和传统的单点数据库相比有很大不同。从技术上能不能简单介绍一下，分布式数据库的难点在什么地方？你们是怎样解决的？
王涛：传统的关系型数据库主要都是单点架构，有数的几个像Greenplum和DB2这种MPP 数据库才能够做到分布式架构。当然，我们说Oracle的RAC算是假的分布式，在存储层还是大统一。所以，我们这里说的分布式是Share
Nothing的MPP架构。
在分布式系统里面，有几点是需要注意的。第一，就是数据是否可以做到弹性扩张。这个可能算是所有MPP分布式关系型数据库最大的弱点之一。比如DB2，想要添加个节点，需要做redistribution，遇到一个几十TB的数据库估计要好几天才能搞完。而NoSQL明显不能这么玩，所以我们用的是一致性哈希技术，把数据散列后映射到哈希环上根据范围划分节点，可以做到在增减节点时移动最少的数据。
第二，节点的可用性。现在讲究的大集群基本都是围绕着PC服务器说的，PC服务器的特点众所周知，就是容易坏。那么如果我一个集群里面有1000个节点，三天两头都有可能有机器出故障。如果用关系型数据库那种MPP架构就完蛋了，一个节点坏了可能整个表都挂了。所以，我们要用多数据副本的方式保证即使机器挂了，数据也可以在其他的节点中找到。
第三，就是事务操作。我想事务操作是现在很多NoSQL都不具备的功能。并不是说NoSQL的架构和事务有冲突，而是想要实现事务机制需要太多模块的配合。譬如说日志机制，对于MongoDB的capped
collection机制就很难实现事务的提交和回滚功能。我们用的是基于传统的事务日志的机制才能够做到这一点。当然，别忘了还有记录锁、表锁这些机制，还要考虑多副本之间数据根据日志的分发同步，节点失效重新选举后日志的同步等一系列机制。
CSDN：事务一直是分布式数据库实现的难点，就算很多其他世界知名的NoSQL也没有很好地实现。可否详细介绍一下其中存在的挑战，以及SequoiaDB事务的实现途径。
王涛：事务本身其实原理并不难，就是做任何操作都要先写日志，然后把每个会话的日志都有一个链能够往回一条条找到本事务起始的位置，能够对每一个操作做redo和undo就可以了。这个是单点传统数据库的玩法。当然，锁这些机制是另一个故事了，这里先不提。
但是在分布式环境中，这个简单的东西就开始变复杂了。第一，如何确保在可配置的强一致与最终一致性中，事务在复制过程中的完整性。譬如说，主节点A挂了，备节点还没有同步到这个主节点最后的日志，这个时候事务怎么处理？对于我们来说，当然在最终一致性的配置中只能牺牲数据的完整性了，不过在强一致性开启的情况下则是必须要保证这一点。
另外，多个分片之间数据完整性的问题也存在。我们利用很多MPP数据库使用的二段提交（2PC）来玩，可以满足大部分提交回滚的需求。但是如果在二段提交过程中的小窗口处发生问题同样还会造成indoubt
transaction，这一块处理也是难点。
还有很多网络问题的检测也和事务息息相关。比如说如果协调节点挂掉了，需要让数据节点能够立刻感知到这个事件，并且确保这个协调节点所属的事务全部进行回滚操作。而如果某一个数据节点掉了，协调节点则必须感知然后通知其他数据节点回滚这个操作。
CSDN：我们看到SequoiaDB提供不少与第三方产品的连接器，能不能介绍一下这些连接器的作用？
王涛：做一个数据库不像搞一个游戏或者应用软件，自己和自己玩就行了。数据库是软件项目基础架构的一部分，需要对接很多第三方的应用和产品，要把生态圈建立起来嘛。所以我们在和其他产品对接这一块也花了不少力气。主要是两个大方向，一个是和Hadoop这块一起玩，一个是和使用关系型数据库的应用这块一起玩。和Hadoop对接相对比较简单，就是Java里串行化的几个函数嘛，对接了以后自然和Spark的对接也有了。另外对于Hadoop生态圈里面其他的Hive和Storm我们也都做了连接器，可以直接利用Hive和Storm从数据库读写数据。
而和使用关系型数据库的应用对接就有点麻烦了。我们想了个方法，先和PostgreSQL对接。PG不是提供一个FDW的机制么，我们就直接写了个库能够串到FDW上，让PG能够定义基于SequoiaDB的外部表，里面定义各个字段和类型。每次查询的时候相关的请求会通过FDW转换成我们认识的东西发送的数据库上，然后返回的记录在格式化成PG需要的格式，在PG里面进行关联啊聚集之类的。
总地来说，我们会不断增强连接器的种类和功能，争取今后和多数主流的产品与第三方应用都能够较轻易地对接。
CSDN：SequoiaDB曾宣布提供开源版本，是否取得了一定的进展，对比商业版，开源版本会弱化哪些方面？
王涛：开源现在是万事俱备，就差最后临门一脚了。我们已经在Github和CSDN CODE平台上都建立好了repository，所有的代码审查和协议注释也都已经完成了。我们将很快在近期就会正式对外开源。
商业版和社区版相比，主要是在企业级服务这块增加了一些内容。譬如说24x7的技术支持啦，定期巡检啦，安全机制啦，还有一些额外的监控机制和工具软件之类的。而从数据库内核的代码上来看企业版和社区版基本区别不大，也并不存在集群规模限制等问题。
CSDN：作为数据库打造的行家，有什么使用经验可以分享给读者的？
王涛：太多经验也谈不上，现在我看到不少程序员和DBA兄弟依然围绕着关系型数据库吃饭，我想大家可以开始适当关注大数据和NoSQL这个领域。因为我觉得今后关系型数据库会成为一个存量市场，就像几十年前的大型机一样不会消亡，但是也不会近期迎来大规模的增长。相反，非关系型数据库与大数据技术正在开始起步，虽然市场上还是一片混战局势未明，但这也正是切入这个领域开始学习的好机会。如果局势都明朗了，基本该占的坑都被占完了，晚来的弟兄们也没啥汤好喝。
中国创新“先锋”企业系列报道
公司产品/方向
C、C++、Java产品研发&
移动数据服务
鲁为民 & & &&
MoPaaS和InPaaS&
OpenStack公有云 & & &&
SendCloud & & & & & & & & &
大数据实时分析
云管理、云存储 & & & & & & & &
云操作系统 & & & & & & & &
赵健 & & & & & & & &
云安全、云身份认证&
通信运营商 & & & & & & & &
胡茂华 & & & & & &
云备份 & & & & & & & &&
& & & & & & & & &
基于云的建站软件超市&
云监控、基于大数据APM
高性能存储系统
手静脉生物识别、虚拟化
移动视频技术提供商
大数据分析平台
基于Hadoop的大数据平台
云API和端API
大数据、云计算、NoSQL
备注：日更新，持续更新中......
备注：云先锋系列文章是由CSDN云计算频道打造的，主要报道国内外在云计算、大数据方面具有独特竞争优势的企业，以传播技术为目的，推动中国云计算技术的发展，只有你有云计算或大数据方面独特的技术、产品和服务，你就可以投稿，欢迎投稿。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章
&&&&&&& NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的运用，这一概念无疑是一种全新的思维的注入。
&&&&&&& NoSQL数据库分四大类：
键值()存储
这一类数据库主要会使用到一个，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果只对部分值进行查询或更新的时候，Key/value就显得效率低下了。[3]举例如：Tokyo
Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存储数据库。
这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.
文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，目前已经开源。
图形(Graph)数据库
图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。[2]如：Neo4J,
InfoGrid, Infinite Graph.
因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
NoSQL数据库的四大分类表格分析
Examples举例
典型应用场景
键值（key-value）[3]
Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB
内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。[3]
Key 指向 Value 的键值对，通常用hash table来实现[3]
查找速度快
数据无结构化，通常只被当作字符串或者二进制数据[3]
列存储数据库[3]
Cassandra, HBase, Riak
分布式的文件系统
以列簇式存储，将同一列数据存在一起
查找速度快，可扩展性强，更容易进行分布式扩展
功能相对局限
文档型数据库[3]
CouchDB, MongoDb
Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）
Key-Value对应的键值对，Value为结构化数据
数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构
查询性能不高，而且缺乏统一的查询语法。
图形(Graph)数据库[3]
Neo4J, InfoGrid, Infinite Graph
社交网络，推荐系统等。专注于构建关系图谱
利用图结构相关算法。比如最短路径寻址，N度关系查找等
很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。[3]
以上内容摘自网上
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：253024次
积分：4704
积分：4704
排名：第3335名
原创：132篇
转载：74篇
译文：51篇
评论：163条
马云说，梦想还是要有的，万一实现了呢？所以，如果你不甘平庸，如果你心怀梦想，那就激情起来，即使跑起来被拌倒无数次，也不要规规矩矩走一辈子，岁月不止，奋斗不息，就做这样的自己！
Java之美：
如果你执着于技术，欢迎您的加入！
(1)(5)(6)(25)(10)(7)(65)(57)(27)(42)(10)
