甲骨文发布高效能备份解决方案SunZFS Backup Appliance，专为Oracle整合式系统设计的解决方案而设计，包括OracleExadata数据库机器、OracleExalogicElasticCloud及OracleSPARCSuperClusterT4-4。

在一般用途的储存系统中，OracleSunZFS为Oracle整合式系统的数据保护提供最快的复原速度，包含每小时20TB完整备份，以及每小时9.4TB的完整还原流量。而 SunZFS备份应用以极致迅速的备份性能备份特定数据，不需要额外的主机端软件或CPU资源，即可达到高速的备份效能。 OracleSunZFS经过Oracle整合式系统的测试、验证和支持，实现卓越的运行速度，操作简易且有助于降低成本。

Oracle软硬件整合技术，实现卓越的数据保护效能和极高的投资报酬率，在SunZFS透过最佳化可预测的自我修复(self-healing)功能，以及自动检测、判断潜在问题的故障管理架构，降低还原失败的风险。端对端的数据检查汇总功能亦可自动检查、修复损坏数据至位(bit)单位。

SunZFS运用OracleRecoveryManager(RMAN)，以TCP/IP直接连接InfiniBand，比其它竞争解决方案表现出更卓越的效率和成本效益，且不需额外的服务器及昂贵的第三方备份软件。透过全面性的效能和最佳化的储存空间，加以完整执行甲骨文推荐的RMAN和累积备份程序，SunZFS放弃复杂而昂贵的数据保护程序。

SunZFS的Oracle混合列式压缩(HybridColumnarCompression；HCC)，透过有效运用数据和系统，达成更高的投资报酬率，包含SunZFS在内的Oracle储存产品，是唯一能复制(clone)同时维持系统运行于HCC压缩数据库副本的储存解决方案。复制HCC压缩表格的快照无须耗用解压缩的效能，可同时用于测试和开发、质量保证、报表和额外的数据保护。

OracleSunZFS可快速、简易地配置、部署和管理，并提供高效能和高容量2种配置的选择，为用户预先安装机架及电缆，免除硬件调校。OracleSunZFS和甲骨文完整的软件堆栈整合，从Oracle应用软件到Oracle数据库、OracleVM及OracleExadata数据库机器、OracleExalogicElasticCloud和OracleSPARCSuperClusterT4-4。

甲骨文储存产品资深副总裁PhilBullinger表示，企业营运高度依赖数据库的可用性，数据的快速备份和复原对企业而言极其重要。OracleSunZFS专为Oracle整合式系统量身打造，充分利用软硬件整合的优势，以快速、简易、节省的成本为客户提供卓越效能，保护客户的数据，满足其严谨的还原时间要求。

日本东京一名男子，因为搜索引擎Google自动跳出的搜索建议，控告Google公司侵犯隐私权，不但要求Google停止搜索建议的功能，同时要求赔偿其精神损失。

日本共同社报道，这名男子表示，当他在Google的搜索功能中，输入自己的名字，会自动补充与他无关的一连串讯息，包含一些犯罪行为，这让他很苦恼。

这名男子声称，他突然被前公司解雇，找工作也很不顺利，让他百思不得其解，后来才发现，如果用Google查他的名字，会出现一些对他造成诽谤的内容。这名男子曾经去函，要求Google删除相关内容，但一直没有得到Google的回应。

(编译/cnITinfo.COM)

对于互联网用户来说，搜索是一件非常简单的事情。在搜索框输入关键词，回车（或点击搜索框），等待。而对于搜索公司来说，这是一个复杂的技术问题。从你开始搜索到获得结果的短暂时间里，究竟发生了什么？从 Google 发给 Mashable 网站的这副信息图里，我们可以了解到一些相关的数据。

搜索之前

在你进行搜索之前，Google 的搜索爬虫已经走遍了整个网络，它们从一个链接跳到另一个链接，将数据带回 Google 的服务器。网络就像是一本书，Google 的工作就是为图书建立目录。

Google 建立的目录，其容量已经超过 1 亿 GB。目前为止，Google 已经花费了 100 万个小时来构建目录。

搜索之时

从 查询开始到获得结果，搜索查询的平均旅行路程是 1500 公里。在此过程中，它可能经过全球不同的数据中心。根据 Google 的说法，1500 是一个平均数字，具体到每次搜索产生的路程不会这么长，因为 Google 总是会寻找最近的数据中心。在用户键入搜索查询的时候，Google 就开始提供对查询的预测，以减少键入时间，这就是 Google Instant。

排名

Google 的排序算法会根据 200 多个信号来决定相关结果。每年，Google 对排序算法有 500 多项改进。这些信号包括：

网页内容的新鲜程度；网站内容的质量；网页的地址和标题；其它网站对某特定站点的链接，以及这些链接的权威性；最好的搜索结果是什么，网页、图片、视频、新闻、个人结果等；网页上的单词；拼写检查；个性化（与你关联的人推荐的结果）。

搜索结果

搜索结果根据相关性排序，同时，Google 还提供了网页预览功能。

每天在 Google 上产生的搜索超过亿次；网页预览的平均加载时间是 1/10 秒；从 2003 年以来，Google 已经回答了 4500 亿个新查询；每天都有 16% 的新查询出现。

6月14日，互联网名称与数字地址分配机构、非营利国际组织ICANN称，其在新通用顶级域名的全球申请名单中，共收到1930个新顶级的申请。ICANN由此大赚特赚，仅此一役，就将约3.6亿美元吸入囊中。但吸金的不止只有ICANN，还有像黄道这样的公司。

据黄道公司副总裁李祥建透露，借ICANN即将公布新通用顶级域名的机会，其公司成功融资2000万美元。“在1930个通用顶级域名中，我们共获得18个通用顶级域名，这是获得融资的核心资产。”李祥建说。

黄道公司执行董事庄振宇则将他们的生意又提升了一个层次：“ICANN公布新规，是中国互联网产业‘40年一遇的机会’。过去，互联网核心资源的分配及规则制定均由美国主导，而这一次，中国首次有机会参与其中。”

庄振宇所谓的互联网核心资源，即包括根服务器，也包括IP地址及顶级通用域名。换句话说，ICANN公布新规，也同时引发了一场重划互联网疆域的战争。

域名争夺大户

按每个域名18.5万美元计算，如果1930个申请域名全部注册成功，ICANN将收到3.5亿美元的资金。其中，谷歌花费1887万美元申请102个顶级域名，印度巨头Directi集团斥资超过600万美元申请31个顶级域名。

但李祥建补充：ICANN收到的远不止3.5亿美元，18.5万美元是在没有竞争者时的价格，如果同一通用顶级域名有两个或两个以上机构竞争，注册价格则采取竞价方式，价高者得。

比如“.weibo”的顶级通用域名。对此，中国的腾讯与新浪展开了激烈竞价，李祥建预计，这一通用域名最桥头价格为数百万美元。此外，腾讯和新浪还竞争中文通用顶级域名“.微博”。此次ICANN组织首次开放通用顶级中文域名注册，此前全为英文。

记者了解到，在1930个域名中，有751个存在竞争，超过申请总量的三分之一。其中，竞争最为激烈的域名后缀分别 是：.app、.home、.inc、.art、.blog等。而注册成功的企业或机构，除缴纳18.5万美元注册费用外，每年还要为每个域名缴纳2.5 万美元的管理费。这对ICANN来说，又是一笔不菲的收入。

中国区域此次共申请域名88个。李祥建统计，88个域名由约15家企业分得，而黄道公司独得18个通用顶级域名，算是此次顶级域名争夺中的大户。

根据ICANN公布的名单，中国机构申请的新顶级域名分为三类：一是提供公开注册服务的通用商务域名，如CNNIC申请了“.公司”和“.网络”两个中文域名；二是企业品牌域名，如中信申请的“.中信”、搜狐申请的“.sohu”；还有一类是地理名称域名。另外，也有企业申请“.我爱你”之类的时尚个性化域名提供公开注册。

域名新商业模式

“随着互联网的发展，域名数量不够是ICANN开放的动力。”Frost &Sullivan中国区总裁、资深电信市场营销和战略咨询专家王煜全告诉记者：“就如同IP地址，IPV4地址不够用，升级为IPV6。”

李祥建认为，新顶级域名扩展后，意味着以往的“.com”、“.cn”之类的域名，今后可以用“.shop”、“.sohu”“.中信”的形式出现。这必然会改变其所在行业用户的域名需求格局，创造新的商业模式。

而拥有18个域名、2000万美元融资后，黄道公司的业务也将充满想象力。“首先，可以做域名注册局的生意，就像现在的CNNIC，我们会成为域名产品提供商。”李祥建说，“其次，可以做万网这样的‘域名渠道商’的生意，面向最终用户销售域名。”

此前，李祥建曾在CNNIC工作多年。据他统计，中国域名渠道商约有30家。过去，CNNIC主要提供“.cn”域名产品，不做渠道商生意，未来黄道的角色可能是“域名产品提供商+域名渠道商”相统一。

除打域名提供商与域名渠道商的主意外，抢注顶级通用域名，还可以保护公司在某一领域的产品品牌及公司品牌。如除了腾讯、新浪为了“.weibo”、“.微博”大打出手外，奇虎360申请了“.shouji”、“.yun”和“.anquan”等四个顶级域名。在CNNIC曾与周鸿祎“打过仗”的李祥建认为，“域名显示了周鸿祎未来的业务版图”。

李祥建同时指出，此次新顶级域名面向全球开放申请，对中国公司无疑是一次与世界同行站在同一起跑线上、保护自有品牌的好机会。此前，中国没有一个全球通 用顶级域名注册机构，“.cn”仅是中国区域顶级域名，而即使是CNNIC，也没有机会参与全球顶级通用域名分配及政策制定。

《21世纪经济报道》

葡萄牙的一位开发者 Ricardo Peres 最近发布了一篇文章，以看起来无偏见的形式对领先的两种 .NET ORM：NHibernate 和实体框架进行了比较。 我们建议考虑使用这两种框架的人都应该读下他的文章，NHibernate 和实体框架之间的区别，另外还将指出一些关键的区别。

从架构上看，NHibernate 基于 Java 的 Hibernate ORM。 Ricardo 写道：

在 NHibernate 中，工作单元和配置项以及模型实例都相互独立。 你首先会创建 Configuration 对象，在其中你会指定所有 NHibernate 设置，像要使用的数据库和语言、批处理的大小、映射关系等等，然后你会依此构建 ISessionFactory。 ISessionFactory 会持有与特定数据库绑定的模型和元数据，以及来自于 Configuration 对象的设定，并且，一般每个进程中只有一个实例。 最终，你会基于 ISessionFactory 创建 ISession 的示例，它是工作单元（Unit of Work）以及标识符地图（Identity Map）的 NHibernate 表现形式。 这是一种轻量级的对象，它本质上会根据需要打开和关闭数据库连接，并跟踪与之相关的实体。 ISession 对象很容易创建和销毁，因为所有的模型复杂性都存储在 ISessionFactory 和 Configuration 对象中。

评论者 Morten Mertner 说：“我永远都不会使用 NHibernate。 尽管它拥有很棒的特性列表，但它并非一种能够轻松使用的产品，而且 API 和设计中始终带有遗传自 Java 的味道（同样，很多 Java API 都太企业化，并且架构过于庞大；结果会与你想要的大相径庭）。”

实体框架遵循的是更加传统的 .NET 设计，其中所有一切都封装在单独的 ObjectContext 或者 DbContext 中。 这让使用对象更加简单，但是缺点在于“类并没有因此是轻量级的，因为它有与 NHibernate 类似的内容，并且一般不会看到这样的例子：实例可以缓存在字段中。”

对于映射，NHibernate 和实体框架之间的关键区别在于，前者支持基于 XML 的映射文件，该文件可以独立部署。 在理论上，这让你可以针对不同的数据库 schema 使用相同的对象模型，而不需要重新编译应用程序。 但在实践中很少这么使用。

在很多方面古老一些的 NHibernate 要优于实体框架。 Ricardo 提供了更多细节，并简要地总结如下：

• 关联： 都支持一对一、一对多、多对多，但是 NHibernate 还支持各种排序、未排序和索引的选项。 它甚至还有不变的（immutable）、索引的（indexed）列表。
• 缓存： NHibernate 提供了带有大量实现的二级缓存。 实体框架没有任何对此内建的支持，但是有些增加二级缓存的例子。
• ID 生成： NHibernate 提供了大概十二种策略，这取决于你如何计算。 实体框架只为 SQL Server 提供了主要的三种： 标识符列、GUID、和手动赋值。
• 事件： 实体框架只有两种基于事件的扩展点： ObjectMaterialized 和 SavingChanges。 “NHibernate 拥有非常丰富的事件模型，暴露了超过 20 种事件，有些针对同步前执行（synchronous pre-execution），有些针对异步后执行（asynchronous post-execution）”。
• 级联： “两种框架都支持集合和关联的级联： 当实体被删除的时候，相关的子实体也会被删除。 NHibernate 还提供了一种特性，可以把子实体上的外键设置为 NULL，而不删除它们。”
• 清理变更： NHibernate 提供了一种自动模式，其中在必要的时候会保存变更，像“如果有一种实体类型的脏实例，而查询是针对这种实体类型执行”。 FlushMode.Auto 实际上是默认值，但偶尔会看到由于自动清除而导致性能问题。

也有一些领域中，实体框架会比 NHibernate 好，比方说：

• 跟踪变更： 尽管两种框架在工作单元级别默认都能够跟踪变化，而实体框架还提供了自我跟踪实体（self-tracking entities）。
• 整合： 实体框架当然会与 Visual Studio 和各种 ASP.NET 以及 WCF 类库有很好的绑定。
• 文档： “这是另一种实体框架表现非常好的地方： NHibernate 缺少针对初学者的文档，并且也没有与其最新版本同步的最新 API 参考。”
• 查询： Craig 写到：“NHibernate 有更丰富的特性，但有一个领域除外，那就是对 Linq 的支持。 因为对于很多用户来说，Linq 或者其它查询语言都是 ORM 中最可见的部分，它会让人对功能产生错误印象。”

还有某些领域，两种框架都可以做出改进，像批处理功能。 当需要真正支持 SQL 的高级特性——像通用表表达式——的时候，两种 ORM 框架都无法支持 SQL Alchemy。

我们应该发现两个项目都很活跃，经常会有定期的改进。 所以，如果二者都能够满足你的最小需求，那么考虑就更多集中在程序库的设计模式和哲学上，而不是在特性列表上。