云计算 归档

  • 树大招风，dropbox刚冉冉升起，在国内就被和谐了。不过他的启动和运作模式，还是值得借鉴的。 在论坛里发现了一个DropBox创始人总结成功经验的ppt中文版，读来很受启发： 现有用户是最好的推销员 推荐+互惠，更容易让人接受 利用facebook和twitter推广 作出有用的好产品 不断升级，可以得到持续的关注和免费曝光 不要害怕红海，只要你的产品足够好 公关、结盟、代理商只是锦上添花 免费试用可以创造需求 制作iphone版，增加一个营销渠道和卖点 使用下面这个链接注册，你和我都增加250M的免费使用空间 http://db.tt/WseIVf

    病毒式营销的新境界，DropBox

    在 2010/05/12 上发表 | 评论暂缺
    树大招风，dropbox刚冉冉升起，在国内就被和谐了。不过他的启动和运作模式，还是值得借鉴的。 在论坛里发现了一个DropBox创始人总结成功经验的ppt中文版，读来很受启发： 现有用户是最好的推销员 推荐+互惠，更容易让人接受 利用facebook和twitter推广 作出有用的好产品 不断升级，可以得到持续的关注和免费曝光 不要害怕红海，只要你的产品足够好 公关、结盟、代理商只是锦上添花 免费试用可以创造需求 制作iphone版，增加一个营销渠道和卖点 使用下面这个链接注册，你和我都增加250M的免费使用空间 http://db.tt/WseIVf

    继续阅读...

  • Google App Engine的数据库属于对象数据库，设计的思路比较独特，主要适用于“多查询，少更新”的web应用。今天去参加Sun的开发者日，正好有个MySQL的讲座，其中提到MySQL的pluggable storage engine当中，针对web应用优化的MyISAM，也是延续这个思路。不过MySQL毕竟是关系数据库，对于复杂的表查询操作，专家和新手写出来的语句，效率那可是千差万别。而GAE则不同，可以保证任何人只要能完成功能，效率都不会太差。当然，这是以牺牲部分功能作为代价的。但是想一下，还是更喜欢GAE的方式，毕竟设计数据结构和关系的时候就把问题解决，总比上线以后才发现数据库操作效率低下要好。 使用GAE的Python版和Java版做的程序也有好几个了，正好把它与传统的关系数据库比较一下。 查询比更新快十倍。 查询结果数量有限制。GAE进行查询时最多返回1000条数据，即使使用count来查看记录数量，最多也只返回1000。但是，在获取数据时可以指定offset，这样可以简单分页。 想统计，就要维护计数器。由于最多返回1000，无法得知到底有多少数据，如果程序中需要总数、平均值、总和、按月总数等等统计数据，就要自己维护一个计数器对象。具体做法，参考Google官方的文章计数器。 先索引，后查询。出现在查询条件中的字段，必须设置索引。 不用严格遵循数据库设计范式。在关系数据库中，类别名称、tag名称等一般要独立成表，然后使用时放置索引。但在GAE中，对象可以直接保存这些短小的数据，这样在查询时就规避了GAE无法进行表关联的缺点，而且由于有索引，这样速度其实也非常快。 查询条件，只能有一个不等。允许有多项查询条件，但是其中只能有一项是非相等条件（例如：大于，小于）。 ID或Key的使用，用于定位获取对象，速度最快。对于帐户对象，可以使用唯一的email作为key，这样更新时就不需要再查询一次了，直接在Transaction中完成更新即可。 在一个Transaction中，不能出现不同组的对象。 尽量减小单个组内的对象数量。由于Google App Engine属于云计算，所有的对象数据都分布在无数节点之上，这样数据查询可以并行完成，速度大大提高。如果把大量对象放置在一个组内，所有这些对象只能存在一个节点之上，查询时就没有并行查询的优势了。 数据关系的强制一致性。如果删除一个对象，所有依赖于该对象的对象都将被删除。 tag的实现，可以结合对象的list属性，直接保存所有的tag字符串。这样便于查询、增减。但不利于统计例如：具有某tag一共有多少对象。 暂时想到这么多，有空再补充。

    GAE对象数据库设计特点

    在 2009/07/29 上发表 | 1 条评论
    Google App Engine的数据库属于对象数据库，设计的思路比较独特，主要适用于“多查询，少更新”的web应用。今天去参加Sun的开发者日，正好有个MySQL的讲座，其中提到MySQL的pluggable storage engine当中，针对web应用优化的MyISAM，也是延续这个思路。不过MySQL毕竟是关系数据库，对于复杂的表查询操作，专家和新手写出来的语句，效率那可是千差万别。而GAE则不同，可以保证任何人只要能完成功能，效率都不会太差。当然，这是以牺牲部分功能作为代价的。但是想一下，还是更喜欢GAE的方式，毕竟设计数据结构和关系的时候就把问题解决，总比上线以后才发现数据库操作效率低下要好。 使用GAE的Python版和Java版做的程序也有好几个了，正好把它与传统的关系数据库比较一下。 查询比更新快十倍。 查询结果数量有限制。GAE进行查询时最多返回1000条数据，即使使用count来查看记录数量，最多也只返回1000。但是，在获取数据时可以指定offset，这样可以简单分页。 想统计，就要维护计数器。由于最多返回1000，无法得知到底有多少数据，如果程序中需要总数、平均值、总和、按月总数等等统计数据，就要自己维护一个计数器对象。具体做法，参考Google官方的文章计数器。 先索引，后查询。出现在查询条件中的字段，必须设置索引。 不用严格遵循数据库设计范式。在关系数据库中，类别名称、tag名称等一般要独立成表，然后使用时放置索引。但在GAE中，对象可以直接保存这些短小的数据，这样在查询时就规避了GAE无法进行表关联的缺点，而且由于有索引，这样速度其实也非常快。 查询条件，只能有一个不等。允许有多项查询条件，但是其中只能有一项是非相等条件（例如：大于，小于）。 ID或Key的使用，用于定位获取对象，速度最快。对于帐户对象，可以使用唯一的email作为key，这样更新时就不需要再查询一次了，直接在Transaction中完成更新即可。 在一个Transaction中，不能出现不同组的对象。 尽量减小单个组内的对象数量。由于Google App Engine属于云计算，所有的对象数据都分布在无数节点之上，这样数据查询可以并行完成，速度大大提高。如果把大量对象放置在一个组内，所有这些对象只能存在一个节点之上，查询时就没有并行查询的优势了。 数据关系的强制一致性。如果删除一个对象，所有依赖于该对象的对象都将被删除。 tag的实现，可以结合对象的list属性，直接保存所有的tag字符串。这样便于查询、增减。但不利于统计例如：具有某tag一共有多少对象。 暂时想到这么多，有空再补充。

    继续阅读...

  • 上网第一周，《Google API大全》已经名列中国互动出版网计算机类的近7日销售排行榜第17位。  Shameless self-promotion 中国互动出版网（China-pub）成立于2000年，是中国最早的一批网络书店，最早主营计算机图书，我买计算机方面图书的首选网络书店。现已扩展到通信、经济管理、数理化、各类专业技术、教育等领域。

    《Google API大全》，近7日销售排名第17

    在 2009/06/13 上发表 | 评论暂缺
    上网第一周，《Google API大全》已经名列中国互动出版网计算机类的近7日销售排行榜第17位。  Shameless self-promotion 中国互动出版网（China-pub）成立于2000年，是中国最早的一批网络书店，最早主营计算机图书，我买计算机方面图书的首选网络书店。现已扩展到通信、经济管理、数理化、各类专业技术、教育等领域。

    继续阅读...

  • 算起来，用Google API来开发web系统已经有1年多了。一年前，参加Google开发者大会时的情景还历历在目。各大公司的会议将和讲座参加了很多，但是很少有像参加完Google大会之后这么激动。或许是被Google的创新精神所折服，或许是被Google API的强大威力所感召，不久之后，结合了Google App Engine，Google Ajax Search和Google Gadget的RankRadar Tracking 便诞生了。半年多来，RankRadar系统在Google云计算平台上，顺畅地奔跑着，每天都为用户抓取、保存、展示着数据，轻松应对大数据量的访问。Google平台的强悍可见一斑。 使用了Google API这么久，现在终于有机会把自己的经验分享出来，真是一件很荣幸的事情。我与数位Google公司的一线工程师，还有几位活跃在技术社区的开发者一起合著了《Google API大全：编程·开发·实例》这本书。6月5日，Google 2009 年开发者日大会上，将会正式发布。 我写作的章节如下： 第11章 小工具开发——Google Gadgets API 第26章 网络广告整合——Google AdSense API 第35章 让应用支持桌面搜索——Google Desktop Search APIs 本书书如其名，确实很全，囊括了绝大多数的Google API，既提供了对Google...

    《Google API大全：编程·开发·实例》6月5日面市

    在 2009/06/02 上发表 | 4 条评论
    算起来，用Google API来开发web系统已经有1年多了。一年前，参加Google开发者大会时的情景还历历在目。各大公司的会议将和讲座参加了很多，但是很少有像参加完Google大会之后这么激动。或许是被Google的创新精神所折服，或许是被Google API的强大威力所感召，不久之后，结合了Google App Engine，Google Ajax Search和Google Gadget的RankRadar Tracking 便诞生了。半年多来，RankRadar系统在Google云计算平台上，顺畅地奔跑着，每天都为用户抓取、保存、展示着数据，轻松应对大数据量的访问。Google平台的强悍可见一斑。 使用了Google API这么久，现在终于有机会把自己的经验分享出来，真是一件很荣幸的事情。我与数位Google公司的一线工程师，还有几位活跃在技术社区的开发者一起合著了《Google API大全：编程·开发·实例》这本书。6月5日，Google 2009 年开发者日大会上，将会正式发布。 我写作的章节如下： 第11章 小工具开发——Google Gadgets API 第26章 网络广告整合——Google AdSense API 第35章 让应用支持桌面搜索——Google Desktop Search APIs 本书书如其名，确实很全，囊括了绝大多数的Google API，既提供了对Google...

    继续阅读...

  • 最近IT界最热门的话题就是Oracle收购了SUN。而SUN在一年前收购了MySql。这样Oracle就进一步巩固了在数据库方面的老大地位。现在唯一能够撼动Oracle老大地位的，恐怕只有Google了。Google近年来连续推出了桌面搜索、Apps、App Engine、Google Base等基础架构，目标直指数据库领域。 企业级的数据库Oracle，IBM Db2，Sybase，MS SQL server，MySQL（a Oracle DB？！）。Oracle是名副其实的数据库老大，MySql主要用于网站，只是去年被Sun收购，才正式吹响了进军企业级领域的号角。回想去年，Sun刚刚收购MySql，立即进行全球巡展，意气风发。我正好来新加坡，还参加了它的MySQL产品推介会，记得Sun的亚太区总监，轻快的跃上讲台的时候，那派头，活脱一位好莱坞明星参加Fans见面会。当年Sun在网络大潮中崛起，泡沫破裂后，成功的存活并稳步发展到今天，其开创的Java已经成为最多使用者的编程语言，没想到竟然走到的今天的地步，落得被Oracle收购的结局，真是让人慨叹世事无常啊。 扯远了！书归正传。Google也有数据库产品？当然，而且Google就靠其强大的数据库索引和查询系统，才奠定了世界第一搜索引擎的江湖地位。多年以来Google一直是敝帚自珍，终于等到现在，时机成熟了。Google把它包装成云计算，同时推出的还有Google App Engine，让开发人员来免费使用云，开发出强大的应用程序。在最近的更新中，Google App Engine已经可以使用Java这一广泛活跃在商业应用领域的编程语言来进行访问了。 Google现在还留了一手，全文搜索功能还没有在Google App Engine中提供。暂时只有Google Desktop允许开发人员使用Google搜索技术来服务于自己程序的全文搜索的需要。这正是Google的风格，不鸣则已一鸣惊人。但是，预计在不久的将来，Google一定会有条件的以某种方式来让开发人员使用这一功能的。 为什么全文搜索是决胜之役？我的理解是，好用才是真正的取胜之道。企业级应用就是把流程、内容固化在IT系统中，在需要的时候，通过索引精确定位出来和全文搜索出来。固化的过程就是对数据库更新的操作过程，但是Oracle等系统毕竟使用多年，这方面已经很成熟了，而Google的搜索蜘蛛并发访问和存储，这方面的功力估计也不差；精确定位查找就更简单了，即使是桌面级数据库也都没问题；而全文搜索方面，这可是Google的看家本领，看看其他搜索引擎的市场份额，就知道Google的全文搜索可不是浪得虚名的。其他方面都差不多，但是用户在Google系统上可以以最快的速度找到要找的东西，而在其他系统上就不行，你说用户会选择谁？ 现在的问题是，Google评定网页的排名是建立在网页彼此投票的基础上。在企业级数据库的搜索中，数据彼此之间并无彼此投票，那么如何评定关键字排名呢？嘿嘿，看看Google桌面搜索，就能发现，Google已经在试验和探索了！而且效果相当好，支持各种常用的文件类型。 再看看Google Apps俨然就是一个Outlook+Exchange+SharePoint的Google网络版。对中小型企业的诱惑力简直就是杀手级的。入门版甚至是完全免费的，把公司内的邮件和文档整合在一起，没有限制的流量，G级的存储，闪电般的全文检索，微软看来真的要奋起直追了。 Google还有一个杀手级的产品——Google Base Data API。把数据以某种格式放置在Google Base中，然后随时访问。 云计算的好处，不用为了峰值访问而白白付出买服务器的钱。很多时候，一条新闻就能让你的系统拥有100倍于平时的访问量。为了应付这100倍的有价值的高效访问，难道要购买数十倍多余的平时根本用不上的服务器吗？Google云就可以很好的解决这个问题。你只需要按照实际使用的来付钱，同时具有几乎无限的扩展能力。 云计算也有些缺点，很多数据极端敏感的银行或商业企业，他们往往有自己的庞大的数据中心，并不愿意把自己的数据放在其他公司那里的。Google想吞下这部分大肥肉，恐怕就要动动脑筋了，这不是技术问题，而是商业问题，是不是考虑成立一个数据中心公司，然后把云计算授权给它。 Google的数据库现在需要做的就是多攒点人气，多做点关键应用，培育一些行业典型客户。与Oracle等巨头正面交锋的日子不远了。

    Google与企业级数据库市场的格局

    在 2009/05/30 上发表 | 评论暂缺
    最近IT界最热门的话题就是Oracle收购了SUN。而SUN在一年前收购了MySql。这样Oracle就进一步巩固了在数据库方面的老大地位。现在唯一能够撼动Oracle老大地位的，恐怕只有Google了。Google近年来连续推出了桌面搜索、Apps、App Engine、Google Base等基础架构，目标直指数据库领域。 企业级的数据库Oracle，IBM Db2，Sybase，MS SQL server，MySQL（a Oracle DB？！）。Oracle是名副其实的数据库老大，MySql主要用于网站，只是去年被Sun收购，才正式吹响了进军企业级领域的号角。回想去年，Sun刚刚收购MySql，立即进行全球巡展，意气风发。我正好来新加坡，还参加了它的MySQL产品推介会，记得Sun的亚太区总监，轻快的跃上讲台的时候，那派头，活脱一位好莱坞明星参加Fans见面会。当年Sun在网络大潮中崛起，泡沫破裂后，成功的存活并稳步发展到今天，其开创的Java已经成为最多使用者的编程语言，没想到竟然走到的今天的地步，落得被Oracle收购的结局，真是让人慨叹世事无常啊。 扯远了！书归正传。Google也有数据库产品？当然，而且Google就靠其强大的数据库索引和查询系统，才奠定了世界第一搜索引擎的江湖地位。多年以来Google一直是敝帚自珍，终于等到现在，时机成熟了。Google把它包装成云计算，同时推出的还有Google App Engine，让开发人员来免费使用云，开发出强大的应用程序。在最近的更新中，Google App Engine已经可以使用Java这一广泛活跃在商业应用领域的编程语言来进行访问了。 Google现在还留了一手，全文搜索功能还没有在Google App Engine中提供。暂时只有Google Desktop允许开发人员使用Google搜索技术来服务于自己程序的全文搜索的需要。这正是Google的风格，不鸣则已一鸣惊人。但是，预计在不久的将来，Google一定会有条件的以某种方式来让开发人员使用这一功能的。 为什么全文搜索是决胜之役？我的理解是，好用才是真正的取胜之道。企业级应用就是把流程、内容固化在IT系统中，在需要的时候，通过索引精确定位出来和全文搜索出来。固化的过程就是对数据库更新的操作过程，但是Oracle等系统毕竟使用多年，这方面已经很成熟了，而Google的搜索蜘蛛并发访问和存储，这方面的功力估计也不差；精确定位查找就更简单了，即使是桌面级数据库也都没问题；而全文搜索方面，这可是Google的看家本领，看看其他搜索引擎的市场份额，就知道Google的全文搜索可不是浪得虚名的。其他方面都差不多，但是用户在Google系统上可以以最快的速度找到要找的东西，而在其他系统上就不行，你说用户会选择谁？ 现在的问题是，Google评定网页的排名是建立在网页彼此投票的基础上。在企业级数据库的搜索中，数据彼此之间并无彼此投票，那么如何评定关键字排名呢？嘿嘿，看看Google桌面搜索，就能发现，Google已经在试验和探索了！而且效果相当好，支持各种常用的文件类型。 再看看Google Apps俨然就是一个Outlook+Exchange+SharePoint的Google网络版。对中小型企业的诱惑力简直就是杀手级的。入门版甚至是完全免费的，把公司内的邮件和文档整合在一起，没有限制的流量，G级的存储，闪电般的全文检索，微软看来真的要奋起直追了。 Google还有一个杀手级的产品——Google Base Data API。把数据以某种格式放置在Google Base中，然后随时访问。 云计算的好处，不用为了峰值访问而白白付出买服务器的钱。很多时候，一条新闻就能让你的系统拥有100倍于平时的访问量。为了应付这100倍的有价值的高效访问，难道要购买数十倍多余的平时根本用不上的服务器吗？Google云就可以很好的解决这个问题。你只需要按照实际使用的来付钱，同时具有几乎无限的扩展能力。 云计算也有些缺点，很多数据极端敏感的银行或商业企业，他们往往有自己的庞大的数据中心，并不愿意把自己的数据放在其他公司那里的。Google想吞下这部分大肥肉，恐怕就要动动脑筋了，这不是技术问题，而是商业问题，是不是考虑成立一个数据中心公司，然后把云计算授权给它。 Google的数据库现在需要做的就是多攒点人气，多做点关键应用，培育一些行业典型客户。与Oracle等巨头正面交锋的日子不远了。

    继续阅读...