create-dwy 0.12.2 → 0.13.0

package/templates/claude-global/skills//346/225/260/346/215/256/345/272/223/dwy-dolphindb/references/official/db_distr_comp/db/iotdb.md

@@ -0,0 +1,419 @@
+---
+source_url: https://docs.dolphindb.cn/zh/db_distr_comp/db/iotdb.html
+fetched_at: 2026-05-19T09:04:52Z
+category: db_distr_comp
+title: 物联网点位管理引擎
+sha1: 70ee182b85c8f1ab7412319fdf0ca00131bdad8e
+---
+
+# 物联网点位管理引擎
+
+DolphinDB 提供物联网点位管理引擎（IOTDB
+引擎）以对海量测点进行精细化、低延时的点位管理。用户能够在建表时使用含可变类型的列，并且系统会自动缓存每个点位的最新值数据，从而大幅提升查询性能（目前可达毫秒级）。
+
+## 基础概念
+
+本节将介绍物联网点位管理引擎中的一些基本概念。
+
+### 点位
+
+在物联网（Internet of Things，简称
+IoT）中，“点位”通常指被监控或管理的物理对象上的具体信息点或数据采集点。这些点位可以是传感器、执行器、控制器等物联网设备上的具体接口或参数，也可以是设备本身作为一个整体被监控的标识。其中数据对象包括静态属性（ID，名称等）和动态属性（温度，压力，湿度，状态等）。
+
+### 点位数据特点
+
+- **数量巨多**：在电网、车联网、工业制造场景中，点位数从几百万到上亿点不等。
+- **采样频率高**：某些极端场景下，点位的采样频率高达 100KHz。
+- **数据类型复杂**：点位数据类型涵盖布尔型、整型、浮点型、枚举型等。
+- **数据传输形式多样**：同一设备的点位数据，可能同一时间采集、同一批次上传，也可能不同时间采集、单独上传。
+
+### 物联网点位管理引擎 / IOTDB 引擎
+
+DolphinDB 在 3.00.2
+版本中推出的基于 TSDB 引擎自研的、针对物联网场景中海量点位数据进行高效管理的存储引擎。
+
+### IOTANY 列
+
+值类型可变的列，能够在单值模型的字段里存储不同类型的属性值。
+
+### 最新值缓存功能
+
+系统实时更新最新值缓存，并直接从缓存而非磁盘中读取数据，创建以分区为单位的最新值缓存表。最新值缓存功能可在 create 或
+`createPartitionedTable` 中通过 *latestKeyCache*
+参数开启。功能说明小节将详细介绍其原理。
+
+### 点位管理表
+
+- 包含 IOTANY 列的表。（推荐）
+- 使用物联网点位管理引擎（IOTDB 引擎）、且开启最新值缓存功能的分布式表、流数据表或共享内存表。
+
+### 静态表
+
+对 sortColumns 中指定的除最后时间列外的其它列进行映射。将其映射为内部 ID。在后续的存储和缓存操作中，系统将通过内部 ID
+来代指某个测点，以达到节省存储空间的目的。该表与 SymbolBase 类似，以分区为单位。该映射会存储于静态表中，用户无感知。
+
+## 功能说明
+
+本节将从原理、使用、管理等多个角度详细介绍 IOTANY 列和最新值查询优化。
+
+### IOTANY 列
+
+IOTANY 列即值类型可变的列，建表时最多可以创建一个 IOTANY 列。IOTANY 列类型只能用在 create
+语句中，不能单独建一个该类型的向量或者表。DolphinDB 在存储 IOTANY 列数据时， 将在 **TSDB** Level File
+层级单独存储不同类型的值。
+
+关于 TSDB 存储引擎，物联网点位管理引擎：
+
+- 规定将唯一标识一组测点的**多个列（一般为 id 列+各种 tag 列）+时间列**设置为 sortColumns。
+- 支持两种去重策略：ALL（保留所有数据，为默认值）， LAST（仅保留最新数据）。
+- 支持 HashMappingFunction。
+- 暂不支持 softDelete。
+- 最新值查询功能暂不支持 snapshot read。
+- 暂不支持 level 4 compaction。
+- 暂不支持向量数据库等。
+- 暂不支持添加 IOTANY 列。
+- 不支持 sortColumns 中包含 DECIMAL 类型。
+- 不支持 upsert! 时设置 ignoreNull=true。
+- 不支持 upsert! 时传入 IOTANY 向量。
+
+### 最新值查询优化
+
+最新值查询的优化有最新值缓存表和最新值查询优化两种方式。
+
+一般情况下，我们通过`context by`
+**id+tag 列**
+`csort`
+**时间列**
+`limit
+-1`语法来查询最新值：
+
+```dolphindb
+select deviceId, timestamp, metrics1... from pt
+where deviceId = xxx context by deviceId csort timestamp limit -1
+```
+
+针对最新值查询，物联网点位管理引擎引入两种优化：
+
+- **最新值缓存表**：引入以分区为单位的最新值缓存表。系统将**实时更新**最新值缓存，并直接从**缓存**而非磁盘中读取数据。此外，物联网点位管理引擎提供预热机制，重启后自动加载最近时间分区的缓存数据，优化冷启动场景。
+- **存储引擎层的最新值查询优化**：在存储引擎层实现 context by 最新值算法，根据 index zonemap
+  进行过滤，只读取磁盘上部分的 block。用于支持缓存表 cache miss 的情况。
+
+以下介绍两种优化方法的使用前提和优先顺序：
+
+| 优化逻辑 | 使用前提（符合任一） |
+| --- | --- |
+| 最新值缓存表 | - 查询语句不包含任何 where 条件。 - 查询语句包含 where 条件，过滤条件仅包含部分或全部 firstSortKey   列，firstSortKey 支持的过滤类型：=, <, <=, >, >=,   between, in。 - 查询语句的 where 过滤条件涉及 lastSortKey 列且不涉及其他任何非   sortKey 列，lastSortKey列支持的过滤类型为<, <=, >, >=,   between。 |
+| 最新值查询优化 | - 查询的 where 条件需要包含所有的 firstSortKey   列，并且可以包含时间列（时间列 where 条件支持的过滤类型：=, <, <=, >,   >=, between）。 - 如果 firstSortKey 有多列，则每一列的过滤条件只支持等值过滤（即=）。 - 如果 firstSortKey 只有一列，则过滤条件支持等值过滤和 in 过滤。 |
+
+注意：
+
+- 最新值缓存表的条件三中，当 lastSortKey 列的过滤类型为 <, <=, between
+  时，需要最新值缓存表内 lastSortKey 列中的所有数据均满足 where
+  过滤条件才会通过缓存表返回结果。例如，最新值缓存表 lastSortKey
+  列`ts`的范围为`[2024.01.01,
+  2024.01.15]`，且 where 条件为`ts <
+  2024.01.16`，此时可以通过查询最新值缓存表获取查询结果。
+- 若满足最新值缓存的使用条件，则优先从最新值缓存表中读取数据。
+- 若不满足最新值缓存的使用条件，则尝试最新值查询优化。
+- 若均不符合条件，则遵循先前版本逻辑。
+
+假设一个 TSDB 分布式表 test 的 sortColumns
+为`` `c1`c2`timestamp ``（其中称 c1, c2 为 firstSortKey，timestamp 为
+lastSortKey），则可以按照以下格式指定最新值查询：
+
+`select [cols] from test
+[where] context by c1,c2 csort timestamp limit
+-1.`
+
+下面给出一些查询语句示例以及这些查询会使用的优化方式：
+
+| sortColumns | SQL | 方式1：最新值缓存表 | 方式2：最新值查询优化 |
+| --- | --- | --- | --- |
+| c1, c2, timestamp | `select [cols] from pt context by c1, c2 csort timestamp limit -1`  （不包含任何过滤条件） | 可使用 |  |
+| c1, c2, timestamp | ```dolphindb select [cols] from pt where c1 in [x,x,x] and c2 = xxx context by c1, c2 csort                 timestamp limit -1 ```  （多个firstSortKey，且有firstSortKey的过滤类型为非等值过滤） | 可使用 |  |
+| c1, c2, timestamp | ```dolphindb select [cols] from pt where c1 = xx and c2 = xx and timestamp >= xxx context by c1, c2                 csort timestamp limit -1 ```  （涵盖所有firstSortKey，并且有lastSortKey过滤） | 可使用 | 可使用 |
+| c1, c2, timestamp | ```dolphindb select [cols] from pt where c1 = xx and c2 = xx  context by c1, c2 csort timestamp                 limit -1 ```  （过滤条件包含所有firstSortKey） | 可使用 | 可使用 |
+| c1, c2, timestamp | ```dolphindb select [cols] from pt where c1 = xx and timestamp > xxx  context by c1, c2 csort                 timestamp limit -1 ```  （过滤条件包含部分firstSortKey以及lastSortKey） | 可使用 |  |
+| c1, timestamp | ```dolphindb select [cols] from pt where c1 in [x,x,x] context by c1, c2 csort timestamp limit                 -1 ```  （过滤条件包含所有firstSortKey，且firstSortKey过滤类型为in） | 可使用 | 可使用 |
+| c1, timestamp | ```dolphindb select [cols] from pt where c1 in [x,x,x] and timestamp between xxx and xxx context                 by c1, c2 csort timestamp limit -1 ```  （过滤条件包含所有firstSortKey和lastSortKey） | 可使用 | 可使用 |
+| c1, timestamp | ```dolphindb select [cols] from pt where c1 > x context by c1, c2 csort timestamp limit               -1 ```  （过滤条件包含所有firstSortKey，firSortKey过滤类型不是 `in` 或 `=` ) | 可使用 |  |
+
+#### 通过 HINT\_EXPLAIN 查看是否使用优化
+
+可以通过 HINT\_EXPLAIN 查看是否使用、以及具体使用了什么优化。
+
+如果查询是最新值查询（即 context by firstSortKey 列，csort lastSortKey 列，并且 limit
+为-1），则查询开启HINT\_EXPLAIN 后，将可以在输出中看到 lastQuery 字段，该字段包含以下三种可能的输出形式：
+
+1. 采用最新值缓存查询：
+
+    `"lastQuery": { "optimizationMethod":
+   LatestKeyCache },`
+2. 采用最新值查询优化查询：
+
+    `"lastQuery": { "optimizationMethod":
+   LatestKeyQuery },`
+3. 两种优化方式均不满足:
+
+    `"lastQuery": { "optimizationMethod": None
+   },`
+
+#### 有重复数据时的最新值查询语义
+
+如果存在两条 id 相同、时间戳相同的数据，当使用 context by 查询最新值时，只会保留其中的一条。比如：
+
+| id | timestamp | value |
+| --- | --- | --- |
+| 1 | 10:00 | 1 |
+| 1 | 10:00 | 2 |
+
+```dolphindb
+select * from pt where id = 1 context by id csort timestamp limit -1
+```
+
+当对普通分区表使用 context by 时，并未明确规定保留对象，故将随机保留一条数据。但在 IOTDB 引擎中，对点位管理表使用 context by
+时，已明确规定**保留最新一条**，不会被 KEEP\_LAST 或 KEEP\_ALL 的设定影响。
+
+#### 最新值缓存表管理
+
+最新值缓存表以分区为单位，存储该分区内所有测点的最新值。写入时实时更新，随 Cache Engine 一同flush。持久化保存在每个分区的
+tableDir 目录下。文件名为 *timeseries.cache*。
+
+缓存管理与 symbolBase 一致，定期移除最近未使用的分区。参数 *IOTDBLatestKeyCacheSize*专用于控制最新值缓存表管理，默认为 maxMemSize 的 5%。
+
+```dolphindb
+IOTDBLatestKeyCacheSize=0.5 //浮点数，单位为G
+```
+
+## 数据类型
+
+IOTANY 类型目前支持如下几种类型：
+
+| categroy | 类型 |
+| --- | --- |
+| Integral | CHAR |
+| SHORT |
+| INT |
+| LONG |
+| Logical | BOOL |
+| Floating | FLOAT |
+| DOUBLE |
+| Literal | SYMBOL |
+| STRING |
+
+## 使用示例
+
+本节将对创建点位管理表，表数据写入和查询、最新值查询等操作进行示例说明。
+
+### 创建示例
+
+推荐通过 create 语句创建含 IOTANY 列的点位管理表。
+
+下例中，我们通过复合分区方案按 deviceId 和 timestamp 分区，创建了一个名为 pt 的点位管理表。该表使用 deviceId 和
+location 作为唯一识别一个点位的两列，启用最新值缓存，且 value 为 IOTANY 类型，可存储不同类型的测点数据；启用了 hashSortKey
+压缩。
+
+```dolphindb
+dbName = "dfs://db"
+if (existsDatabase(dbName)) {
+    dropDatabase(dbName)
+}
+// 创建数据库，存储引擎为IOTDB
+create database "dfs://db" partitioned by HASH([INT, 20]),VALUE(2017.08.07..2017.08.11), engine='IOTDB'
+// 创建点位表，其中 firstSortKey 为 deviceId 和 location，lastSortKey(时间戳列)为 timestamp
+create table "dfs://db"."pt" (
+        deviceId INT,
+        location SYMBOL,
+        timestamp TIMESTAMP,
+        value IOTANY
+)
+partitioned by deviceId, timestamp,
+sortColumns = [`deviceId, `location, `timestamp],
+latestKeyCache = true
+```
+
+### 写入示例
+
+对于每个测点，第一次写入时会确定其 IOTANY 列的类型，如果之后对该测点写入不同的类型，会报错。
+
+在**非 KEEP\_LAST** 的情况下，可以使用 update 语句修改测点 IOTANY 列的类型，但是 **where
+条件里只能包含firstSortKey**，这样能保证每次更新所有该测点的记录，以确保同一个测点的 IOTANY 列的类型一直统一。
+
+基于上例已建立的表，进行写入对比操作。首先第一次写入数据，结果为可以正常写入，测点[1, `loc1`]的类型确定为
+INT。
+
+```dolphindb
+// 测点[1, `loc1`] 第一次写入
+pt = loadTable("dfs://db", "pt")
+t = table([1] as deviceId,
+  [`loc1] as location,
+  [now()] as timestamp,
+  [int(233)] as value)
+pt.append!(t)
+```
+
+第二次写入该测点，value 类型为
+DOUBLE。因为类型不匹配，故结果为不能写入。
+
+```dolphindb
+// 测点[1, `loc1`] 第二次写入，value类型为double
+t = table([1] as deviceId,
+  [`loc1] as location,
+  [now()] as timestamp,
+  [double(233)] as value)
+pt.append!(t)
+```
+
+尝试修改测点类型。
+
+```dolphindb
+// 修改测点类型为double
+// 修改失败，where条件只能包含firstSortKey
+update pt set value=double(233) where deviceId = 1 and location=`loc1 and timestamp >= 2017.08.07 
+// 修改成功
+update pt set value=double(233) where deviceId = 1 and location=`loc1
+```
+
+此时再次执行第二次写入的脚本，结果为写入成功。
+
+### 更新示例
+
+在非 KEEP\_LAST 的设置情况下，支持调用 update 时变更某个点位 IOTANY 列的类型。
+
+在写入示例的最后也涉及到了更新操作，此处聚焦后再次讲解。
+
+当更新列为 IOTANY列 时，where 中不能包含除 first sort key
+以外的列，否则会报错。这样是为了保证修改类型时要更新所有该点位的记录，以确保同一个点位的 IOTANY
+列的类型一直统一。
+
+```dolphindb
+t = table([`dev1] as deviceId,
+  [now()] as timestamp,
+  [`loc1] as location,
+  [int(233)] as value)
+pt.append!(t) //该测点的类型为INT
+update pt set value = 2.33 where deviceId = `dev1 and location = `loc1
+// 将测点值更新为double
+update pt set value = 2.33 where deviceId = `dev1
+// ok
+update pt set value = 2.33 where deviceId = `dev1 and location = `loc1 and timestamp > xxx
+// 不行，一次需要更新该点位所有的记录
+```
+
+### IOTANY 列查询示例
+
+基于已建立的表，进行如下查询操作：
+
+```dolphindb
+select deviceId, location, sum(long(value)), timestamp from pt where deviceId = 1 and
+  location = `loc1 and timestamp >= 2017.08.07
+//成功执行
+```
+
+### IOTANY 列计算示例
+
+基于已建立的表，进行如下计算：
+
+```dolphindb
+// 判断相等关系
+select * from pt where value = 233
+
+// 聚合计算
+select deviceId, location, sum(value), timestamp from pt where deviceId = 1 and
+  location = `loc1 and timestamp >= 2017.08.07
+```
+
+### 最新值查询（context by）示例
+
+前文介绍，最新值查询的优化有最新值缓存表和最新值查询优化两种方式。在满足不同条件时会用到不同的优化策略。本例为方便展示，将创建一个新的点位管理表。
+
+```dolphindb
+dbName = "dfs://test";
+if(existsDatabase(dbName)){
+	dropDatabase(dbName)
+}
+// 创建数据库，存储引擎为IOTDB
+create database "dfs://test" 
+partitioned by HASH([LONG,1]),HASH([DATE, 1]),
+engine = 'IOTDB'
+dummy = table(1000000:0, `date`deviceId`key1`val_any, [DATE, LONG, INT, DOUBLE])
+// 创建点位表，其中 firstSortKey 为 deviceId 和 key1，lastSortKey(时间戳列)为 date
+create table "dfs://test"."pt1"(
+        date DATE,
+        deviceId LONG,
+        key1 INT,
+        val_any DOUBLE
+)
+partitioned by deviceId, date
+sortColumns = [`deviceId,`key1,`date]
+keepDuplicates = ALL
+latestKeyCache = true
+pt1 = loadTable(dbName, "pt1")
+// 导入测试数据
+n = 200000
+date = rand(2012.01.01..2012.12.31, n)
+key1 = take(200199..(200199+n), n)
+deviceId = take(200..(200+n), n)
+val = rand(double(n), n)
+t = table(date, deviceId, key1, val)
+pt1.append!(t)
+```
+
+以下查询将使用最新值缓存优化：
+
+```dolphindb
+select [HINT_EXPLAIN] * from pt1 where deviceId in [200, 201, 202]
+context by deviceId, key1 csort date
+limit -1
+// HINT_EXPLAIN 输出
+{
+    .......
+    "lastQuery": {
+        "optimizationMethod": LatestKeyCache
+    },
+    ......
+}
+```
+
+以下查询将使用最新值查询优化：
+
+```dolphindb
+select [HINT_EXPLAIN] * from pt1 where deviceId = 200 and key1 = 200199 
+and date > 2010.12.31
+context by deviceId, key1 csort date
+limit -1
+// HINT_EXPLAIN 输出
+{
+    .......
+    "lastQuery": {
+        "optimizationMethod": LatestKeyQuery
+    },
+    ......
+}
+```
+
+以下查询不会使用存储层的任何优化（过滤条件中包含了非 sortkey
+列）：
+
+```dolphindb
+select [HINT_EXPLAIN] * from pt1 where deviceId = 200
+and val_any = 123
+context by deviceId, key1 csort date
+limit -1
+// HINT_EXPLAIN 输出
+{
+    .......
+    "lastQuery": {
+        "optimizationMethod": None
+    },
+    ......
+}
+```
+
+相关文档：
+
+- [create](../../progr/sql/create.html)
+- [createPartitionedTable](../../funcs/c/createPartitionedTable.html)
+- [schema](../../funcs/s/schema.html)
+- [getSessionMemoryStat](../../funcs/g/getSessionMemoryStat.html)
+- [参数配置](../cfg/function_configuration.html)

package/templates/claude-global/skills//346/225/260/346/215/256/345/272/223/dwy-dolphindb/references/official/db_distr_comp/db/limits.md

@@ -0,0 +1,40 @@
+---
+source_url: https://docs.dolphindb.cn/zh/db_distr_comp/db/limits.html
+fetched_at: 2026-05-19T09:04:53Z
+category: db_distr_comp
+title: 使用限制
+sha1: 0d2e697960efe3df9c19a26c8cb6311bb3536ef5
+---
+
+# 使用限制
+
+本节介绍 DolphinDB 的常见使用限制，包括用户与权限管理、网络连接、数据库对象、数据类型、查询事务以及系统资源等方面的数量和大小限制。
+
+| 限制项 | 上限 |
+| --- | --- |
+| 用户（User）数量 | 无 |
+| 用户组（Group）数量 | 无 |
+| 同一用户组内的用户数量 | 无 |
+| 网络连接数 | 取决于配置项 *maxConnections*（如果调用 `setMaxConnections` 动态修改，上限为 65,536） |
+| 单个会话（Session）内变量（Variable）的数量 | 无 |
+| 共享（shared）变量的数量 | 65,536 |
+| 函数视图（FunctionView）数量 | 无 |
+| 定时任务（scheduleJob）数量 | 无 |
+| 数据库数量 | 无 |
+| 表数量 | 无 |
+| 组合分区（COMPO）的层级数 | 3 |
+| 分区个数 | 无 |
+| 分区内行数 | 2,147,483,648 |
+| 表行数 | 内存表：2,147,483,648  分布式表：无 |
+| 表列数 | 无 |
+| STRING 类型长度 | 分布式表：65,536 字节（64KB）  OLTP 引擎表：若作为索引字段，限制 4,096 字节  内存表：无 |
+| BLOB 类型长度 | 分布式表：67,108,864 字节（64MB）  其它：无 |
+| SYMBOL 类型长度 | 分布式表：256 字节  其它：无 |
+| 单个分区 SYMBOL 列不同值的数量 | 2,097,152 |
+| 单个 SQL 查询的结果大小 | 分布式表：总内存的 80%  其它：无 |
+| 单个 SQL 查询涉及的分区数 | 取决于配置项 *maxPartitionNumPerQuery* |
+| 单个事务允许执行的时间 | 无 |
+| 单个查询允许执行的时间 | 无 |
+| 可用内存大小 | 由 license 、物理内存和配置项 *maxMemSize* 限制 |
+| 可用 CPU 核数 | 由 license、物理 CPU 核数和配置项*workerNum* 限制 |
+| 集群包含的节点数量 | 由 license 限制 |

package/templates/claude-global/skills//346/225/260/346/215/256/345/272/223/dwy-dolphindb/references/official/db_distr_comp/db/multimodal_storage.md

@@ -0,0 +1,65 @@
+---
+source_url: https://docs.dolphindb.cn/zh/db_distr_comp/db/multimodal_storage.html
+fetched_at: 2026-05-19T09:04:40Z
+category: db_distr_comp
+title: 多模态存储
+sha1: 88e6928aa6a888cc1e759a20d1ab0df4e7bdb49d
+---
+
+# 多模态存储
+
+多模态存储是指一个系统可以同时支持多种不同的存储引擎，每种引擎共享同一个数据库架构，但技术实现存在差异。DolphinDB
+在架构设计上充分考虑了多模态存储的需求，提供了多种存储引擎，实现了对不同类型数据的存储和管理。这种设计更好地满足了复杂业务场景对数据管理的需求，能够适应金融、物联网等不同需求的应用场景，为用户提供了一个统一、高效的数据管理解决方案。
+
+## 多模态架构
+
+DolphinDB
+多模态架构如图所示。它由多个层次组成，其中存储引擎层作为系统的独立分层，负责提供数据库和表的创建与删除接口。针对不同业务场景，各种引擎在存储结构和索引设计上有所不同，但均遵循统一标准来实现写入和读取接口。而在其他层次，DolphinDB
+实现了多模态数据库的“三个统一”：
+
+**统一的数据库查询语言**：查询层提供编译器和解析器，支持多种编程语言，包括 DolphinScript（包括 SQL 92
+标准语法）、Python。这种统一性使得用户可以根据自身需求灵活选择编程语言，而无需担心存储引擎的差异。
+
+**统一的分布式计算框架**：计算层实现了分布式计算的抽象通用功能，包括通用算子和执行优化、向量化等优化计算功能。这一层的设计不区分存储引擎的类型，可以确保任何计算任务都能够高效地利用计算资源，提高整体性能。
+
+**统一的存储管理系统**：存储层负责统一的分布式存储管理，涵盖数据写入、数据分区、副本、分布式事务、负载均衡、数据恢复、元数据、高可用、弹性扩缩容等功能。它通过统一的接口，可以对不同存储引擎中的数据进行读取调度，从而简化了数据管理的复杂性。
+
+  
+![](images/multimodal_new_1.png)
+
+## 存储引擎
+
+在 DolphinDB
+中，新增一个引擎只需在存储引擎层实现必要功能，并复用其他层的基础功能，这使得扩展存储引擎变得更简单高效。在存储引擎层实现存储结构和接口。其中，对于存储结构，需要根据引擎所需实现的业务特征，设计合适的存储结构，包括索引实现和数据存储文件的具体结构。而对于接口，存储引擎提供统一的表和向量写入和读取接口，使
+SQL 引擎能够无感知于存储引擎的细节，从而降低模块间的耦合度。SQL
+引擎关注数据库中表和列的结构与数据，而计算引擎则将表的一列视为一个向量。两者并不关心具体的数据存储方式或底层实现，这些由存储引擎负责。不同存储引擎实现数据存储的方式不同。例如：TSDB
+引擎在一个分区中的一列，实际上是由多个 Block 组成的逻辑上连续，物理上分散的向量。而 OLAP 引擎在一个分区中的一列，是一个物理上连续的向量。
+
+此外，分布式存储管理系统负责将数据分散存储在多个物理或虚拟节点上，并提供数据访问和管理功能。存储引擎则负责单个分区的数据写入和读取、索引创建和解压缩等任务。写入数据时，存储引擎提供写入接口，将一个分区的数据写入一个内存表。分布式存储管理系统告知存储引擎分区的存储位置，最终将内存表数据持久化到指定位置的文件中。在查询数据时，存储引擎提供读取接口，从分布式存储管理系统指定的分区位置读取数据，每次返回一个分区的数据给计算引擎。
+
+目前，DolphinDB 支持以下存储引擎：TSDB, OLAP, PKEY, IMOLTP, VectorDB, TextDB。除 IMOLTP
+外，其它引擎均采用数据分区技术，按照给定规则将大规模数据集水平分区，基于同一个分布式存储管理系统，实现数据在各个数据节点上的均匀分布。不同的存储引擎分别针对不同的应用场景而设计，在存储结构、支持的数据形式和类型、索引机制等方面存在区别。
+
+- TSDB：行列混存，采用 LSM-Tree 数据结构，支持通过 *sortColumns*
+  参数设置稀疏索引，支持数据去重，除基础的数据类型外，还支持 array vector、columnar tuple、BLOB 类型。更多介绍见[TSDB 存储引擎](tsdb.html)。
+- OLAP：列式存储，一个分区内的一列数据存储在一个文件上。它是架构最简单的存储引擎，仅支持基础的数据类型，不支持 array
+  vector、columnar tuple、BLOB 类型，不支持索引和数据去重。更多介绍见[OLAP 存储引擎](olap.html)。
+- PKEY：列式存储，采用 LSM-Tree 数据结构，支持设置主键，支持为非主键列设置索引，数据类型支持性同
+  TSDB、支持数据去重。更多介绍见[主键存储引擎](pkey_engine.html)。
+- IMOLTP：所有数据存储在内存中，行式存储，索引采用 B+ Tree
+  数据结构，支持主键索引和二级索引，仅支持有限的数据类型（时间类型、整数类型、浮点数、字符串）。
+- VECTORDB：基于 TSDB 设计，存储结构和数据类型支持性都和 TSDB
+  一致。支持为指定列设置向量索引。更多介绍见[向量存储引擎](vectordb.html)。
+- TextDB 基于 PKEY 设计，支持文本索引构建和存储，高效检索文本数据。更多介绍见[文本存储引擎](textdb.html)。
+
+在实际使用中，需要根据实际业务需求来选择合适的存储引擎。在 DolphinDB 中选择引擎的方式简单灵活，只需要在创建数据库时，通过 [database](../../funcs/d/database.html) 函数的 *engine*
+参数指定存储引擎即可。可以同时创建多个不同引擎下的数据库，但每个数据库只能使用一种引擎。用户参考下面存储引擎的适用场景，根据业务需求进行合理设置。
+
+| 存储引擎 | 适用场景 |
+| --- | --- |
+| TSDB | 兼顾了 OLAP 的分析和 PKEY 的高效查询性能，适用于大多数时序数据处理场景。 |
+| OLAP | 适合扫描分析大量数据等场景，如：查询所有股票在某个时间段内的交易量等。 |
+| PKEY | 在支持主键的同时，需要实时更新和高效查询的场景，如从 OLTP 数据库的主键表 CDC 到 DolphinDB 中进行数据分析。 |
+| IMOLTP | 高并发、低延迟的在线事务处理场景，如金融行业的交易系统等。由于它是内存数据库，要求数据集大小在内存容量范围内。 |
+| VECTORDB | 海量数据的高效检索和快速响应的场景，如搜索引擎（如 Elasticsearch）和 AI 生成模型等。 |
+| TextDB | 金融领域实现市场情绪分析、信息过滤与处理等；物联网领域管理海量日志数据、进行实时搜索与分析等。 |

package/templates/claude-global/skills//346/225/260/346/215/256/345/272/223/dwy-dolphindb/references/official/db_distr_comp/db/olap.md

@@ -0,0 +1,107 @@
+---
+source_url: https://docs.dolphindb.cn/zh/db_distr_comp/db/olap.html
+fetched_at: 2026-05-19T09:04:45Z
+category: db_distr_comp
+title: OLAP 存储引擎
+sha1: 7f0a0c36a92f68ba63e2e399ade0768333a8709f
+---
+
+# OLAP 存储引擎
+
+在 OLAP 场景中，通常需要执行大规模的聚合和分析操作。为了应对这种需求，DolphinDB OLAP
+引擎采用了数据分区技术，按照指定规则将大规模数据集水平分割成多个分区，并在每个分区内采用列式存储的方式来存储数据。这种分区式存储策略允许我们只读取所需的列数据，从而减少不必要的
+I/O 操作，显著提高了查询速度。
+
+  
+![images](../../images/db_distr_comp/OLAP%20%E5%BC%95%E6%93%8E%E6%9E%B6%E6%9E%84%E5%9B%BE.png)
+
+## 存储结构
+
+OLAP 存储如下图所示，同一列的数据按表中的顺序连续地存放在一起，表的每列构成一个长数组。
+![](../../images/db_distr_comp/OLAP_file.png)
+
+OLAP
+引擎将数据表中的每个分区中的每列都存储在一个单独的数据文件中。数据以追加的方式存储到相应的列文件中，因此，数据写入的顺序决定了它们的存储顺序。这种存储方式使得对于每个分区中的每一列数据的查询和分析都可以快速高效地进行。同时，由于每个分区都有其独立的存储空间，因此在进行数据操作时可以充分利用系统的并行处理能力，进一步提高数据处理速度。
+
+## 数据压缩
+
+OLAP 支持无损压缩，提供了如下可选的压缩算法（通过建表的选项 *compressMethods* 配置）：
+
+- 若不指定，默认采用 LZ4 压缩算法，适用于一般情况。LZ4 主要针对重复字符进行压缩，压缩率与数据重复频率相关。如果同一列中有较多重复项，LZ4
+  算法可以获得较高的压缩速度。但相对于 Delta（delta-of-delta encoding） 压缩算法，压缩率提升可能不太明显。
+- zstd 压缩算法：zstd 适用于几乎所有数据类型，其压缩比高于 LZ4，但解压缩速度较 LZ4 慢约1倍。
+- 对于时间类型或者变化较小的整型数据，建议采用 Delta（delta-of-delta encoding） 压缩算法。Delta
+  是专门针对时间戳等连续且等间隔的数据提出的算法，能够极大降低时间戳的存储空间，因此特别适合时间列的压缩。
+- chimp 压缩算法：在处理小数部分长度不超过三位的 DOUBLE 类型数据时，chimp 具有很高的压缩率及优越的压缩和解压效率。
+- 对于重复较高的字符串，可采用 SYMBOL 类型存储。系统对 SYMBOL 类型数据会使用字典编码，将字符串转化为整型，减少字符串的存储空间。
+
+在现实场景下，金融数据存盘的压缩率一般可达到 20% 到 30% 左右。OLAP
+采用增量压缩策略，每次只对新增数据进行压缩，因此批量写入有助于提升压缩效果。若每次仅写入一行记录，且 Cache Engine
+未开启，则存于磁盘的数据不会进行压缩。
+
+## 数据写入
+
+通用场景下，数据写入后会直接刷盘，若每次进行小批量写入会极大影响磁盘 I/O 性能以及压缩效果。为此，OLAP 维护了一个 Cache
+Engine，以实现数据缓存后批量写入的功能。Cache Engine 是 DolphinDB
+中的一种数据写入缓存机制，对一个文件进行写入时，写入1行数据和写入1000行数据的时间基本相等，大部分时间都花在打开和关闭文件上；因此，如果把多次少量的写入缓存起来，在一次文件
+IO 中批量写入，那么就可以节省许多对文件进行打开和关闭带来的时间开销，从而在整体上提升系统的写入性能。
+
+OLAP 引擎可以通过配置参数 OLAPCacheEngineSize 开启或关闭 Cache Engine。写入缓存功能必须与 Redo Log 配合使用，即开启
+Cache Engine 时必须指定 dataSync=1。 当缓存中的数据量达到阈值（OLAPCacheEngineSize
+的30%）时，系统才会将数据写入磁盘，这样避免了频繁的磁盘操作。
+
+OLAP 引擎写入操作支持事务，具备事务 ACID 特性，且通过 MVCC 实现快照隔离级别。
+
+**写入流程如下：**
+
+1. **写 Redo：**先将数据写入 OLAP Redo Log。
+2. **写 Cache Engine：**写 Redo Log 的同时，将数据写入 OLAP Cache Engine。
+3. **写磁盘：**若某写事务到来时，Cache Engine 中的数据累计达到了 *OLAPCacheEngineSize* \* 30%
+   时，系统将进行一次刷盘操作，把数据以追加的方式写入分区中的列文件。
+
+## 数据查询
+
+OLAP 引擎将每列数据存储为一个列文件，所以读取数据时，需要从磁盘读取该列所在的分区，解压后加载到内存。
+
+具体流程如下：
+
+1. 根据查询语句进行分区剪枝，缩窄查询范围。
+2. 将 where 语句过滤条件中包含的列的数据文件读到内存，并进行过滤。
+3. 根据过滤出的列数据，读出其对应的其他列的数据。
+
+这种数据读取方式使得 OLAP 引擎在高吞吐量查询情况下拥有较好的性能。 但若需要更新或删除某条数据，OLAP
+会将整个分区数据加载到内存中，再对这条数据进行更新或删除，因此性能开销大。
+
+## 数据更新
+
+OLAP 引擎更新操作支持事务，具备事务 ACID 特性，且通过 MVCC
+实现快照隔离级别。每次更新，系统都会读出对应分区中相关的列文件，在内存中进行更新，同时创建一个新的版本以存储新的数据。整个过程通过事务来确保数据一致性，并通过 MVCC
+保证读取的一致性，对于未变化的列，采用创建硬链接的方式，以提升性能并降低不必要的数据读写。在提交事务之前，其他 SQL
+语句仍然访问旧版本的数据，直到更新事务完成。若更新操作涉及多个分区，只要其中某一个分区更新失败，系统会回滚所有分区的修改。
+
+针对不同的数据更新需求，DolphinDB 提供3种更新表的方法：
+
+- update：ANSI SQL 92 的update语法
+- sqlUpdate：动态生成 SQL update 语句的元代码。
+- upsert!：用于更新键值内存表、索引内存表或分布式表。进行更新时，若新数据的主键值已存在，则更新该主键值的数据；否则添加数据。
+
+## 数据删除
+
+对于 OLAP 引擎的数据删除操作，其流程与更新操作一致，即按分区读取所有数据，执行删除操作后写入一个新版本的目录。整个过程同样通过事务保证数据一致性，并通过 MVCC
+保证读取一致性。若删除操作涉及多个分区，只要其中某一个分区删除失败，系统会回滚所有分区的修改。
+
+针对不同的数据删除需求，DolphinDB 提供以下方法删除数据：
+
+- dropPartition：删除整个分区的数据，默认保留分区结构，也可通过参数设置不保留分区结构。
+- delete：删除数据，保留分区结构。
+- sqlDelete：动态生成 SQL delete 语句。
+- dropTable：删除整个表的数据，不保留表结构。
+- truncate：删除整个表的数据，保留表结构。
+
+## OLAP引擎特点
+
+- 数据在表中的存储顺序与数据写入的顺序一致，数据写入非常高效。
+- OLAP 的存储结构决定了它很适合读取整个分区数据或分区的某几列数据的场景。
+- 适合扫描分析大量数据、全表扫描等场景，如：查询所有股票在某个时间段内的交易量等。
+- 写入过程设计简单，不支持去重。
+- 不适合几百几千列的宽表存储。