OLTP 内存存储引擎（非嵌入式版）使用教程

在一些数据库应用场景中，例如金融行业的交易系统，其主要工作负载来源于对关系表的高频度、高并发的更新和查询操作。这样的应用场景要求数据的读写和计算能够具有低延迟、高并发的特征，同时保证极高的数据一致性，并提供 ACID 事务的支持，是典型的在线事务处理（OLTP）场景。传统的存储引擎由于其架构的设计出发点是将数据存储在磁盘上，在面对上述场景要求时，软硬件层面面临巨大挑战，无法很好地满足上述苛刻的性能要求。而在这些场景中，往往需要维护的数据量实际上没有那么大，那么，能否把所有的数据都维护在内存里呢？这样就可以减少读写磁盘的带宽，能够大大降低数据库的延迟和提升数据库的并发度。

基于这个想法，DolphinDB 设计并实现了一款纯自研的内存 OLTP 数据库，它有以下特点：

• 将所有数据都存储在内存中，省去磁盘 I/O 的开销；
• 以行存的形式来组织数据，主要适用于 OLTP 的场景；
• 支持创建 B+ 树索引 (主键索引和二级索引) 来应对高频度、高并发的更新和查询操作；
• 支持事务，默认为 snapshot isolation；
• 实现 Write-Ahead-Logging 和 checkpoint 机制以保证数据的持久化和恢复；
• 为加速重启时的恢复过程，实现了并行恢复机制。

下文将介绍 OLTP 的使用方式。

后文的例子假设已经执行过下面的脚本来建库建表：

dbName = "oltp://test_imoltp"
tableName = "test_table"

if (existsDatabase(dbName)) {
    dropDatabase(dbName)
}

db = database(dbName, VALUE, 1..100, , "IMOLTP")

// pt 以 id 为主键，没有二级索引
pt = db.createIMOLTPTable(
    table(1:0, ["id", "val1", "val2", "sym"], [LONG, INT, LONG, STRING]),
    tableName,
    primaryKey=`id
)

使用 transaction 语句块可以在一个事务内执行多条 DML 语句，在一个事务范围内，所有的 DML 操作都会一起成功或一起失败。若一个事务执行的时候有异常抛出，会自动撤销本次事务的所有更改。

pt = loadTable("oltp://test_imoltp", "test_table")

delete from pt

transaction {
    insert into pt values(0, 0, 0, `aaa)
    insert into pt values(1, 1, 1, `bbb)
    insert into pt values(2, 2, 2, `ccc)
    commit  // 提交事务（可以省略）
}
assert (exec id from pt order by id) == [0,1,2]

transaction {
    insert into pt values(3, 3, 3, `ddd)
    insert into pt values(4, 4, 4, `eee)
    delete from pt where id = 1
    update pt set id = 10 where id = 0
    
    assert (exec id from pt order by id) == [2,3,4,10]
    rollback  // 强制回滚事务，撤销所有修改
}
assert (exec id from pt order by id) == [0,1,2]

commit 表示提交本次事务的所有更改，rollback 表示撤销本次事务的所有更改。不需要显式地写 commit，出了 transaction 语句块的作用域时会自动 commit。

目前 OLTP 有以下配置参数可以设置：

• enableIMOLTPEngine，bool 类型。表示是否开启 OLTP 引擎。默认为 false。
• enableIMOLTPRedo，bool 类型。表示是否开启 WAL（Write-Ahead-Log），开启之后才能保证数据不会丢失。默认为 true。
• IMOLTPRedoFilePath，string 类型。表示 redo 文件（即 WAL 文件）的路径（注意不是目录），可以为绝对路径或者相对路径。当为相对路径时，相对于 home 目录下的 IMOLTP 目录。默认为 home 目录下的 IMOLTP/im_oltp.redo。
• IMOLTPSyncOnTxnCommit，bool 类型。只在 enableIMOLTPRedo 为 true 时（即开启了 WAL）有意义。默认为 false。详细解释见下文。
• enableIMOLTPCheckpoint，bool 类型。表示是否开启 checkpoint。默认为 true。
• IMOLTPCheckpointFilePath，string 类型。表示 checkpoint 文件的路径（注意不是目录），可以为绝对路径或者相对路径。当为相对路径时，相对于 home 目录下的 IMOLTP 目录。默认为 home 目录下的 IMOLTP/im_oltp.ckp。
• IMOLTPCheckpointThreshold，long 类型，单位为 MiB。 表示：如果 redo 文件里面的 log 大小达到该阈值后，会触发一次 checkpoint。默认为 100 MiB。
• IMOLTPCheckpointInterval，long 类型，单位为秒。表示每隔 # 秒之后强制做一次 checkpoint。默认为 60 秒。

当开启了 checkpoint 时（即 enableIMOLTPCheckpoint 配置为 true ），系统会在达到以下两个条件之一时自动触发 checkpoint：

• redo 文件里面的 log 大小达到阈值（IMOLTPCheckpointThreshold MiB）；
• 或者，距离上一次 checkpoint 过去了 IMOLTPCheckpointInterval 秒。

用户也可以手动调用 triggerCheckpointForIMOLTP 函数来触发 checkpoint。函数语法如下：

triggerCheckpointForIMOLTP([force=false], [sync=false])

参数：

• force，bool 类型，可选。表示是否强制做 checkpoint。如果为 false，并且当前并没有达到做 checkpoint 的条件（即 redo 文件里的 log 大小没有达到 IMOLTPCheckpointThreshold），则忽略这次请求。默认为 false。
• sync，bool 类型，可选。表示是否异步。如果为 false，则该函数请求一次异步的 checkpoint，并不会等到请求完成再返回；否则该函数会等到请求完成（注意不一定做了 checkpoint）再返回。默认为 false。

DolphinDB 推出的OLTP 内存数据库适用于高并发、低延迟的在线事务处理场景。该数据库将数据存储在内存中，支持 B+ 树索引、事务、Write-Ahead-Logging 和 checkpoint 机制。事务通过 transaction 语句块实现，保证了操作的原子性。

用户还可以通过配置参数的配置以及内置函数 triggerCheckpointForIMOLTP 的使用，手动触发 checkpoint。

总体而言，DolphinDB 的 OLTP 引擎适用于对数据一致性和性能要求较高的场景。