看过一篇文章

http://www.sqlite.com.cn/MySqlite/6/25.Html

介绍sqlite存储结构的，分析得很简单。看过以后一直有种很困惑的感觉，昨天又看了一遍sqlite的代码，发现作者忽略了一些比较关键的问题。

page和Btree并没有确实的依赖关系，sqlite里代码大体分做3部分，sql的语言解释，page交换和缓冲，Btree的索引。这3部分也是设计一个数据库考虑最多的，首先Btree和缓冲的交换并不相互依赖，Btree索引出来的是一个缓冲的地址。这里使用Btree也好tree也好，还是只是顺序索引都好只要有一张表能够把散乱存放在文件里的数据关系起来就ok的。那么为什么要使用page的结构呢，要是你读过x86关于page结构和缓冲得相关部分就会恍然大悟，没读过也没关系我来简单的解释一下。数据库文件的数据是要在文件和内存中频繁交换的，而索引表的索引地址是不应该频繁改变的。 这里就是用一个相对地址替换内存的绝对地址，并把相对地址存放在索引表里面。

比如:

通过索引表检索到一个相对地址这个地址是有（ 页名称 + 页内偏移） 这里只要把页名称替换成页地址就成了，这里页地址是缓冲控制器把页调入内存时的页面内存地址。这样缓冲区就和索引方式就分离开来。

说到这顺便说下我们通常使用的mssql.mssql功能很强大他的默认索引是顺序索引，这里我们就看到索引方式并不会影响存储方式的例子，因为在mssql里面可以建立多种索引方式的索引表，当然其他的数据库也可以完成类似的功能。

那么数据库存储的要点就是在于如何快速和高命中的缓冲，和快速高效的索引，各自完成就可以了。

说到这想到现在流行的网页搜索技术，他的缓冲得方式应该和数据库大体相同，所不同的是这样超大型的数据服务一般是分部式的，就是有极多台服务器支持的大型存储。那如何检索呢？这里和普通数据库就完全不同的方法了。普通的数据库是将数据库内所拥有的key排序而检索。网页搜索是将一本字典预先排序而不问数据库中是否有这个key.那么网页的整理就是想包含相关词条的网页链接放入预先排好序的索引里面。这里在提点旧话就是网页rank，这个rank根本就是和索引存储无关也不是后期整理所得。rank是在网络蜘蛛抓起网页的时候为了不重复分析网页所用的，当蜘蛛抓到一个网页链接的时候就会到数据库中检索这些链接是否已经被其他蜘蛛分析过，当遇到已经分析过的链接时就把这个链接的 rank++ 并跳过对这个网页的分析。那么对没个词条下的网页数据排序的时究竟用如何标准~切以为现在就是金钱使然跟rank已经全无关系。