漫谈数据库扩展-跨库分页

声明：本文借鉴网上的观点，加入自己的理解。如有不正之处，欢迎指正。

前言

今天继续前面《一分钟了解数据库扩展》引出的几个问题，上篇《漫谈数据库扩展-跨库join查询问题》介绍了解决分库分表下的数据join问题。今天，谈谈分页问题及解决方案。

背景

web应用，或多或少都会涉及到数据分页展示的场景：

用户点击下一页，数据展示下页偏移数据。

用户指定某一些，数据展示指定页偏移的数据。

分页展示有些会给出总页，第一页的信息。

等等…

问题

常规，单库的分页很好实现，通过数据库SQL提供的offset/limit来处理。但是，当数据分布在不同的实例上的时候。就不能简单的通过一个sql语句来处理了。

如，实现下面这个分页sql：

解决方案

全局汇总

最简单的方法，将N个实例上的数据汇总，进行内存分页。

汇总，将N个库返回的数据N*（X+Y）条数据放入内存整合，然后取出X后的Y偏移的数据。

优点

业务处理简单。

数据准确。

缺点

返回数据量大

消耗更多的业务服务器性能（内存(数据)，cpu（需要二次排序））。

随着页数的增加，性能急剧下降（野鼠越大，每次总各个库返回的全局数据越多）。

禁止跳转页

针对上面的问题，进行业务折衷。什么业务折衷呢？想必大家一定见过如下两种分页交互方式。

支持上一页，下一页，跳转第几页。

传统分页

只支持上一下，下一页。

搜索分页处理思路

每次翻页记录上一次的最大值,如：记录time最大值。在第一种sql的基础上增加where条件。

这样，优化后的分页交互方式。是的每次只需要查一页数据。不会随着页数的增加，返回数据也增加。

优点

性能为常量（每次翻页，都只是一页的数据）。

降低了内存和cpu的消耗。

缺点

业务功能缺失（少了跳转页的功能）。

分布式数据库架构

如今，大数据，分布式，微服务的时代。早已诞生了很多应对产物。对于分布式下的数据存储和查询处理（基于hadoop、hive等），分布式计算框架也可以间接的解决。

如：MapReduce的计算框架，就是将分布式下的数据进行内存汇总计算。

优点

并发处理能力。

可以离线处理。

缺点

实时性不高。

系统复杂度增加。

分布式组件

除了原始的分布式存储引擎外，一些分布式组件也提供了间接分页功能。可以优化分页性能。

如：搜索引擎Solr、ES。

一些非关系型数据库，如：MogonDB等。