现在的项目团队中有在使用MongoDB，MongoDB是一个文档数据库，采用类JSON的格式BSON存储文档，号称集文档数据库、KEY/VALUE存储和关系型数据库的优点与一身。 晚上看了一会MongoDB的文档，结构还是比较简单： dbs -> collections -> objects 其中collection类似于关系型数据库中的表，object类似于记录，也就是存储的文档。 在优化章节中提到的几点： 1. 创建索引/限制输出结果/选取字段，这是比较常规的优化手段。需要注意的是选取字段的结果，会使得对象不完整，这样更新后无法保存到数据库中； 2. 有profier工具，$explain, hints和传统数据库类似的地方； 3. 服务端的代码执行； 4. 对count()函数涉及的字段建索引； 5. 实现计数器方式的应用时，支持简单对象字段的增加操作，可以直接在服务端更新。避免获取、更新、再保存的来回过程； 6. 小对象的优化提到三点意见：一是显示使用_id字段，二是取短的字段名称（哈哈，这个我觉得真逗，想起当年节衣缩食地在TimesTen中掐字段大小），三是采用组合对象； 7. MongoDB的查询优化不是基于cost和统计来做的，而是简单地尝试不同执行计划，并行运行。是驴子是马拉出来遛遛，谁先完成就认为谁ok，其他的就干掉； 看了觉得挺有意思，先简单记录一下，啥时候找时间也试试。
Posts Tagged ‘计算机与 Internet’
离开AI后，以前的同事经常问我去干什么了，做的是些什么东西，和以前做的BOSS有啥不同。之前觉得有点说不清，来了两个月，理理思路吧，也算是解惑。不能说的太细，还把握不好，免得漏了公司的信息，呵呵。现在只能多来点抽象的，顺便做个广告，欢迎有兴趣的人一起加入。 一般我们说BOSS系统的时候，在移动NGBOSS的规范里画的图是这样的： 我呢，喜欢再加一个统一的产品管理，这可能和在ZMCC做了这么多年很有关系，更多地强调产品的融合管理，在实现时的时候，分系统去完成对它的使用。CRM侧重产品的营销，BOSS侧重产品的计费。 而在手机应用appstore的模式下，我理解的应用支撑系统结构（目前）是： 在业务系统上，个人理解还是处于BOSS系统建设的初始阶段。比如说：各个业务应用是垂直式的，缺乏数据的共享；缺少产品的定义和营销的管理，资费简单化；对于客户和用户定义不清晰，CRM尚处于雏形；（不可能一步到运营商的地步，想想运营商在这块的规划上已经投入了10年的人力，且电信领域有成熟的TMF规范做参考。）不过从所画的系统结构来看，作为业务支撑系统来说，两者还是很类似的。“麻雀虽小，五脏俱全”。门户、产品、计费、帐务、结算、客服、经分主要系统是一个也不少，而且从客服和经分的现状来看，相比当初的运营商是起步更高。 不过和传统的电信运营支撑系统相比，也存在很大的不同，而这正是体现了手机应用支撑系统的特性：1. 门户的特性不同：WAP门户和终端APP，分别需要WAP浏览器和终端手机的虚拟机平台的支持；（我们是做山寨机的，不象iphone专注于自己的平台就可以了）2. 应用部署平台：部署平台是业务系统的核心，类似于BOSS系统的产品管理，起到驱动的作用。不过目前这个平台还承载着类似服务开通以及面向用户的CRM部分功能，个人觉得过于杂了，而在产品管理上不够专注，功能反而弱了。3. 运维管理平台，这部分相比运营商的系统其实做的不差，可能做互联网运营的都会迫切关注，涉及大量的内容部署和审核等等；4. 基础平台的不同，更关注引入对SNS基础服务的支持，来提高用户的粘度。运营商的传统营销还仅仅是针对家庭和集团等在现实中有归属关系的群体，而缺乏对有共同兴趣爱好的关系的挖掘； 在系统设计和实现上不同的是，运营商是家大业大，设备和网络都不可同日而语啊。用的都是小型机，千兆光纤，所以系统往往还是集中化的方式，再考虑故障切换和异地容灾。而现在就不同了，能有的设备就是一堆PC SERVER，跨IDC的网络性能也比不上，从初始设计出发就需要考虑分布式，关注性能。在软件架构上采用的也都是开源的系统，没有一堆大厂家在背后支持你，需要自己来搞定。 先写这么多吧，后面也许可以再说说具体的一些系统的情况。 BTW.手机应用的开发也大不相同，这块不太清楚，不过想想移动网络的性能和终端CPU/内存，就觉得要考虑的问题的确是好多。
什么是不是问题的问题？ 我的定义就是：不解决也死不了，有点别扭。解决了或许会提高效率，更重要的是心情爽了。 今天解决了两个不是问题的问题，所以心情有点小爽： 1. chrome中点击RSS扩展图标，使用google reader订阅。不过由于大家知道的原因经常http访问不了，我这时一般在url前面改成用https就ok了。 一直偷懒这么将就着，其实很简单，右键点击RSS扩展图标，选项，修改google reader的网址为https即可。可怜我之前每次都是在页面无法访问时再输入一次。 2. 在chrome中下载都是默认下载，不采用下载工具。还好现在网速够快，一般情况下也够用了，如果真的是大文件，这时候往往我就打开快车（我用的一直是最干净的1.96版），再把url复制进去。 Google了一下，找到了一个扩展DM Bridge (oGet for Chrome, 仅用于 windows)，设置一下选项，采用shift+右键，就可以直接选择flashget下载了。
机器需要还掉了，整理原先的内容，想把chrome的插件给备份一下。原以为简单的很，找个软件，看到都推荐google chrome backup。 那就下载一个exe文件，方便。可是我试了一下都运行没有效果。 先是提示就让人糊里糊涂，一方面告诉我好像没装chrome，一方面又跳出来告诉我有新版本。 而事实上是我装了，而且也是最新版本的6.0.408.1。 不管它，虽然算我没装，我也继续吧。 选择wizard，制定备份的目录，每次都提示文件已存在，包括第一次。事实上是根本备份的文件都没有生成。 继续不管它，强制覆盖。 最后出来的结果是让我点Finish了，可是进度条根本没有动静，而且备份文件也没有生成。 我彻底晕倒了！有备份成功的吗？俺这到底是咋的了？ 只有先用粗陋的方法直接备份我的user data了。又惊异的发现居然有1.4个G，呵呵。 查了一下，原来是google gears在作怪。 最后就手工清除了浏览数据和Google gears的离线备份，再把user data的default打个包，差不多也4M的样子吧。先这么着吧，看来下次还是搞个portable版的算了。
给自己找条翻墙的道:chrome+Switchy+cjb+myentunnel
Posted: February 2, 2010 in UncategorizedTags: 计算机与 Internet
最佳翻墙方法自然是使用ssh，不过一直没有ssh帐号就都没有使用，之前曾尝试过ultravpn，不过也不顺。 今天尝试了一个方法，感觉不错，分享一下：chrome+Switchy+cjb+myentunnel。 1. 这里的关键还是cjb了，国外的同志真是太好了，什么都有免费的，只需要提供邮件注册一个帐号，就可以使用免费的ssh了。 2. 有了ssh，就去下载一个myentunnel，自己搜索一下吧，简单地使用刚在cjb上申请的帐号和密码做个设置即可，连接，看到图标变绿色就ok了。 3. 用自己喜欢的浏览器firefox或chrome，搭上一个代理切换的扩展，我用的就是chrome+switchy，安装后在扩展设置中sock代理（端口采用在myentunnel中的参数）。 4. switchy提供了auto switch mode和Rule的手段，这下就可以方便地切换。 一切搞定，输入http://twitter.com/xbin999试试看，能访问就搞定了。 参考文章：chrome 扩展： Proxy Switchy!之图解使用方法。
