| Twitter | Del.icio.us | Comments (10) | | Edit

Comments Powered by Disqus

留言评论 | Comments (10)

评论不成功?
微博类应用确实缺一个完美的整合和通知

这篇精彩,建议办成年度栏目。

一直以来,学习新技术,慎用新技术...

对于开放而言,目前各大互联网公司都在搞开放,从微博开始向各个领域推进,包括腾讯、新浪、搜狐、网易等大公司也在积极准备着,2011年,会是中国互联网的开放年,在上半年会爆发出来。

期待2011!期待NoSQL的蓬勃发展!

开源软件如火如荼!中国软件的兴旺一定从开源始。

作为一个中小企业(webgame)的IT从业者,相对而言我更关心的是各个大厂商的开放程度,比如腾讯、新浪、网易的开放平台,可以使我们产品整合这些大厂商的应用。当然也免不了去了解团购、微博、SNS、LBS的发展情况。作为技术人员,相对而言我更关心mysql、html5的发展。关于HTML5,借此地呼吁一下国内用户抛弃IE6

喜欢这句话 "望着天上的星,也要看着脚下的坑",同时也勉励下自己~

>> 我有一个猜测是 Redis 从 VM 转向 Diskstore 模式后,有可能超越 MongoDB 么?

其实Redis根本就不能和MongoDB相提并论。因为MongoDB跟多像一个数据库,并且来替代MySQL,而Redis跟多是一个跟高级的Memcache。

从架构角度来说,用Redis在中大型项目中替代MySQL根本没有任何意义,因为Redis虽然支持不同的数据类型 (hash, string, set, sorted set和list),但是始终是一个Data Store,在 memory 和磁盘上做缓存 (补充一下,Redis支持把内存数据写入磁盘)。很多你可以用MySQL做出的select操作在Redis中要通过预先处理数据结构的方式来解决(暖缓存),而不能,或很难像mysql那样just-in-time来进行。 据个例子,mysql中要搜索出某些符合不同条件的语句是:

select data from table where column1="ABC" and column2="EFG" and column3="HIJ"

在Redis中,第一种方法是用list作为数据结构存储table中每条数据, 然后for到内存里,并且用一门其他语言来做匹配,但是因为Redis因为只是个Key Value Store,不像MySQL支持Index,所以复杂度要比MySQL同样的操作要高, 以上操作通过Redis为 O(n), n 为 |table|, 就是list的数量。第二种方法可以通过set来存储,并且利用 sinter (交际),来做搜索。复杂度威 O(n*m),但是n是你最小set的基数,m是你的set的数量(这里为3)。


同样的,用MongoDB当做MySQL,并且不用Memcache或Redis也是从架构设计角度的误差,因为从经济效益和架构性能角度而言,MongoDB和MySQL一样在Replication的时候只支持一台Master做写操作:

MongoDB supports asynchronous replication of data between servers for failover and redundancy. Only one server (in the set/shard) is active for writes (the primary, or master) at a given time. With a single active master at any point in time, strong consistency semantics are available.
http://www.mongodb.org/display/DOCS/Replication

用来扩展写还是需要通过数据分割(分库,分表)来完成。但是如果需求要达到高可用的话,Sharding 会需要很多服务器,提高很多架构成本。而如果架构上添加一个In-disk或In-memory cache的话可以达到同样的新能,同样的高可用性,并且节省很多服务器。

所以说,像MongoDB这样的数据库系统永远都不会替代像Redis这样的缓存系统,相同Redis也不会取代MongoDB,因为两者根本不能在同一个级别上做比较。