摘要下午开始弄的。手头就一台 2 核 1.9 GiB 的腾讯云轻量服务器平时跑博客这次拿来当测试机。金仓 V9R1C10 的镜像 731 MB从官方 OSS 拉头一回还被防盗链拦了加上 Referer 才下来。docker load然后docker runksql 就通了版本 V009R001C010。后来建了张 1 万行的订单表试了试 ROWNUM、序列、VARCHAR2、NUMBER 这些 Oracle 常用的东西都能跑就 DBMS_RANDOM 默认没装。最后 EXPLAIN ANALYZE 对比了一下分组聚合没索引 6.966 ms加了索引 2.104 ms。过程记录在下面。一、为什么要写这篇我平时用的是 MySQL 和 PostgreSQL金仓只听说过没碰过。征文活动开了正好借这个机会把 V9R1C10 拉起来跑跑。手头这台机器内存不大金仓起来后常驻六七百兆剩下的地方不多。机器小也有小的好处坑藏不住踩到就是踩到写出来大家少走弯路。二、装的时候翻了翻容器镜像加载完我进容器看了看目录。/home/kingbase下面install里是金仓的二进制ksql 也在那儿userdata是挂出来的数据卷后面建库就落在它上面。宿主机这边Docker 把 54321 端口映射进容器数据卷对应宿主的/opt/kingbase/data。Oracle 兼容模式是开着的后面建表我就按 Oracle 的习惯写了。三、这趟一共七件事环境确认、拉镜像、加载镜像、启动容器、连库看版本、建演示表、索引前后对比就这七件挨着来。每件做完我截一张图再写两句看到了什么。场景做什么关键命令图场景一确认机器能不能跑uname、os-release、lscpu、free、docker --version图 2场景二拉镜像并校验curlmd5sum图 3场景三加载镜像docker loaddocker tag图 4场景四启动容器挂数据卷mkdir datadocker rundocker ps图 5场景五连库看版本ksql -VSELECT version() 库列表图 6场景六建订单表验证 Oracle 兼容CREATE SCHEMA/TABLE/SEQUENCE INSERT ROWNUM 查询图 7场景七索引前后性能对比EXPLAIN ANALYZE CREATE INDEX 计时图 8场景一先看看机器uname -a、docker --version各来一遍看机器状态。free -h出来 1.9 GiB我心里嘀咕了一下这内存跑 V9R1C10 行不行。真跑起来常驻 700 MiB 上下加上系统和 Docker小 1 GiB 没了剩下的给系统缓冲。能用就是别再同时开别的重容器了。场景二拉镜像头一回被拦curl拉官方 OSS 上的 V9R1C10 镜像 tar 包第一次直接 403错误页写着You are denied by bucket referer policy。金仓的 OSS 开了防盗链不带 Referer 头就不给下。加上Referer: https://www.kingbase.com.cn/再拉通了。md5sum算出来26bb99891becc52f533488aac5fabfb6我留了个记录下次下载完先验一下省得文件坏了到docker load才发现。场景三镜像名太长加载完的镜像叫kingbase_v009r001c010b0004_single_x86:v1这一长串每次敲docker run都费劲。我docker tag成了kingbase:v1。docker images里两个名字都在image id 是同一个。原来的 tag 我没删留着以后查版本号方便也不占什么。场景四ksql 连不上慌了这一步最折腾。命令先放这数据卷建好、chown 完docker ps看到Up 5 seconds我还挺高兴。接着docker exec kingbase ksql ...第一次连就报错ksql: error: could not connect to server: FATAL: could not open file global/sys_filenode.map: Permission denieddocker logs kingbase里 initdb 是成功的server started 也打了ksql 就是连不上。我坐那想了半天。后来反应过来宿主机上这个数据卷 chown 成了 1001:1001是 lighthouse 用户的可容器里 kingbase 用户 uid 是 1000。两边对不上700 权限的目录ksql 读不了。修复就一行sudo chown -R 1000:1000 /opt/kingbase/data sudo docker restart kingbase。再连通了。这个教训我记下了下次先查容器里用户的 uid再对着 chown。场景五ksql 通了ksql -VKingbaseES V009R001C010跟镜像标签对得上。SELECT version();也是 V009R001C010。库列表 5 个test、kingbase、template1、template0、security跟 PostgreSQL 差不多。有个细节ksql 的真实路径是/home/kingbase/install/kingbase/bin/ksql中间带install/。我一开始照文档找kingbase/bin扑了个空折腾了一会儿才发现。场景六演示表通了DBMS_RANDOM 翻车建订单演示表demo.t_order字段按 Oracle 习惯NUMBER(10,2)、VARCHAR2(64)、CHAR(1)、TIMESTAMP DEFAULT SYSTIMESTAMP。第一次 INSERT我照着 Oracle 的写法抄了个用DBMS_RANDOM.VALUE生成金额INSERT INTO demo.t_order SELECT 10000g, 客户||LPAD(g,5,0), ROUND(DBMS_RANDOM.VALUE(50,5000),2), ...报错schema or package dbms_random does not exist。V9R1C10 默认不装这个包得手动加载。我换成 PG 的写法ROUND((random()*495050)::numeric,2)就过了。1 万行灌进去SELECT … WHERE ROWNUM 5拿前 5 条分页正常中文字符串也正常。FETCH FIRST 3 ROWS ONLY这种标准语法直接就能用。Oracle 兼容是真做了功夫但 DBMS_RANDOM 不在默认包里。平时用 Oracle 的同事估计会在这卡一下业务里真依赖的话部署的时候记得手动加载。场景七索引前后的差距性能这块我最上心。EXPLAIN ANALYZE会把规划代价和实际执行时间一起打出来比光看EXPLAIN实在。实测结果1 万行t_order2 vCPU / 1.9 GiB 资源受限环境SQL计划Execution Time实测耗时分组聚合无索引Seq Scan on t_order6.966 ms—分组聚合有索引Bitmap Index Scan on idx_order_statusBitmap Heap Scan2.104 ms—等值查询statusS——4.179 ms含客户端解析加了索引聚合从 6.966 ms 掉到 2.104 ms。status就 N/S 两个值金仓走了Bitmap Index Scan没走 B-Tree跟我猜的一样。机器内存就 1.9 GiB这几万行的表基本都在内存里躺着Seq Scan 本来就快毫秒级的事。3.31 倍这个数看着不算夸张。等哪天表长到几百万行差距就不是一个量级的事了。四、数据汇总维度实测结果出处部署门槛4 步完成单容器资源占用约 600~800 MiB图 3~5Oracle 兼容ROWNUM / 序列 / VARCHAR2 / NUMBER / SYSTIMESTAMP / FETCH FIRST 全部可用DBMS_RANDOM 需手动加载图 7性能起点1 万行 Seq Scan 分组聚合 6.966 ms图 8性能上限同等条件下加索引后 2.104 ms3.31×图 8资源占用实测 1.9 GiB 内存可正常运行 V9R1C10图 2五、写在最后这趟跑下来几件事印象挺深。部署是真省事4 步就起来了比装 Oracle 那个安装包加一堆依赖轻快太多。Oracle 兼容也实打实ROWNUM、序列这些常规的都能跑就 DBMS_RANDOM 要自己装这个坑踩一次就记住了。数据卷权限那个事最曲折看到 Permission denied 我还怀疑过镜像排查下来是 uid 的事下次先把用户查清楚再 chown省得折腾。