oracle times ten 学习笔记

1. times ten本质上是关系型数据库。

2. 性能：12个cpu情况：读300万/s，写50万/s。

3. 可靠性：通过主备机的实时备份保证单点故障，也即应用程序的请求消息在主机times ten（一下简称active）和备机times ten（一下简称standby）的内存都会有一份，可以避免单点故障。

4. 应用程序可以选择是从内存返回还是从文件返回，也即应用程序的请求是到times ten内存后就返回，还是通过times ten将应用程序请求写入文件后再返回，这里有个性能和安全的平衡。

5. 如果active宕机了，standby会自动重连应用程序，这个实现原理是：应用程序连接到active后，active会将连接的session传输一份给standby，当active宕机后，active和standby之间的通讯中断，standby就知道active宕机了，就会获取应用程序的连接session，然后去relink应用程序。

6. 物理数据库中的数据load到times ten时可以采取预加载和动态加载两种方式，如果应用的case有需求要将oracle数据库中的更新同步到times ten内存数据库中时，需要采用动态加载的方式加载，当然动态加载的话会损失一点性能。

7. Times ten写两种日志，一种是logs files，一种是checkpoint files。也即一种是数据日志，一种是数据更新的日志。

8. Times ten运行起来后主要有以下的线程：

 


也即一个进程下有十个线程，可以看出times ten在十二个cpu下性能达到最好的原理。其中每个线程具体干什么事情，我问他们，他们没有告诉我，从听课中我了解了一部分的工作原理。

a) Manager是一个管理线程

b) Flusher是将内存中的数据更新部分同步到物理数据库中。

c) Monitor是监控一些资源的使用情况及性能的瓶颈在哪里，具体的监控项很多，可以参考客户给的ppt中的monitor一节。

d) Log Marker是将内存中的数据写入磁盘，也即写入log files，

e) Checkpoint是将内存中的数据更新写入checkpoint files。

以上几个功能块大概的有个处理逻辑就是：内存中的所有数据都异步的通过log marker 线程落地到log files，内存中的数据有更新部分（insert和update）通过checkpoint线程落地到checkpoint files。数据文件log files被扫描将更新部分写入checkpoint files 后，这部分数据日志log files即可删除，checkpoint files中的更新，通过flusher线程同步到物理数据库中，已经扫描处理并同步到物理数据库中的数据即可删除出checkpoint
files。

9. 支持cache grid，local cache group，global cache global等缓存技术。其中cache grid可以起到防止数据漂移的作用。

写times ten应用程序和oracle应用程序之间差异：

1. times ten的pl/sql可以调用sql，但是sql不能调用pl/sql.

2. times ten commit时会关闭游标cursors

3. 不支持blob/clob.

4. times ten没有数字类型的隐式转换等

实际情况会碰到log files 不断增大的问题，写磁盘的速度跟不上times ten的处理速度，写物理数据库的速度跟不上times ten的处理速度等都可以用较高性能的磁盘读写设备，或是其他的扩充方案来解决，这个需要根据实际的case具体对待。我也没有详细去研究他们做过的case。

Times ten包含的内容还是挺多的，我就说个大概，很多内容我就不在这里写了。自己觉得他们的性能和解决方案还是挺不错的，也和异步运行机制，cpu的power，disk的读写能力等硬件性能分不开。如果是只读的case，处理能力还是很强大的，但是既要读写，又要保证可靠性的话，处理能力就会小很多。他们有个证券的case将客户端的吞吐量从3000提高到15000。