本章讨论“使用分布式实时数据库服务器解决超大容量实时和历史数据访问”的问题。
在开发远程移动监控系统时，一般有两种技术路线，一种是直接开发针对特定行业特定应用的系统，另一种是选用组态软件进行二次开发，这两种技术路线各有优缺点。当管理功能是远程移动监控系统的主要功能点，或者监控对象具有非常独特的行业特性，直接开发应用系统是一种合理的选择。而当监控功能是远程移动监控系统的主要功能点时，选用合适的组态软件，可以减少投入成本，缩短项目周期、提高系统稳定性，减少失败风险。
不管采取以上哪种技术路线，都不可避免地要对一个问题进行决策：如何保存采集到的数据。保存的概念包括三个方面：内存中保存的实时数据，磁盘上保存的历史数据，针对实时数据和历史数据的访问接口。可以选择的方案有五种：
1、组态软件本身的内存和历史数据库（或模块）；
2、自定义的内存和文件格式；
3、关系数据库；
4、实时数据库；
5、关系数据库+实时数据库；
针对以上两种不同的技术路线，可以选择不同的数据保存方案，当需要采集和保存的数据点达到一定的规模时，就需要采用方案4或方案5，在我的上一篇文章《实时数据库与组态软件的市场定位之异同》中，提到了依据工程总点数和需保存的总点数来决定是使用实时数据库还是组态软件，在远程移动监控系统中，当系统的点数规模超出了组态软件能处理的范围时，关系数据库也同样不能处理。
还是以那个重型机械厂的项目为例说明，如果按照每台车辆每10秒向上传送一次数据，每次传送100个数据，车辆总数按50000台计算。
如果采用Oracle关系数据库来存贮实时和历史数据。对数据的保存有两种方式，这两种方式也决定了上层Oracle数据库的数据表设计方案。
第一种方案是每个车辆设备的数据用一条记录来表示，每条记录有100个字段，这样设计的好处是采集服务器操作ORACLE服务器的事务数比较小，平均每秒钟的插入事务数为50000*5/60=4167条。该方式的缺点是，对不同的DTU需要设计不同的数据表；数据不能被压缩，磁盘空间占用非常大，如果每条记录按1K来计算，则一年需占用的磁盘空间为：356*24*60*60/5*50000*1024=293335G，再加上索引等辅助内容，整个系统一年所占用的磁盘空间约为400000G。
第二种方案是每个车辆设备的数据用多条记录来表示，每条记录只记录该DTU中某一个具体的数据点，这样处理，Oracle服务器的事务数达到每秒钟50000*100*5/60=416667次，在这种情况下，对数据可以采取一些压缩处理，系统一年所占用的磁盘空间与第一种方案相比，可以减少到1/10左右，约为40000G。
不管是采用以上的哪一种方案，都存在单位时间的读写次数达到系统处理上限，系统容量超出系统上限等困难，导致系统无法使用。可以通过引入网格数据库，或重新规划需保存的历史数据等方式解决这些难点问题，但都存在缺点，不是价格高，就是不得不损失相应功能。
引入实时数据库，只能部分解决此问题，举例说明，如果使用我们的实时数据库，单台服务器只能处理5000台左右车辆设备的数据采集和保存问题（经过定制改造，如果不改造，单服务器只能处理1000台车辆设备，该问题的瓶颈不在于性能，而在于点数限制，目前我们的标准实时数据库单台服务器只支持126000个数据点），仍不能处理高达50000台车辆设备。
这时，需要使用分布式实时数据库服务器来解决超大容量实时和历史数据访问，如下图所示（图略）。
可以看到，单台服务器处理5千台设备，处理的数据点为50万个，10台实时服务器能处理5万台设备，处理的总数据点为500万个，调度服务器对这10台服务器进行调度，使得10台服务器对外部而言（包括采集服务器和客户端）是透明的，外部只看到一台能处理500万数据点的大型实时数据库。
要实现一个分布式分布式实时数据库服务器，可能做得非常复杂，但对于大型远程移动监控系统中，可以简化处理，当然，这需要实时数据库支持层次点系统、设备模块、在线修改等功能的辅助支持，关于这方面的内容，在下一章中加以说明。