Google Map Reduce
英文原文链接: Google Map Reduce 译文原文链接: Google MapReduce中文版
Google File System
英文原文地址: Google File system 译文原文地址: The Google File System中文版
|
|||||
|
Jdon总结的NoSQL的分类，转在此：原文链接 NoSQL = HVSP 无(传统关系数据库的)join或明显事务的高容量简单处理。 按照数据模型保存性质将当前NoSQL分为四种： 1.Key-value stores键值存储, 保存keys+BLOBs (二进制大对象Binary Large OBjects) 2.Table-oriented 面向表, 主要有Google的BigTable和Cassandra. 3.Document-oriented面向文本, 文本是一种类似XML文档，MongoDB 和 CouchDB 4.Graph-oriented 面向图论. 如Neo4J. NoSQL一般都是分布式数据库，高性能是其特点，因此，数据是如何被分布、复制/碎片以及合成就成为关键，这其中涉及你的应用对数据一致性的要求，见CAP原理，不同一致性处理方式决定不同类型： 1.基本上基于Dynamo. 核心思想就是在多个节点之间获得最终一致性就可以，即使你有时会读到脏数据. 好处是写数据时从来不会阻塞。那种强制性节点一致性，如2PC，两段事务提交将会让你的写关闭停顿，使用Dynamo-like风格你能将数据写到多个节点中，通过一致hashing，然后你可以从这些节点读取数据，返回正确结果给用户。 2.基本基于BigTable. 这种模型中，使用常用方式保持节点充分的一致性。比如同步复制，由数据自己活或数据所在位置来实现一致性，不同产品实现细节不一样。 比如：MongoDB有一个面向文本类型的数据模型, 它采取类似BigTable-like 复制策略；Cassandra有面向表table-like数据模型, 采取的是Dynamo-like风格. 以后应该有数据是如何被持久化保存到磁盘上的区分，不同NoSQL处理策略不一样，有的是写一次保存一次；有的是定期保存，后者性能要好些。 当然，也有按照列记录来划分的，见http://nosql-database.org/ Amazon Dynamo 论文。几乎所有懂 NoSQL 的人都阅读过它。 Google 的 Bigtable 论文。 也许您已经耳熟能详。 Werner Vogels 的 Eventually Consistent （发布于 ACM Queue）。如果您对最终一致性不是非常清晰，请阅读这篇文章。 Brewer 的 CAP 理论（可伸缩性的基础）在这里可以找到非常好的诠释。也可以看看 2000 7 月 PODC 上 Brewer的原始幻灯片。 在 2009 年 6 月在 SFO 的 NoSQL 见面会的幻灯片。这些资料可以用经典的、关键的、将影响巨大的、值得纪念的来形容。 SQL Databases Don’t Scale 是一篇简短、基础、直切问题的文章。除非您是一位在伸缩性问题上身经百战的数据库管理员，否则，这篇文章讲述的内容对于您可能是非常关键的。 Jonathan Ellis 的文章 NoSQL Ecosystem 以表格的方式对当今主流的分布式数据库做了比较。类似的比较还有 Quick Reference to Alternative data storages。Ellis [...] |
|||||
|
Copyright © 2010 Bookcold's Blog - All Rights Reserved |
|||||