元数据nosql,元数据标准
elasticsearch可以代替NoSQL吗
我们使用Elasticsearch存储的文档数量接近50亿(算上1份复制,接近100亿文档),总共10个数据节点和2个元数据节点(48GB内存,8核心CPU,ES使用内存达到70%),每天的文档增量大概是3000W条(速度持续增加中)。目前来看,单个文档的查询效率基本处于实时状态;对于1到2周的数据的聚合统计操作也可以在10秒之内返回结果。
专注于为中小企业提供成都网站建设、做网站服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业保定免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了近千家企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。
但是,还有提升的空间:
1. 对于查询单条数据的应用场景来说,我们可以使用ES的路由机制,将同一索引内的具有相同特征(比如具有相同的userid)的文档全部存储于一个节点上,这样我们之后的查询都可以直接定位到这个节点上,而不用将查询广播道所有的节点上;
2. 随着数据节点的增加,适当增加分片数量,提升系统的分布水平,也可以通过分而治之的方式优化查询性能;
个人以为Elasticsearch作为内部存储来说还是不错的,效率也基本能够满足,在某些方面替代传统DB也是可以的,前提是你的业务不对操作的事性务有特殊要求;而权限管理也不用那么细,因为ES的权限这块还不完善。由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作,没有大量的单文档请求(比如通过userid来找到一个用户的文档,类似于NoSQL的应用场景),所以能否替代NoSQL还需要各位自己的测试。如果让我选择的话,我会尝试使用ES来替代传统的NoSQL,因为它的横向扩展机制太方便了。
在我的工作过程中,我深切体会到:经验固然是一个很重要的东西,因为它能够帮助我们少走很多弯路,但同时也应该看到经验的另一面——它会变成一个笼子,将我们闭塞其中,使我们错过一些可能更好的解决方案,关键是我们要学会尝试,接触新的世界。
NoSQL-HDFS-基本概念
Hadoop
文件系统:文件系统是用来存储和管理文件,并且提供文件的查询、增加、删除等操作。
直观上的体验:在shell窗口输入 ls 命令,就可以看到当前目录下的文件夹、文件。
文件存储在哪里?硬盘
一台只有250G硬盘的电脑,如果需要存储500G的文件可以怎么办?先将电脑硬盘扩容至少250G,再将文件分割成多块,放到多块硬盘上储存。
通过 hdfs dfs -ls 命令可以查看分布式文件系统中的文件,就像本地的ls命令一样。
HDFS在客户端上提供了查询、新增和删除的指令,可以实现将分布在多台机器上的文件系统进行统一的管理。
在分布式文件系统中,一个大文件会被切分成块,分别存储到几台机器上。结合上文中提到的那个存储500G大文件的那个例子,这500G的文件会按照一定的大小被切分成若干块,然后分别存储在若干台机器上,然后提供统一的操作接口。
看到这里,不少人可能会觉得,分布式文件系统不过如此,很简单嘛。事实真的是这样的么?
潜在问题
假如我有一个1000台机器组成的分布式系统,一台机器每天出现故障的概率是0.1%,那么整个系统每天出现故障的概率是多大呢?答案是(1-0.1%)^1000=63%,因此需要提供一个容错机制来保证发生差错时文件依然可以读出,这里暂时先不展开介绍。
如果要存储PB级或者EB级的数据,成千上万台机器组成的集群是很常见的,所以说分布式系统比单机系统要复杂得多呀。
这是一张HDFS的架构简图:
client通过nameNode了解数据在哪些DataNode上,从而发起查询。此外,不仅是查询文件,写入文件的时候也是先去请教NameNode,看看应该往哪个DateNode中去写。
为了某一份数据只写入到一个Datanode中,而这个Datanode因为某些原因出错无法读取的问题,需要通过冗余备份的方式来进行容错处理。因此,HDFS在写入一个数据块的时候,不会仅仅写入一个DataNode,而是会写入到多个DataNode中,这样,如果其中一个DataNode坏了,还可以从其余的DataNode中拿到数据,保证了数据不丢失。
实际上,每个数据块在HDFS上都会保存多份,保存在不同的DataNode上。这种是牺牲一定存储空间换取可靠性的做法。
接下来我们来看一下完整的文件写入的流程:
大文件要写入HDFS,client端根据配置将大文件分成固定大小的块,然后再上传到HDFS。
读取文件的流程:
1、client询问NameNode,我要读取某个路径下的文件,麻烦告诉我这个文件都在哪些DataNode上?
2、NameNode回复client,这个路径下的文件被切成了3块,分别在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4,拿到3个文件块,通过stream读取并且整合起来
文件写入的流程:
1、client先将文件分块,然后询问NameNode,我要写入一个文件到某个路径下,文件有3块,应该怎么写?
2、NameNode回复client,可以分别写到DataNode1、DataNode2、DataNode3、DataNode4上,记住,每个块重复写3份,总共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4,把数据写到他们上面
出于容错的考虑,每个数据块有3个备份,但是3个备份快都直接由client端直接写入势必会带来client端过重的写入压力,这个点是否有更好的解决方案呢?回忆一下mysql主备之间是通过binlog文件进行同步的,HDFS当然也可以借鉴这个思想,数据其实只需要写入到一个datanode上,然后由datanode之间相互进行备份同步,减少了client端的写入压力,那么至于是一个datanode写入成功即成功,还是需要所有的参与备份的datanode返回写入成功才算成功,是可靠性配置的策略,当然这个设置会影响到数据写入的吞吐率,我们可以看到可靠性和效率永远是“鱼和熊掌不可兼得”的。
潜在问题
NameNode确实会回放editlog,但是不是每次都从头回放,它会先加载一个fsimage,这个文件是之前某一个时刻整个NameNode的文件元数据的内存快照,然后再在这个基础上回放editlog,完成后,会清空editlog,再把当前文件元数据的内存状态写入fsimage,方便下一次加载。
这样,全量回放就变成了增量回放,但是如果NameNode长时间未重启过,editlog依然会比较大,恢复的时间依然比较长,这个问题怎么解呢?
SecondNameNode是一个NameNode内的定时任务线程,它会定期地将editlog写入fsimage,然后情况原来的editlog,从而保证editlog的文件大小维持在一定大小。
NameNode挂了, SecondNameNode并不能替代NameNode,所以如果集群中只有一个NameNode,它挂了,整个系统就挂了。hadoop2.x之前,整个集群只能有一个NameNode,是有可能发生单点故障的,所以hadoop1.x有本身的不稳定性。但是hadoop2.x之后,我们可以在集群中配置多个NameNode,就不会有这个问题了,但是配置多个NameNode,需要注意的地方就更多了,系统就更加复杂了。
俗话说“一山不容二虎”,两个NameNode只能有一个是活跃状态active,另一个是备份状态standby,我们看一下两个NameNode的架构图。
两个NameNode通过JournalNode实现同步editlog,保持状态一致可以相互替换。
因为active的NameNode挂了之后,standby的NameNode要马上接替它,所以它们的数据要时刻保持一致,在写入数据的时候,两个NameNode内存中都要记录数据的元信息,并保持一致。这个JournalNode就是用来在两个NameNode中同步数据的,并且standby NameNode实现了SecondNameNode的功能。
进行数据同步操作的过程如下:
active NameNode有操作之后,它的editlog会被记录到JournalNode中,standby NameNode会从JournalNode中读取到变化并进行同步,同时standby NameNode会监听记录的变化。这样做的话就是实时同步了,并且standby NameNode就实现了SecondNameNode的功能。
优点:
缺点:
目前哪些NoSQL数据库应用广泛,各有什么特点
特点:
它们可以处理超大量的数据。
它们运行在便宜的PC服务器集群上。
PC集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。
它们击碎了性能瓶颈。
NoSQL的支持者称,通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间,执行速度变得更快。
“SQL并非适用于所有的程序代码,” 对于那些繁重的重复操作的数据,SQL值得花钱。但是当数据库结构非常简单时,SQL可能没有太大用处。
没有过多的操作。
虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合,而且在数据完整性上也发挥绝对稳定,他们同时也表示,企业的具体需求可能没有那么多。
Bootstrap支持
因为NoSQL项目都是开源的,因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样,不得不从社区中寻求支持。
优点:
易扩展
NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。
大数据量,高性能
NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用 Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的 Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。
灵活的数据模型
NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
高可用
NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。
主要应用:
Apache HBase
这个大数据管理平台建立在谷歌强大的BigTable管理引擎基础上。作为具有开源、Java编码、分布式多个优势的数据库,Hbase最初被设计应用于Hadoop平台,而这一强大的数据管理工具,也被Facebook采用,用于管理消息平台的庞大数据。
Apache Storm
用于处理高速、大型数据流的分布式实时计算系统。Storm为Apache Hadoop添加了可靠的实时数据处理功能,同时还增加了低延迟的仪表板、安全警报,改进了原有的操作方式,帮助企业更有效率地捕获商业机会、发展新业务。
Apache Spark
该技术采用内存计算,从多迭代批量处理出发,允许将数据载入内存做反复查询,此外还融合数据仓库、流处理和图计算等多种计算范式,Spark用Scala语言实现,构建在HDFS上,能与Hadoop很好的结合,而且运行速度比MapReduce快100倍。
Apache Hadoop
该技术迅速成为了大数据管理标准之一。当它被用来管理大型数据集时,对于复杂的分布式应用,Hadoop体现出了非常好的性能,平台的灵活性使它可以运行在商用硬件系统,它还可以轻松地集成结构化、半结构化和甚至非结构化数据集。
Apache Drill
你有多大的数据集?其实无论你有多大的数据集,Drill都能轻松应对。通过支持HBase、Cassandra和MongoDB,Drill建立了交互式分析平台,允许大规模数据吞吐,而且能很快得出结果。
Apache Sqoop
也许你的数据现在还被锁定于旧系统中,Sqoop可以帮你解决这个问题。这一平台采用并发连接,可以将数据从关系数据库系统方便地转移到Hadoop中,可以自定义数据类型以及元数据传播的映射。事实上,你还可以将数据(如新的数据)导入到HDFS、Hive和Hbase中。
Apache Giraph
这是功能强大的图形处理平台,具有很好可扩展性和可用性。该技术已经被Facebook采用,Giraph可以运行在Hadoop环境中,可以将它直接部署到现有的Hadoop系统中。通过这种方式,你可以得到强大的分布式作图能力,同时还能利用上现有的大数据处理引擎。
Cloudera Impala
Impala模型也可以部署在你现有的Hadoop群集上,监视所有的查询。该技术和MapReduce一样,具有强大的批处理能力,而且Impala对于实时的SQL查询也有很好的效果,通过高效的SQL查询,你可以很快的了解到大数据平台上的数据。
Gephi
它可以用来对信息进行关联和量化处理,通过为数据创建功能强大的可视化效果,你可以从数据中得到不一样的洞察力。Gephi已经支持多个图表类型,而且可以在具有上百万个节点的大型网络上运行。Gephi具有活跃的用户社区,Gephi还提供了大量的插件,可以和现有系统完美的集成到一起,它还可以对复杂的IT连接、分布式系统中各个节点、数据流等信息进行可视化分析。
MongoDB
这个坚实的平台一直被很多组织推崇,它在大数据管理上有极好的性能。MongoDB最初是由DoubleClick公司的员工创建,现在该技术已经被广泛的应用于大数据管理。MongoDB是一个应用开源技术开发的NoSQL数据库,可以用于在JSON这样的平台上存储和处理数据。目前,纽约时报、Craigslist以及众多企业都采用了MongoDB,帮助他们管理大型数据集。(Couchbase服务器也作为一个参考)。
十大顶尖公司:
Amazon Web Services
Forrester将AWS称为“云霸主”,谈到云计算领域的大数据,那就不得不提到亚马逊。该公司的Hadoop产品被称为EMR(Elastic Map Reduce),AWS解释这款产品采用了Hadoop技术来提供大数据管理服务,但它不是纯开源Hadoop,经过修改后现在被专门用在AWS云上。
Forrester称EMR有很好的市场前景。很多公司基于EMR为客户提供服务,有一些公司将EMR应用于数据查询、建模、集成和管理。而且AWS还在创新,Forrester称未来EMR可以基于工作量的需要自动缩放调整大小。亚马逊计划为其产品和服务提供更强大的EMR支持,包括它的RedShift数据仓库、新公布的Kenesis实时处理引擎以及计划中的NoSQL数据库和商业智能工具。不过AWS还没有自己的Hadoop发行版。
Cloudera
Cloudera有开源Hadoop的发行版,这个发行版采用了Apache Hadoop开源项目的很多技术,不过基于这些技术的发行版也有很大的进步。Cloudera为它的Hadoop发行版开发了很多功能,包括Cloudera管理器,用于管理和监控,以及名为Impala的SQL引擎等。Cloudera的Hadoop发行版基于开源Hadoop,但也不是纯开源的产品。当Cloudera的客户需要Hadoop不具备的某些功能时,Cloudera的工程师们就会实现这些功能,或者找一个拥有这项技术的合作伙伴。Forrester表示:“Cloudera的创新方法忠于核心Hadoop,但因为其可实现快速创新并积极满足客户需求,这一点使它不同于其他那些供应商。”目前,Cloudera的平台已经拥有200多个付费客户,一些客户在Cloudera的技术支持下已经可以跨1000多个节点实现对PB级数据的有效管理。
Hortonworks
和Cloudera一样,Hortonworks是一个纯粹的Hadoop技术公司。与Cloudera不同的是,Hortonworks坚信开源Hadoop比任何其他供应商的Hadoop发行版都要强大。Hortonworks的目标是建立Hadoop生态圈和Hadoop用户社区,推进开源项目的发展。Hortonworks平台和开源Hadoop联系紧密,公司管理人员表示这会给用户带来好处,因为它可以防止被供应商套牢(如果Hortonworks的客户想要离开这个平台,他们可以轻松转向其他开源平台)。这并不是说Hortonworks完全依赖开源Hadoop技术,而是因为该公司将其所有开发的成果回报给了开源社区,比如Ambari,这个工具就是由Hortonworks开发而成,用来填充集群管理项目漏洞。Hortonworks的方案已经得到了Teradata、Microsoft、Red Hat和SAP这些供应商的支持。
IBM
当企业考虑一些大的IT项目时,很多人首先会想到IBM。IBM是Hadoop项目的主要参与者之一,Forrester称IBM已有100多个Hadoop部署,它的很多客户都有PB级的数据。IBM在网格计算、全球数据中心和企业大数据项目实施等众多领域有着丰富的经验。“IBM计划继续整合SPSS分析、高性能计算、BI工具、数据管理和建模、应对高性能计算的工作负载管理等众多技术。”
Intel
和AWS类似,英特尔不断改进和优化Hadoop使其运行在自己的硬件上,具体来说,就是让Hadoop运行在其至强芯片上,帮助用户打破Hadoop系统的一些限制,使软件和硬件结合的更好,英特尔的Hadoop发行版在上述方面做得比较好。Forrester指出英特尔在最近才推出这个产品,所以公司在未来还有很多改进的可能,英特尔和微软都被认为是Hadoop市场上的潜力股。
MapR Technologies
MapR的Hadoop发行版目前为止也许是最好的了,不过很多人可能都没有听说过。Forrester对Hadoop用户的调查显示,MapR的评级最高,其发行版在架构和数据处理能力上都获得了最高分。MapR已将一套特殊功能融入其Hadoop发行版中。例如网络文件系统(NFS)、灾难恢复以及高可用性功能。Forrester说MapR在Hadoop市场上没有Cloudera和Hortonworks那样的知名度,MapR要成为一个真正的大企业,还需要加强伙伴关系和市场营销。
Microsoft
微软在开源软件问题上一直很低调,但在大数据形势下,它不得不考虑让Windows也兼容Hadoop,它还积极投入到开源项目中,以更广泛地推动Hadoop生态圈的发展。我们可以在微软的公共云Windows Azure HDInsight产品中看到其成果。微软的Hadoop服务基于Hortonworks的发行版,而且是为Azure量身定制的。
微软也有一些其他的项目,包括名为Polybase的项目,让Hadoop查询实现了SQLServer查询的一些功能。Forrester说:“微软在数据库、数据仓库、云、OLAP、BI、电子表格(包括PowerPivot)、协作和开发工具市场上有很大优势,而且微软拥有庞大的用户群,但要在Hadoop这个领域成为行业领导者还有很远的路要走。”
Pivotal Software
EMC和Vmware部分大数据业务分拆组合产生了Pivotal。Pivotal一直努力构建一个性能优越的Hadoop发行版,为此,Pivotal在开源Hadoop的基础上又添加了一些新的工具,包括一个名为HAWQ的SQL引擎以及一个专门解决大数据问题的Hadoop应用。Forrester称Pivotal Hadoop平台的优势在于它整合了Pivotal、EMC、Vmware的众多技术,Pivotal的真正优势实际上等于EMC和Vmware两大公司为其撑腰。到目前为止,Pivotal的用户还不到100个,而且大多是中小型客户。
Teradata
对于Teradata来说,Hadoop既是一种威胁也是一种机遇。数据管理,特别是关于SQL和关系数据库这一领域是Teradata的专长。所以像Hadoop这样的NoSQL平台崛起可能会威胁到Teradata。相反,Teradata接受了Hadoop,通过与Hortonworks合作,Teradata在Hadoop平台集成了SQL技术,这使Teradata的客户可以在Hadoop平台上方便地使用存储在Teradata数据仓库中的数据。
AMPLab
通过将数据转变为信息,我们才可以理解世界,而这也正是AMPLab所做的。AMPLab致力于机器学习、数据挖掘、数据库、信息检索、自然语言处理和语音识别等多个领域,努力改进对信息包括不透明数据集内信息的甄别技术。除了Spark,开源分布式SQL查询引擎Shark也源于AMPLab,Shark具有极高的查询效率,具有良好的兼容性和可扩展性。近几年的发展使计算机科学进入到全新的时代,而AMPLab为我们设想一个运用大数据、云计算、通信等各种资源和技术灵活解决难题的方案,以应对越来越复杂的各种难题。
为什么不用NoSQL
当为大家描述我们的整体服务架构时,最常见的两个问题是:
为什么采用结构化方式将数据存储在SQL数据库中,而不使用NoSQL平台?
为什么自己维护数据中心,而不将Evernote托管到云服务提供商?
这两个问题都很有趣,我们先来探讨第一个。
对特定的应用而言,相比一个单一的SQL实例,一个现代的键值存储引擎具备显著的性能优势和可扩展性。
CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
如果你在Windows客户端上创建了一个名为“Cooking”的记事本,并立即在其中粘贴了一个名为“Quick Tomato Sauce”的食谱,客户端会立刻进行如下同步:
调用NoteStore.createNotebook() 请求服务器创建记事本,并返回以创建记事本的GUID。
通过指定记事本的GUID,调用NoteStore.createNote()在记事本中创建笔记。
每次API调用都通过SQL事物予以实现,可以让客户端完全信任服务器的任何提示。ACID兼容的数据库可以做到这些:
原子性(Atomicity):如果API调用成功,那么所有的改动都会保存;如果API调用失败,所有的改动都不会提交。
一致性(Consistency): 在API调用完成后,所有的账户都可用,并能保证内部状态的一致性。每篇笔记都与记事本相关联,以避免出现孤立项。数据库不允许删除关联有记事的记事本,这得感谢FOREIGN KEY约束。
持久性(Durability):当服务器发送记事本已创建完毕的回执后,客户端会认为它的存在具有持久性,以便进行后续的操作。变更的持久性,可以让客户端知道在任何时刻对服务状态的影响都能保持一致性。
对我们的同步协议而言,持久性最为重要。如果客户端不能确定服务器端的变更具有持久性,那么协议将会变得复杂而低效。
“大数据”问题
得益于事务处理的数据库的ACID属性,同样使得数据集非常难以扩展,以超出单台服务器的范围。数据库集群和多主复制技术并不理想,键值存储为实现可扩展性提供了一条捷径。
所幸,Evernote暂时不需要考虑这个问题。即便是我们有近10亿的笔记,和近20亿的资源文件,这也并不能称得上是一个大数据集。通过按用户分区,它被划分成了2千万个独立的数据集。
我们尚未遇到所谓“大数据”引发的问题,倒是遇到了许多“中数据”的存储问题,这就是通过规整分区形成的分片存储架构。
也许以后……
我们对新的存储系统非常感兴趣,非常乐意应用在哪些对ACID要求不强,但确实需要横向扩展的新项目中。例如,我们的报告分析系统已经逐渐超出了MySQL平台的承受力,需要被更快、更先进的系统所取代。
我们现在对以Evernote用户元数据为基础的MySQL分片存储颇为满意,尽管这不会引起那些IT弄潮儿的兴趣。
nosql数据库有哪些
1. CouchDB
所用语言: Erlang
特点:DB一致性,易于使用
使用许可: Apache
协议: HTTP/REST
双向数据复制,
持续进行或临时处理,
处理时带冲突检查,
因此,采用的是master-master复制(见编注2)
MVCC – 写操作不阻塞读操作
可保存文件之前的版本
Crash-only(可靠的)设计
需要不时地进行数据压缩
视图:嵌入式 映射/减少
格式化视图:列表显示
支持进行服务器端文档验证
支持认证
根据变化实时更新
支持附件处理
因此, CouchApps(独立的 js应用程序)
需要 jQuery程序库
最佳应用场景:适用于数据变化较少,执行预定义查询,进行数据统计的应用程序。适用于需要提供数据版本支持的应用程序。
例如: CRM、CMS系统。 master-master复制对于多站点部署是非常有用的。
(编注2:master-master复制:是一种数据库同步方法,允许数据在一组计算机之间共享数据,并且可以通过小组中任意成员在组内进行数据更新。)
2. Redis
所用语言:C/C++
特点:运行异常快
使用许可: BSD
协议:类 Telnet
有硬盘存储支持的内存数据库,
但自2.0版本以后可以将数据交换到硬盘(注意, 2.4以后版本不支持该特性!)
Master-slave复制(见编注3)
虽然采用简单数据或以键值索引的哈希表,但也支持复杂操作,例如 ZREVRANGEBYSCORE。
INCR co (适合计算极限值或统计数据)
支持 sets(同时也支持 union/diff/inter)
支持列表(同时也支持队列;阻塞式 pop操作)
支持哈希表(带有多个域的对象)
支持排序 sets(高得分表,适用于范围查询)
Redis支持事务
支持将数据设置成过期数据(类似快速缓冲区设计)
Pub/Sub允许用户实现消息机制
最佳应用场景:适用于数据变化快且数据库大小可遇见(适合内存容量)的应用程序。
例如:股票价格、数据分析、实时数据搜集、实时通讯。
(编注3:Master-slave复制:如果同一时刻只有一台服务器处理所有的复制请求,这被称为
Master-slave复制,通常应用在需要提供高可用性的服务器集群。)
3. MongoDB
所用语言:C++
特点:保留了SQL一些友好的特性(查询,索引)。
使用许可: AGPL(发起者: Apache)
协议: Custom, binary( BSON)
Master/slave复制(支持自动错误恢复,使用 sets 复制)
内建分片机制
支持 javascript表达式查询
可在服务器端执行任意的 javascript函数
update-in-place支持比CouchDB更好
在数据存储时采用内存到文件映射
对性能的关注超过对功能的要求
建议最好打开日志功能(参数 –journal)
在32位操作系统上,数据库大小限制在约2.5Gb
空数据库大约占 192Mb
采用 GridFS存储大数据或元数据(不是真正的文件系统)
最佳应用场景:适用于需要动态查询支持;需要使用索引而不是 map/reduce功能;需要对大数据库有性能要求;需要使用
CouchDB但因为数据改变太频繁而占满内存的应用程序。
例如:你本打算采用 MySQL或 PostgreSQL,但因为它们本身自带的预定义栏让你望而却步。
4. Riak
所用语言:Erlang和C,以及一些Javascript
特点:具备容错能力
使用许可: Apache
协议: HTTP/REST或者 custom binary
可调节的分发及复制(N, R, W)
用 JavaScript or Erlang在操作前或操作后进行验证和安全支持。
使用JavaScript或Erlang进行 Map/reduce
连接及连接遍历:可作为图形数据库使用
索引:输入元数据进行搜索(1.0版本即将支持)
大数据对象支持( Luwak)
提供“开源”和“企业”两个版本
全文本搜索,索引,通过 Riak搜索服务器查询( beta版)
支持Masterless多站点复制及商业许可的 SNMP监控
最佳应用场景:适用于想使用类似 Cassandra(类似Dynamo)数据库但无法处理
bloat及复杂性的情况。适用于你打算做多站点复制,但又需要对单个站点的扩展性,可用性及出错处理有要求的情况。
例如:销售数据搜集,工厂控制系统;对宕机时间有严格要求;可以作为易于更新的 web服务器使用。
5. Membase
所用语言: Erlang和C
特点:兼容 Memcache,但同时兼具持久化和支持集群
使用许可: Apache 2.0
协议:分布式缓存及扩展
非常快速(200k+/秒),通过键值索引数据
可持久化存储到硬盘
所有节点都是唯一的( master-master复制)
在内存中同样支持类似分布式缓存的缓存单元
写数据时通过去除重复数据来减少 IO
提供非常好的集群管理 web界面
更新软件时软无需停止数据库服务
支持连接池和多路复用的连接代理
最佳应用场景:适用于需要低延迟数据访问,高并发支持以及高可用性的应用程序
例如:低延迟数据访问比如以广告为目标的应用,高并发的 web 应用比如网络游戏(例如 Zynga)
6. Neo4j
所用语言: Java
特点:基于关系的图形数据库
使用许可: GPL,其中一些特性使用 AGPL/商业许可
协议: HTTP/REST(或嵌入在 Java中)
可独立使用或嵌入到 Java应用程序
图形的节点和边都可以带有元数据
很好的自带web管理功能
使用多种算法支持路径搜索
使用键值和关系进行索引
为读操作进行优化
支持事务(用 Java api)
使用 Gremlin图形遍历语言
支持 Groovy脚本
支持在线备份,高级监控及高可靠性支持使用 AGPL/商业许可
最佳应用场景:适用于图形一类数据。这是 Neo4j与其他nosql数据库的最显著区别
例如:社会关系,公共交通网络,地图及网络拓谱
7. Cassandra
所用语言: Java
特点:对大型表格和 Dynamo支持得最好
使用许可: Apache
协议: Custom, binary (节约型)
可调节的分发及复制(N, R, W)
支持以某个范围的键值通过列查询
类似大表格的功能:列,某个特性的列集合
写操作比读操作更快
基于 Apache分布式平台尽可能地 Map/reduce
我承认对 Cassandra有偏见,一部分是因为它本身的臃肿和复杂性,也因为 Java的问题(配置,出现异常,等等)
最佳应用场景:当使用写操作多过读操作(记录日志)如果每个系统组建都必须用 Java编写(没有人因为选用
Apache的软件被解雇)
例如:银行业,金融业(虽然对于金融交易不是必须的,但这些产业对数据库的要求会比它们更大)写比读更快,所以一个自然的特性就是实时数据分析
8. HBase
(配合 ghshephard使用)
所用语言: Java
特点:支持数十亿行X上百万列
使用许可: Apache
协议:HTTP/REST (支持 Thrift,见编注4)
在 BigTable之后建模
采用分布式架构 Map/reduce
对实时查询进行优化
高性能 Thrift网关
通过在server端扫描及过滤实现对查询操作预判
支持 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基于 Jruby( JIRB)的shell
对配置改变和较小的升级都会重新回滚
不会出现单点故障
堪比MySQL的随机访问性能
最佳应用场景:适用于偏好BigTable:)并且需要对大数据进行随机、实时访问的场合。
例如: Facebook消息数据库(更多通用的用例即将出现)
编注4:Thrift
是一种接口定义语言,为多种其他语言提供定义和创建服务,由Facebook开发并开源。
当然,所有的系统都不只具有上面列出的这些特性。这里我仅仅根据自己的观点列出一些我认为的重要特性。与此同时,技术进步是飞速的,所以上述的内容肯定需要不断更新。我会尽我所能地更新这个列表。
当前标题:元数据nosql,元数据标准
转载源于:http://myzitong.com/article/hogsgg.html