以前一直有用MongoDB，但是听说facebook近日放弃了Cassandra改用HBase，实在是有些震惊。
下面的一个新闻更让人心动，这时真不知该用哪个好了。。。。。
这几天发现“我记录”网站有些问题，时常打不开。。。。。老是处于载入中。。。。
错误如下：
url=http://www.wojilu.com/
ex.Message=超时时间已到。在操作完成之前超时时间已过或服务器未响应。
ex.Source=.Net SqlClient Data Provider
ex.StackTrace= 在 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
在 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
在 System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
在 System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
在 System.Data.SqlClient.TdsParserStateObject.ReadPacket(Int32 bytesExpected)
在 System.Data.SqlClient.TdsParserStateObject.ReadBuffer()
在 System.Data.SqlClient.TdsParserStateObject.ReadByte()
在 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
在 System.Data.SqlClient.SqlInternalConnectionTds.CompleteLogin(Boolean enlistOK)
在 System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
在 System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
在 System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
在 System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)
在 System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)
在 System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)
在 System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
在 System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
在 System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
在 System.Data.SqlClient.SqlConnection.Open()
在 wojilu.Data.SQLServerDatabaseChecker.CheckTable(MappingClass mapping, String db) 位置 D:\Projects\wojilu\wojilu\Data\DbChecker\SQLServerDatabaseChecker.cs:行号 62
在 wojilu.ORM.MappingClass.checkMultiDB(MappingClass map) 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 306
在 wojilu.ORM.MappingClass.loadByReflection() 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 171
在 wojilu.ORM.MappingClass.loadInstance() 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 109
在 wojilu.ORM.MappingClass..cctor() 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 98
建议“我记录”的缓存设计参考一下Twitter设计的缓存插件cache-money，有如下特点：
提供的是write-through的缓存模式：
在ActiveRecord对象更新的时候不是将缓存中的数据清除，而是直接将更新的内容写入到缓存中去。可以参考这篇文章 http://magicscalingsprinkles.wordpress.com/2008/11/24/write-through-cacheing-is-an-essential-part-of-a-healthy-scaling-strategy/
cache-money有许多很棒的特性：
1. 缓存自动清除机制(利用after_save/after_destroy)
2. 支持事务，由于rails的Active Record没有提供after_commit机制，目前常见的缓存插件在高并发下会出现缓存更新竞争冲突，而这个特性对于解决这个问题会很有帮助：
C# 版CacheMoney下载：
https://github.com/tommyk/CacheMoney
近日发现nosql竟然还有C#的实现版本：
RavenDB 是个新的.NET开源文档数据库。
项目主页：http://github.com/ravendb/ravendb
http://www.opensource.org/advocacy/case_for_business.php
有兴趣的朋友可以学习一下。。。。
转载 Facebook：HBase每月存储1350亿条信息
也许你已经在一些地方看到这个消息，Facebook 已经开发一款新的社会化收件箱，集成了电子邮件、即时通讯、短信、文本信息、Facebook站内信息。最重要的是，他们需要每个月存储 1350 亿条信息。他们在哪里存储这些信息？Facebook的Kannan Muthukkaruppan 在《信息背后的技术》一文中给出一个令人惊奇的答案：HBase。HBase 击败了MySQL、Cassandra和其他一些选项，成为了Facebook的选择。
为什么这一选择令人惊奇？Facebook 创建了Cassandra，其目的就是为了建造一个收件箱类型的应用程序，但是最终他们发现，Cassandra的一致性模型并不能很好地适用于 Facebook 新的实时信息系统。另外，Facebook 还有一个扩展的MySQL 架构，不过他们发现，当数据集和索引变大时，性能会变得让人无法忍受。另外，他们原本可以自己开发一套系统，但他们最终还是选择了 HBase。
HBase是一个可以横向扩张的表存储系统，能够为大规模数据提供速度极快的低等级更新。这正是信息系统所需要的功能。另外，HBase是一个基于列的键值存储系统，并且是构建于 BigTabe 模型之上。HBase善于根据键访问行，以及对于一系列的行进行扫描和过滤。同样，这也是信息系统所需要的功能。不过，它并不支持复杂查询。查询通常交给分析工具处理，比如 Hive，Facebook创建了Hive，目的是处理他们容量高达多个拍字节（petabyte）的数据仓库。同时，Hive 是基于Hadoop的文件系统HDFS，而HBase使用的也是这一文件系统。
Facebook 选择了HBase，因为他们对他们的应用进行了监视，并明白他们到底需要什么。他们所需要的是一个可以处理以下两种类型的数据模式：
1. 一小组经常变化的临时数据；
2. 一组不断增加但很少访问的数据。
这很有道理。当前收件箱里的邮件你只会看一次，之后你很少会再去翻看这些电子邮件。这两种类似的数据是如此不同，所以有人也许在想应该使用两种不同的系统。不过，很明显，HBase 能够很好地处理这两种类型的数据。他们如何处理常规的搜索功能，尚不清楚，因为这并非 HBase 的优势所在，不过，HBase 可以集成多个搜索系统。
Facebook 系统的一些关键点：
● HBase：
○ 具有比Cassandra更简洁的一致性模型。
○ 对于他们的数据模式具有很好的扩展能力和处理能力。
○ 大多数功能能够满足他们的需求：自动加载平衡和故障转移、压缩支持功能、单个服务器的多碎片功能等。
○ HBase 所使用的文件系统HDFS，支持复制、端对端校验和，以及自动再次平衡。
○ Facebook 的运营团队具有丰富的HDFS使用经验，因为Facebook是Hadoop的大用户，而Hadoop使用 HDFS 作为它的分布式文件系统。
● Haystack 用于存储附件。
● 从无到有，编写可自定义的应用程序服务器，其目的是为了满足多个不同来源流入的大量信息。
● 用户发现服务（user discovery service）构建于 Zookeeper 之上。
● 对于以下功能可访问架构服务：电子邮件账号验证、好友关系、隐私决策以及发送决策（通过聊天工具或短信发送一条消息？）
● 保持小团队做大事情的一贯作风，15 位工程师在一年内发布了 20 项新的架构服务。
● Facebook将不会对单个数据库平台进行标准化，对于不同的任务他们将使用不同的平台。
Facebook 通过选择HBase将极大地推动该系统的采用，同时Facebook具有丰富的 HDFS/Hadoop/Hive 使用经验。想到这些，就让人兴奋的无法入睡。这是任何一款产品的梦想：成为另一个非常流行的产品的搭档，并期待成为其生态系统的一部分。这正是 HBase 所取得的成功。HBase 已经在许多方面去多了不错的成绩：实时、分布、线性扩展、健壮、BigData、开源、键值、面对列，我们将会看到 HBase 变得更加流行，尤其是它已经获得了 Facebook 的眷顾和青睐。
HBase是一个分布式的、面向列的开源数据库，该技术来源于 Chang et al所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的 Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.另一个不同的是HBase基于列的而不是基于行的模式。HBase使用和Bigtable非常相同的数据模型。用户存储数据行在一个表里。一个数据行拥有一个可选择的键和任意数量的列。表是疏松的存储的，因此用户可以给行定义各种不同的列。HBase主要用于需要随机访问，实时读写你的大数据（Big Data）。
HBase 架构图
http://club.sm160.com/showtopic-854193.aspx
淘宝海量数据库也采用了类似于Goolge的BigTable的数据组织方式，例如：
下面的一个新闻更让人心动，这时真不知该用哪个好了。。。。。
这几天发现“我记录”网站有些问题，时常打不开。。。。。老是处于载入中。。。。
错误如下：
url=http://www.wojilu.com/
ex.Message=超时时间已到。在操作完成之前超时时间已过或服务器未响应。
ex.Source=.Net SqlClient Data Provider
ex.StackTrace= 在 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
在 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
在 System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
在 System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
在 System.Data.SqlClient.TdsParserStateObject.ReadPacket(Int32 bytesExpected)
在 System.Data.SqlClient.TdsParserStateObject.ReadBuffer()
在 System.Data.SqlClient.TdsParserStateObject.ReadByte()
在 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
在 System.Data.SqlClient.SqlInternalConnectionTds.CompleteLogin(Boolean enlistOK)
在 System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
在 System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
在 System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
在 System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)
在 System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)
在 System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)
在 System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
在 System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
在 System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
在 System.Data.SqlClient.SqlConnection.Open()
在 wojilu.Data.SQLServerDatabaseChecker.CheckTable(MappingClass mapping, String db) 位置 D:\Projects\wojilu\wojilu\Data\DbChecker\SQLServerDatabaseChecker.cs:行号 62
在 wojilu.ORM.MappingClass.checkMultiDB(MappingClass map) 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 306
在 wojilu.ORM.MappingClass.loadByReflection() 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 171
在 wojilu.ORM.MappingClass.loadInstance() 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 109
在 wojilu.ORM.MappingClass..cctor() 位置 D:\Projects\wojilu\wojilu\ORM\MappingClass.cs:行号 98
建议“我记录”的缓存设计参考一下Twitter设计的缓存插件cache-money，有如下特点：
提供的是write-through的缓存模式：
在ActiveRecord对象更新的时候不是将缓存中的数据清除，而是直接将更新的内容写入到缓存中去。可以参考这篇文章 http://magicscalingsprinkles.wordpress.com/2008/11/24/write-through-cacheing-is-an-essential-part-of-a-healthy-scaling-strategy/
cache-money有许多很棒的特性：
1. 缓存自动清除机制(利用after_save/after_destroy)
2. 支持事务，由于rails的Active Record没有提供after_commit机制，目前常见的缓存插件在高并发下会出现缓存更新竞争冲突，而这个特性对于解决这个问题会很有帮助：
C# 版CacheMoney下载：
https://github.com/tommyk/CacheMoney
近日发现nosql竟然还有C#的实现版本：
RavenDB 是个新的.NET开源文档数据库。
项目主页：http://github.com/ravendb/ravendb
http://www.opensource.org/advocacy/case_for_business.php
有兴趣的朋友可以学习一下。。。。
转载 Facebook：HBase每月存储1350亿条信息
也许你已经在一些地方看到这个消息，Facebook 已经开发一款新的社会化收件箱，集成了电子邮件、即时通讯、短信、文本信息、Facebook站内信息。最重要的是，他们需要每个月存储 1350 亿条信息。他们在哪里存储这些信息？Facebook的Kannan Muthukkaruppan 在《信息背后的技术》一文中给出一个令人惊奇的答案：HBase。HBase 击败了MySQL、Cassandra和其他一些选项，成为了Facebook的选择。
为什么这一选择令人惊奇？Facebook 创建了Cassandra，其目的就是为了建造一个收件箱类型的应用程序，但是最终他们发现，Cassandra的一致性模型并不能很好地适用于 Facebook 新的实时信息系统。另外，Facebook 还有一个扩展的MySQL 架构，不过他们发现，当数据集和索引变大时，性能会变得让人无法忍受。另外，他们原本可以自己开发一套系统，但他们最终还是选择了 HBase。
HBase是一个可以横向扩张的表存储系统，能够为大规模数据提供速度极快的低等级更新。这正是信息系统所需要的功能。另外，HBase是一个基于列的键值存储系统，并且是构建于 BigTabe 模型之上。HBase善于根据键访问行，以及对于一系列的行进行扫描和过滤。同样，这也是信息系统所需要的功能。不过，它并不支持复杂查询。查询通常交给分析工具处理，比如 Hive，Facebook创建了Hive，目的是处理他们容量高达多个拍字节（petabyte）的数据仓库。同时，Hive 是基于Hadoop的文件系统HDFS，而HBase使用的也是这一文件系统。
Facebook 选择了HBase，因为他们对他们的应用进行了监视，并明白他们到底需要什么。他们所需要的是一个可以处理以下两种类型的数据模式：
1. 一小组经常变化的临时数据；
2. 一组不断增加但很少访问的数据。
这很有道理。当前收件箱里的邮件你只会看一次，之后你很少会再去翻看这些电子邮件。这两种类似的数据是如此不同，所以有人也许在想应该使用两种不同的系统。不过，很明显，HBase 能够很好地处理这两种类型的数据。他们如何处理常规的搜索功能，尚不清楚，因为这并非 HBase 的优势所在，不过，HBase 可以集成多个搜索系统。
Facebook 系统的一些关键点：
● HBase：
○ 具有比Cassandra更简洁的一致性模型。
○ 对于他们的数据模式具有很好的扩展能力和处理能力。
○ 大多数功能能够满足他们的需求：自动加载平衡和故障转移、压缩支持功能、单个服务器的多碎片功能等。
○ HBase 所使用的文件系统HDFS，支持复制、端对端校验和，以及自动再次平衡。
○ Facebook 的运营团队具有丰富的HDFS使用经验，因为Facebook是Hadoop的大用户，而Hadoop使用 HDFS 作为它的分布式文件系统。
● Haystack 用于存储附件。
● 从无到有，编写可自定义的应用程序服务器，其目的是为了满足多个不同来源流入的大量信息。
● 用户发现服务（user discovery service）构建于 Zookeeper 之上。
● 对于以下功能可访问架构服务：电子邮件账号验证、好友关系、隐私决策以及发送决策（通过聊天工具或短信发送一条消息？）
● 保持小团队做大事情的一贯作风，15 位工程师在一年内发布了 20 项新的架构服务。
● Facebook将不会对单个数据库平台进行标准化，对于不同的任务他们将使用不同的平台。
Facebook 通过选择HBase将极大地推动该系统的采用，同时Facebook具有丰富的 HDFS/Hadoop/Hive 使用经验。想到这些，就让人兴奋的无法入睡。这是任何一款产品的梦想：成为另一个非常流行的产品的搭档，并期待成为其生态系统的一部分。这正是 HBase 所取得的成功。HBase 已经在许多方面去多了不错的成绩：实时、分布、线性扩展、健壮、BigData、开源、键值、面对列，我们将会看到 HBase 变得更加流行，尤其是它已经获得了 Facebook 的眷顾和青睐。
HBase是一个分布式的、面向列的开源数据库，该技术来源于 Chang et al所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的 Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.另一个不同的是HBase基于列的而不是基于行的模式。HBase使用和Bigtable非常相同的数据模型。用户存储数据行在一个表里。一个数据行拥有一个可选择的键和任意数量的列。表是疏松的存储的，因此用户可以给行定义各种不同的列。HBase主要用于需要随机访问，实时读写你的大数据（Big Data）。
HBase 架构图
http://club.sm160.com/showtopic-854193.aspx
淘宝海量数据库也采用了类似于Goolge的BigTable的数据组织方式，例如：
- 每个表按主键(row key)组成一个B+树；
- 主键是binary string；
- 一 个叶子节点包含表的一个前开后闭的主键范围(rk1，rk2]内的数据；
- 每个叶子节点内部按更小的主键范围划分为多个块 (block)并内建块索引(block index)；
- 每个块的大小通常在8KB~64KB之间并内建行索引；
- 数 据压缩以块为单位；
- 数据压缩算法由用户指定并可随时变更；
- 每个叶子节点的大小可在一定范围内波动 (例如上下50%)；
- 叶子节点可能合并或者分裂；
- 所有叶子节点基本上是均匀、随机地分布在多台机器 (称为chunk server)上；
- 通常情况下每个叶子节点有3个副本；
- 叶子节点是负载平衡和任 务调度的基本单元；
- 允许bloom filter；
- ......
- 主键(binary string)可以有结构或其他约束；
- 值有多种数据类型(数值，字符串， 时间…)；
- 类似于DBMS的schema并且根据schema进行强制数据类型检查；
- 没有 BigTable的column family及qualifier；
- 支持稀疏表，也支持稠密表；
- 叶 子节点的每个副本同时提供服务；
- 没有支持BigTable一个cell多个时间(timestamp)版本；
- ......
4649
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
