Google DataWiki如何区别于FluidDB

谷歌公司最近在其Google Lab上启动了数据维基(DataWiki)的项目。据谷歌官方称DataWiki将会是”一种数据结构化的维基”。根据其页面介绍,该项目理念来自于2010年海地地震期间发展起来的人物搜索(Person Finder)应用。谷歌开发者看到了创建结构化数据共享系统的急切需求。

该项目乍听起来与FluidDB十分相似,FluidDB常被形容为”一种被托管的维基核心数据库”,FluidDB的Nicholas H.Tollervey很愿意为大家解释这2个项目有何种不同。

DataWiki是用来快速构建简单且特定用途的数据库-例如Person Finder。而FluidDB则试图构建大型数据库所需要的一切。

就Tollervey提出的,这2个项目间的存在主要差别有:

  • 结构:DataWiki的每一页都将遵循某种预定义的结构。而FluidDB则不会将某种模式强加给用户,并且事物总是以对象的形式表达出来而非列表”。
  • 审核:DataWiki似乎不准备提供任何访问控制机制。FluidDB有一个权限系统以控制那些用户有权去使用特定的标签或命名空间。
  • 搜索:我们只能搜索特定的DataWiki页面。而在FluidDB中,我们可以在权限允许的情况下跨越数据集地搜索数据。

想了解更多关于FluidDB的消息可以阅读<FluidDB in a Nutshell>:

[Repaste]The Underlying Technology of Facebook Messages

Facebook engineers have a new post on note portal as below:

We’re launching a new version of Messages today that combines chat, SMS, email, and Messages into a real-time conversation. The product team spent the last year building out a robust, scalable infrastructure. As we launch the product, we wanted to share some details about the technology.

The current Messages infrastructure handles over 350 million users sending over 15 billion person-to-person messages per month. Our chat service supports over 300 million users who send over 120 billion messages per month. By monitoring usage, two general data patterns emerged:

  1. A short set of temporal data that tends to be volatile
  2. An ever-growing set of data that rarely gets accessed

When we started investigating a replacement for the existing Messages infrastructure, we wanted to take an objective approach to storage for these two usage patterns. In 2008 we open-sourced Cassandra, an eventual-consistency key-value store that was already in production serving traffic for Inbox Search. Our Operations and Databases teams have extensive knowledge in managing and running MySQL, so switching off of either technology was a serious concern. We either had to move away from our investment in Cassandra or train our Operations teams to support a new, large system.

We spent a few weeks setting up a test framework to evaluate clusters of MySQL, Apache Cassandra, Apache HBase, and a couple of other systems. We ultimately chose HBase. MySQL proved to not handle the long tail of data well; as indexes and data sets grew large, performance suffered. We found Cassandra’s eventual consistency model to be a difficult pattern to reconcile for our new Messages infrastructure.

HBase comes with very good scalability and performance for this workload and a simpler consistency model than Cassandra. While we’ve done a lot of work on HBase itself over the past year, when we started we also found it to be the most feature rich in terms of our requirements (auto load balancing and failover, compression support, multiple shards per server, etc.). HDFS, the underlying filesystem used by HBase, provides several nice features such as replication, end-to-end checksums, and automatic rebalancing. Additionally, our technical teams already had a lot of development and operational expertise in HDFS from data processing with Hadoop. Since we started working on HBase, we’ve been focused on committing our changes back to HBase itself and working closely with the community. The open source release of HBase is what we’re running today.

Since Messages accepts data from many sources such as email and SMS, we decided to write an application server from scratch instead of using our generic Web infrastructure to handle all decision making for a user’s messages. It interfaces with a large number of other services: we store attachments in Haystack, wrote a user discovery service on top of Apache ZooKeeper, and talk to other infrastructure services for email account verification, friend relationships, privacy decisions, and delivery decisions (for example, should a message be sent over chat or SMS). We spent a lot of time making sure each of these services are reliable, robust, and performant enough to handle a real-time messaging system.

The new Messages will launch over 20 new infrastructure services to ensure you have a great product experience. We hope you enjoy using it.

Kannan is a software engineer at Facebook.

Facebook选择了使用Hbase来替代MYSQL或者Cassandra驱动他们目前的Messages应用;除去后来加上的一大堆应用,不知道扎克伯格当年自己写的代码还有多少在被使用:).

优化Google Analytics Java Script载入

Google Analytics可说是目前最好的浏览分析工具,我们在使用Google Analytics的时候都需要在页面上加载”google-analytics.com/ga.js”的这段java script代码,就目前来说ga.js的载入还是比较快的,而且在第一次载入后就会被缓存下来了;但实际访问页面时偶尔还是会发现瓶颈出现在访问google-analytics.com上。那么有什么好办法进一步加速ga.js的载入吗?
最近Google code推出的pagespeed里就推荐了一种方法:即使用异步载入的ga.js脚本;换而言之就是让页面先完全载入,之后在后台继续完成该java script代码的工作。使用这种最新的异步调用方式后,页面的载入速度几乎和不使用Google Analytics一样快了,实现的方法也十分简单,直接替换页面上调用ga.js的语句就可以了:

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXX']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>

记得要将UA-XXXXXX替换成你自己的Google Analytics ID,如果你是使用wordpress ultimate Google Analytics插件的话,只需要将该插件删除或停用,然后将上述代码插入到footer.php的</html>标记前就行了。

享受asynchronous异步脚本带来的高性能吧!

利用pagespeed插件优化网站css层叠样式文件

“不务正业”的google最近发布了pagespeed插件和apache 2专有的mod_pagespeed页面优化模块;pagespeed插件目前仅有firefox版的,该插件要求预安装有Firebug页面debugger插件,你可以通过Tools->Add-ons->Get Add-ons菜单添加Firebug插件,之后登陆pagespeed在code.google.com的官方页面安装pagespeed插件。

pagespeed插件的使用十分简单,只要在打开你希望优化的页面后,点选Firefox工具栏上的Tools->FireBug->Open Firebug in New Window选项;如我在我的www.askmaclean.com页面上打开Open Firebug in New Window就会出现以窗口:
[Read more…]

关于本博客的feed订阅

有网友反映说订阅的feed显示有问题,实际我使用firefox或opera等浏览器测试是可以正常显示的:
[Read more…]

如何使用MOS风格的代码背景?

很多使用wordpress的技术博客主都喜欢用一些HighLight Syntax的高亮语法插件,让文章中的代码段显得比较醒目和清晰;大约1个月前我也是HightLight Syntax插件众多拥垒中的一员。但今天我要说高亮插件的成本还是太高了,以我的blog为例(之前的www.askmaclean.com),highlight syntax插件包含的多个语法JavaScript脚本导致单个页面的载入需要交互多出大约60-70k的数据,这一因素直接影响了网站打开的速度(往往一个只有几十字的页面打开也需要3秒左右)。实际上绝大多数技术博客主仅会用到这些高亮语法插件中的部分语法JavaScript脚本,好比我一般只用Java,SQL这2中语言代码,而一旦启用了插件,它就会一股脑地把C#,C++,Perl,Shell一大家子的语法脚本在页面上调用;你当然会说这些脚本会在首次加载后被浏览器缓存,但如果所有的用户都仅仅浏览一页呢?

为了优化页面,我考虑到了使用和MOS(也就是Metalink)一致的代码显示风格,如果你经常和我一样去那里看文档的话,想必十分熟悉这种代码显示风格了:

MOS style code sample

为了实现这种代码显示风格,我们需要手动修改您当前使用的主题(theme)的style.css层叠文件,因为代码高亮插件引用的方式一般为”<pre class=brush:codetype>CONTENT</pre>”,所以我们只需要修改pre的属性,即可以完美修改现有文章的代码显示风格,而无需再去文章中修改。

一般我们直接到wp-content/themes/%themename%目录下即可找到主题相关的style.css文件,其默认的pre标记属性为:

pre {
        font-family:'Courier New', Courier, Monospace, Fixed;
	line-height: normal;
        overflow: auto;
	padding-bottom: 25px;
	margin: 0px;

	background-image:url('images/bg_pre_dots.png');
	background-repeat: repeat-x;
	background-position: bottom left;
}

我们需要将pre标记的默认属性修改为:

pre {
        font-family:"Courier New",Courier,monospace;
        background-color:#EEF3F7;
        overflow:auto;
        border-width:1px;
        border-style:solid;
        border-color:#C4D1E6;
        padding:0.5em;
        margin:0px;margin-top:5px;        

}

如果你在wordpress中使用了Super-cache插件则需要在后台删除cache页面,一般来说再次刷新页面就可以看到和我这里一样的代码显示风格了。

IXwebhosting suck me!!

很久之前就想写这样一篇文章了,购买IXwebhosting的虚拟空间服务是从09年的8月份开始(很长的一个熟悉过程)。

但是今天我要说IXwebhosting糟透了,糟到连基本的可用性都无法达到。从这个月初(10年的9月份)到23号,我的站点已经大大小小经历了七八次的短期无法访问,这绝不是因为网络抽风所致,我一直有用pingdom的网站监测服务,在我正式启用这一服务监测我的网站后,我几乎每天要收到1-2封关于site down的警告,有些会是在凌晨时分。我想继Sep 9的那次cp9服务器大规模outage后,有很多正在使用IXwebhosting的owner都彻底对IX失望了。
[Read more…]

关于PageRank的一些见解

根据googlepagerankupdate.com的调查,最新的一次PR值更新发生在2010年的4月2日,更早一次则发生在去年圣诞期间也就是2009年的12月31日。相信不少站长都在期盼着PR值更新,Google PageRank预示着一个页面的重要性和相关性,我们需要大量高质量的链接来喂饱它。

很多人大概会很反感看到这一连串PR的计算公式:PR = 0.15 + 0.85 ( PR(Backlink 1)/TotalLinks(Backlink 1) + PR(Backlink 2)/TotalLinks(Backlink 2) + … + PR(Backlink X)/TotalLinks(Backlink X) )。在我眼中PR计算公式并不能说明什么,重点在于你的页面上有什么,其内容是否是独一无二的,是否能给大众带来帮助;实际上越是那些实际内容空洞接近NULL的站点越热衷于提高自身的PR。

在最近SEO业界有着关于PageRank将变得不再可见(invisible)的流言,这源于部分网站坚信PageRank是它们的命根子,是它们生命价值的唯一体现,这一迷信。就我看来这棒极了,很多人大概不再会为了一个数字在别人的网站或博客上制造垃圾评论了。不少SEO方面的公司和专家以PageRank值作为它们成功的标志,显然PR不因该被拿来做炫耀的奢侈品,我们因我们的creation而自豪,绝非因为一个数字。

你大概见到过不少PageRank很低而SERP(search engine results page,如果你不知道这个术语那么不要在乎它,我们要避免陷入一个怪圈)很不错的站点,由此可以证明PageRank并不意味着较高的排名。

SEO没有错,这是一份正当的工作,但SEO真正应该完成的是让我们的页面受到与其内容相符的搜索引擎重视程度,而缔造非某些数字。

试用IE9 Preview

IE 9 Preview版现在可以从http://ie.microsoft.com/testdrive/下载到了:
[Read more…]

Gmail priority inbox帮助你减少工作量

全世界平均每天发送2940亿封电子邮件,而脑力劳动者每周花在邮件上的时间大约为13个小时。在过去的几个月里,出现过不少用以帮助用户有效使用Gmail的工具。今天,Google推出了自家的priority inbox。如果priority inbox的选项被激活,它会将您的收件箱分成三个部分:重要的邮件,打星号的邮件,其他所有邮件。该系统会自动识别邮件的重要性,并将那些紧急邮件在收件箱中置顶。

Gmail将允许用户进一步客制化Priority Inbox。你可以选择显示那些你关心的版块(好比说那些重要的,未读的,以星星标记的邮件)。当然你也可以很简单地关闭Priority Inbox功能。这一切客制化工作都可以简单地从Gmail的设置菜单中完成。

Google计划将这一令人振奋的特性向每位Gmail用户推广。

沪ICP备14014813号

沪公网安备 31010802001379号