注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风轻扬

活着就是为了追求幸福

 
 
 

日志

 
 
关于我

关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术

网易考拉推荐

MicroStore: 构建Web应用的新基础设施  

2009-03-19 21:30:50|  分类: 数据库 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Web应用在数据管理层的基础设施一起以来是关系数据库、文件系统与全文检索系统的天下,其中关系数据库尤为普遍,基本上可以说是开发Web应用时的必备工具。

关系数据库具有非常简洁的模型,鲁棒的实现,提供极其强大的功能,在我看来,在计算机领域,可能很难找出比这更好的以不变应万变的例子了。

但过于通用的代价通常是性能的下降。最近几年,数据库界元老之一的Mile Stonebraker已经在大声呼吁关系数据库需要改变传统的那种企图以一个系统满足各种应用需求的思维,他自己身体力行,研究出列存数据库C-Store,新型OLTP数据库H-Store,针对合适的应用,性能都比通用的数据库高10倍以上

我非常赞同Stonebraker的观点,在我看来,这可能是最近5年中数据库界最激动人心,最富于远见卓识,最有可能产生卓越成效的理念了。

因此,从07年底开始,我就开始思考如何改变传统关系数据库的架构,从而在应用于特定场合时起到性能优化作用。这一思考的第一个结果是不支持事务的存储引擎NTSE。NTSE是一个支持高并发,通过日志恢复保证数据可靠性,但不支持事务的关系数据存储。不支持事务的特性使得NTSE可以对并发度,存储空间管理,日志与恢复,操作性能等方面进行优化,同时针对Web应用数据访问热点明显的特征,NTSE还集成行级缓存,使很多时候使用Memcached成为不必要,并且可获得比组合两个系统更高的数据安全性和性能。

NTSE从07年底开始策划与设计,历经半年,于08年7月开始开发,目前系统已经功能完备,核心模块已经通过7×24小时测试,正在进行集成测试,预计5.1即可面世。

因此,现在又到了仰望星空,规划未来的时候了。下一步,应该去做什么呢?6日晚上,躺上床上准备睡觉的时候,一个想法突然冒了出来,这就是本文的主题MicroStore。

MicroStore的特点
MicroStore即微存储是大量数据量极小(几K至几M)的数据存储单元的集合,每个数据存储单元只支持单用户访问。数据存储单元通常包含极小型的关系数据库或极小型的全文检索系统。每个数据存储单元有一个唯一的标识,大量存储单元以一种简单的方式加以组合,通过MicroStore操作时需指定所涉及的数据存储单元。

MicroStore的想法来源于最近对邮件系统的研究。邮件系统中邮件数据的存储有一种方法是:一个用户的邮件元数据(该用户每封邮件的标题、发信人等信息)使用一个文件存储,该文件具有复杂的格式,需要维护一个邮件元信息的列表,提供插入、删除、修改等操作。为了对这类文件进行管理,传统方式是编写一个定制的管理程序。由于文件格式比较复杂,并且还需要通过日志恢复来保证数据可靠性,编写这一程序并不简单,估计没有5000至1万行程序下不来,并且一个没经验的程序员很可能会写出低效的程序。

实际上,从数据库的观点,一个用户的邮件元信息相当于一个极小型的关系数据库,邮件元信息列表相当于一个邮件元信息表。与大型通用数据库相比,这一极小型数据库有两个明显特点:数据量极小与无并发访问。根据这两大特点,MicroStore在实现上就可能获得明显的简化与性能提升。

1. 非常简单的并发控制机制。MicroStore只需要在最前端用一个存储单元级的互斥锁即可搞定所有的并发控制问题,不需要表锁、行锁、日志锁。索引扫描时不需要考虑页面被修改页而重来,锁定多个缓存页时不需要考虑顺序问题;

2. 一个用户的所有数据天然的就实现了良好的聚簇;

3. 易于实现在线模式更新。MicroStore中每个库同时包含模式和数据,各库的模式可独立更新。更新模式时一个单元一个单元依次进行,由于每个单元数据量极小,锁定时间很短,不会影响到在线应用。

4. 易于实现在线数据整理。同样的道理,在MicroStore中可以一个单元一个单元的进行在线数据整理。在线数据整理的便利使得MicroStore将可能使用更简单的数据结构,如删除记录时不合并的B+树等,同时还能通过定期整理消除长时间运行造成的碎片等问题。

这里面需要特别注意的一点是MicroStore通常仍然需要一个全局的,被各存储单元共享的缓存,原因是日志与恢复需要遵循WAL原则,因此不能直接用操作系统的文件缓存。

MicroStore的应用场景
MicroStore最适合用在面向个人用户提供的Web应用,除了上面说到的邮件系统外,在线书摘、在线文档、在线日记本、在线日程管理这些几乎是完全保存私有数据的系统当然是应用MicroStore最合适的场景。

然而,以UGC为主题的Web 2.0应用也可以考虑使用MicroStore,这些Web 2.0应用中数据的所有权,有一部分可以很好的按用户加以划分,比如博客、相册等,这时使用MicroStore也是可以考虑的。这些应用与邮箱等应用不同的是一个人的数据虽然只有一个人能修改,但可能被千万人所访问,因此MicroStore中数据存储单元级的粗粒度锁可能会成为障碍。但只要进行简单的计算,就可以发现这不一定会是问题。比如设一个人的博客非常火,一年有1亿的访问量,平均下来每秒也只有3次访问,针对这样的并发度,使用存储单元级的粗粒度锁是完全没有问题的。

不过Web 2.0应用中也有某些数据不适合MicroStore,通常是无法按用户进行良好划分的数据,比如社会关系网络可能就不适合。如果一个用户操作经常需要操作多个MicroStore存储单元才能完成,那这时使用MicroStore可能就不是个好主意。

  评论这张
 
阅读(928)| 评论(10)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017