db2 的缓冲池设计

 

最近接到一些朋友的信，问一些关于缓冲区管理的问题。俺想借此机会也写个短篇总结一下“什么是缓冲区管理”。

很多用户可能都有疑问，缓冲区是不是越大越好，是一个单独的大缓冲池好还是若干个稍小的缓冲池好。

总地来说，这个问题没有一个标准答案。

在俺的经验中，缓冲区管理可以归纳为两个字：质，量

缓冲池的作用是把数据临时存放在内存中，避免物理读写
因此，假设用户使用64位实例，也就是逻辑内存基本没有限制的情况下，如何用有限的物理内存跟有效地存取海量数据，这个是缓冲池设计的关键。

而“质”的概念就是，如何更有效地将重要的数据驻留在内存。注意这里“重要”的数据并不永远等同于“最经常访问”的数据。有的时候，有些表访问不频繁，但是每次访问需要尽可能高的效率，但是缓冲区本身的设计是尽可能保留经常访问的数据在内存，因此这两者之间是有冲突的。“质”的含义就是，如何控制缓冲区使得最重要的数据驻留内存。

另一方面，“量”的含义就比较好理解了。在一个有限内存的机器中，我们不可能把数据库所有的数据放到内存里（如果数据库够小就没问题，但是对于大多用户来说是不现实的）。因此，如何分配内存的使用，做到将最重要的数据放到内存，次重要的数据可以被反复读写，这对于最小的缓冲区大小是有一定需求的。比如说我一个最重要的表有100MB，你的缓冲区如果小于100MB肯定不可能把整个表放进去。但是如果缓冲区只有100MB并且只为这个表分配，那其他的数据怎么办？因此选择一个缓冲区大小，做到数据间的平衡是至关重要的。所以说，“量”就是指如何决定缓冲区的大小。

因此，“质”与“量”体现在缓冲区设计的两个最主要的方面。“质”就是在给定内存中，如何划分一个或者多个缓冲区，以尽可能将最重要的数据驻留内存。换句话说，也就是决定了数据库需要几个缓冲池，哪个表用哪个缓冲池。而“量”就是说需要分配多少内存给缓冲池才算合理。

听起来简单做起来难，并且我们没有任何一个公式能够告诉你答案。命中率是一个不错的东西，但是并没有一个指标说95%以上一定是好的，90%以下一定是不好的。这个必须根据用户需要的业务决定。比如说用户的数据库里面有一个小表数据量不多（比如几十万或者百万），访问不是很频繁，但是每次访问需要极高的效率，否则会造成业务瓶颈，这样的话可以考虑使用单独的缓冲池盛放这些数据。要不然如果这个表和别的表共享缓冲池，则可能该表在长时间不用后数据被flush出内存。

可以想象，使用单独的大缓冲池管理简单，所有的数据遵照使用频繁程度决定是否停留在内存里面。但是当按照使用频率无法满足业务需求的时候，可能需要对特定类型的数据使用单独的缓冲池。

而是不是命中率低就一定需要增大缓冲池呢？也不一定。命中率高低只是现象，其本质是数据在内存中的读写频率。有没有方法在不增减缓冲区大小的情况下调整命中率呢？有啊，比如把某些表移到另外的缓冲池中~~~归根结底，缓冲区的管理就是什么数据，多少数据应该驻留内存的管理。

 

非常精辟。。。。
我一直认为只有达到一定境界了，解释问题才能深入浅出。
缓冲区管理就是在资源有限的情况下，如何把你想留在内存的数据尽量留在内存中，
这就要靠调节缓冲区的个数和大小来做到。
“质量说”很新颖。。。。

建好索引用好索引，在索引都没有创建好的情况下，何谈缓冲池命中率

 

缓冲区,朋友, 总结, 用户, 标准