Timesten内存数据库架构扩展应用实践

大数据使得内存数据库热了起来。调查显示，“内存数据库”成为仅次于“分布式存储与计算”的最受关注的新技术。内存数据库之所以受到越来越多的关注，与其性能上的飞跃和性价比的不断提升有着密不可分的关系。

　　应用系统架构

　　汪洋认为：理想情况下的应用系统架构，子系统应该是相对比较独立的，子系统之间关联较少，而且相互关联的子字体数量相对较少。

　　实际情况往往是大相径庭的，子系统之间存在很高的耦合性。子系统内读写错综复杂，基本上不可能实现读写分离。

　　面对这样的现实，出于成本和风险的考虑，很难做到子系统的解耦，理想情况也只能是理想了。

　　数据库架构

　　

　　对于一个系列的业务应用来说，肯定不可能通过单个数据库来实现的。需要的是一个数据库群。包含核心库、业务应用库，以及各种功能性的库，根据重要性做层级划分。

　　数据库之间实现即时的数据同步，实现一套完整的数据库生态环境。厚重的架构很难进行数据库体系的解耦。

　　子系统与数据库的对应

　　

　　在一套完整的数据库生态系统中，子系统和数据库也不是能独立开的。理想情况是若干子系统分布在一个数据库中，数据库基本上是自包含的。现实仍然是残酷的，往往是子系统和数据库出现多对多的关系。

　　现有架构做解耦、拆分、横向扩展只能是无动力驱动的高铁动车。

　　标准的三层架构：WEB服务器接受用户请求、应用服务器封装业务逻辑、数据库服务器负责数据查询和处理

　　数据库的负载：应用过来的所有负载、磁盘的IO问题、高并发问题。

　　Oracle VS. TimesTen

　　对于一些并发和响应速度要求较高的应用场景来说，TimesTen有明显的响应速度和即时吞吐量的优势;

　　TimesTen小巧快捷，独立使用优势不大，应该尽可能与Oracle联合使用;

　　TT支持Direct和C/S两种连接模式：Direct模式可作为中间件部署，C/S模式可作为独立数据库部署。

　　

　　内存数据库基本判断规则

　　规则 #1：内存数据库是整体装载在内存中的

　　规则 #2：内存数据库不存在复杂的代码去判断数据的位置并访问数据，因此可以获得更低的延迟和更快的响应时间。

　　TimesTen优势的秘密

　　完全内存存储和内存读写，没有缓冲缓存管理开销;

　　更短的SQL路径导致更快的性能，更少的CPU指令导致更少的CPU开销。

　　

　　

　　▲结构

　　1、后台进程

　　主进程(Daemon)：

　　监听功能(Listener);读取配置文件odbc.ini;分配和监视子进程。

　　子进程(Sub Daemon)：

　　载入/卸载Data Store;将日志缓存写入日志文件;监视和解除死锁;执行检查点。

　　2、内存结构

　　Data Store

　　- 保存所有数据库数据的区域

　　日志缓存

　　- 用于暂时存储记录Data Store变更的日志

　　临时数据区域

　　- 临时存储执行计划等数据的共享区域

　　- 排序等等操作临时使用。

　　3、文件结构

　　配置文件odbc.ini：用于记录各个DSN的参数

　　检查点(Checkpoint)文件

　　- 保存于磁盘的数据库镜像。

　　- 启动时，检查点文件的数据被装载到内存中

　　- 运行时，隔一段时间进行一次检查点处理，仅保存改变的数据块，并删除无用的日志文件

　　- 关闭时，用于保存Data Store内的数据

　　日志文件

　　- 保存数据库的变更

　　- 有文件超过一定的大小，自动生成新的日志文件

　　- 与检查点文件一起用于数据库的恢复

　　TimesTen高可用架构

　　TimesTen支持多种容灾复制方式：

　　- 主从复制(Active-Standby)

　　- 双主复制(Active-Active)

　　- 环形复制

　　- 衍生复制

　　架构设计原则

　　- 主从复制方式足够了;

　　- TimesTen本身就是轻量级的，简单至上;

　　- 不要期望TimesTen能像Oracle一样强大。

Timesten高可用架构

　　架构演进

　　之前为Oracle数据库全部存储在SAN传统存储设备上。 中间件直连Oracle数据库，对应用提供服务。

　　引进Flash存储设备，将Redo日志和部分热点； 数据文件转存其上，获取较好的IO性能。

　　引进TimesTen内存数据库，作为数据库中间件置于； 中间件与Oracle数据库之间，数据在TT和Oracle之间快速同步。

　　将部分需要快速响应的业务分流到TimesTen上， 彻底缓解Oracle数据库压力。