当前位置：首页 > news >正文

qKnow本地部署实战：知识图谱构建的可控性与工程落地

news 2026/7/8 19:17:58

1. qKnow 是什么，为什么需要本地部署

qKnow 是一个面向知识图谱构建与推理的开源项目，它不是传统意义上的“问答系统”或“搜索引擎”，而更像一个轻量级、可插拔的知识工程工作台。它的核心价值在于把非结构化文本（比如科研论文摘要、产品说明书、内部技术文档）自动抽取出实体、关系和属性，再落地为图数据库中的节点与边，最终支撑语义检索、关系推理、影响分析等高阶应用。我第一次接触它是在帮一家医疗器械公司梳理产品合规文档时——他们有上百份PDF格式的ISO 13485认证材料，人工标注实体耗时两周且漏标率超35%；换成qKnow跑通本地流程后，单次处理200页PDF仅需6分17秒，实体识别F1值达0.89，关系抽取准确率稳定在82%以上。

之所以强调“本地部署”，是因为qKnow的设计哲学非常务实：它默认不依赖任何云服务或SaaS API，所有NLP模型（基于DeepKE框架）、图谱存储（Neo4j）、结构化数据中转（MySQL）全部运行在你自己的机器上。这意味着三点硬性优势：第一，敏感数据不出内网——医疗记录、专利原文、未公开的供应链信息，全程不触网；第二，推理延迟可控——没有网络抖动、API限流、跨区域DNS解析这些不可控因素，端到端响应稳定在300ms以内；第三，调试自由度高——你可以直接进容器改配置、调模型阈值、查Neo4j原生日志，而不是对着黑盒API文档猜参数含义。

这和当前很多打着“知识图谱”旗号的低代码平台有本质区别。那些平台往往把DeepKE封装成不可见的后台服务，用户只能上传文件、点按钮、看结果，一旦关系抽取错乱，连日志都看不到。而qKnow本地部署后，你手握整条链路的控制权：从MySQL里查原始文本切片，到Neo4j浏览器里验证节点是否被正确合并，再到DeepKE输出的JSONL中间文件里定位某条关系为何被过滤——这种颗粒度的可观测性，是生产环境稳定运行的底线保障。尤其当你要对接ERP、PLM这类企业级系统时，本地部署不是“可选项”，而是唯一能保证数据主权、审计合规和故障归因的路径。

提示：qKnow对硬件要求其实很友好。我在一台i5-8250U + 16GB内存 + 512GB SSD的旧笔记本上实测过全链路运行，只要关闭Neo4j的页面缓存（dbms.memory.pagecache.size=512m），MySQL调低InnoDB缓冲池（innodb_buffer_pool_size=512M），整个栈常驻内存可压到2.3GB以内。这说明它并非为“大厂级”算力设计，而是真正面向中小团队、个人研究者、甚至学生课程设计的落地工具。

2. 部署前必须厘清的四个技术锚点

很多人卡在第一步，不是因为命令敲错了，而是没想清楚qKnow这条流水线里每个组件到底承担什么角色、彼此间如何咬合。我把它们拆解成四个不可妥协的技术锚点，每个锚点都对应一个“为什么必须这样”的底层逻辑。

2.1 DeepKE 不是黑盒模型，而是可干预的抽取引擎

DeepKE在这里不是拿来即用的API，而是作为qKnow的子模块深度集成的。它的配置文件deepke/config.yaml里藏着三个关键开关：ner_model（命名实体识别模型）、re_model（关系抽取模型）、preprocess（预处理规则）。比如你处理的是法律合同，就要把ner_model从默认的bert_base_chinese换成lawbert微调版；如果要提取“甲方支付乙方违约金”的关系，就得在re_model的relation_schema.json里明确定义{"subject_type": "party", "object_type": "money", "predicate": "pay_liquidated_damages"}。这解释了为什么官方Docker镜像不直接打包训练好的模型——不同行业领域的实体定义、关系范式、术语边界差异太大，强行统一反而降低准确率。

2.2 MySQL 承担“文本中转站”而非“图谱存储”

这是最容易误解的一点。MySQL在qKnow里不存图结构，它只存三类东西：原始文档元数据（文件名、上传时间、hash值）、文本切片（按段落/句子切分后的纯文本块）、以及DeepKE抽取的原始三元组（subject, predicate, object, confidence_score）。所有这些数据都是扁平化的、无索引优化的临时表。它的存在意义只有一个：给DeepKE提供稳定的输入源，并让qKnow后端能快速回溯某条关系来自哪段原文。所以你完全不需要给MySQL配SSD、开并行查询、建复杂索引——我实测过，即使MySQL用默认配置跑在HDD上，qKnow整体吞吐量只下降7%，因为瓶颈从来不在这里。

2.3 Neo4j 是图谱的“唯一真相源”，但必须禁用默认安全策略

Neo4j在qKnow架构里是真正的图谱心脏。所有MySQL里的三元组，最终都要通过qKnow的graph_importer.py脚本转换成Cypher语句写入Neo4j。这里有个致命陷阱：Neo4j社区版默认开启dbms.security.auth_enabled=true，而qKnow的导入脚本硬编码了neo4j:password这个凭据。如果你没在neo4j.conf里显式关闭认证（dbms.security.auth_enabled=false），或者没把密码改成password，导入过程会静默失败——日志里只显示Connection refused，根本不会提示是认证问题。我踩过这个坑，在Ubuntu 22.04上重装三次Neo4j才定位到，后来干脆在docker-compose.yml里加了初始化脚本：echo "dbms.security.auth_enabled=false" >> /var/lib/neo4j/conf/neo4j.conf。

2.4 Docker Compose 不是“一键部署”，而是状态编排契约

docker-compose.yml对qKnow而言，不是简单的容器启动清单，而是一份服务依赖契约。它强制规定了启动顺序：MySQL必须先于DeepKE就绪（否则DeepKE启动时连不上数据库报错退出），DeepKE又必须先于qKnow主服务就绪（否则主服务初始化时找不到抽取服务）。这个契约通过depends_on+healthcheck实现，但很多人忽略了一个细节：healthcheck的interval不能设得太短。我最初设成10s，结果MySQL容器刚启动就触发健康检查，返回mysqladmin ping失败，导致Compose误判服务异常并反复重启。后来调到30s，配合start_period: 120s，才让MySQL有足够时间完成初始化（包括创建qKnow专用数据库、导入初始schema）。

这四个锚点环环相扣。比如你改了DeepKE的模型，就必须同步更新MySQL里document_slices表的processed_status字段逻辑；你调低Neo4j内存，就得相应减少qKnow并发导入线程数，否则OOM Killer会干掉Neo4j进程。本地部署的本质，就是亲手把这四个齿轮严丝合缝地咬在一起。

3. 从零开始的完整部署实操（Ubuntu 22.04 实测）

下面是我用一台全新安装的Ubuntu 22.04服务器（4核CPU/16GB内存/500GB SSD）从零搭建qKnow的完整过程。所有命令均经过逐行验证，路径、权限、配置项全部按生产环境标准设置，不是“能跑就行”的玩具配置。

3.1 环境准备：Docker与Compose的精准安装

Ubuntu官方仓库的Docker包版本太老（20.10），而qKnow依赖Docker 23.0+的--platform参数来拉取ARM64兼容镜像。必须用Docker官方源安装：

# 卸载旧版Docker（如有） sudo apt-get remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release # 添加Docker官方GPG密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加稳定版仓库 echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 验证安装 sudo docker run hello-world

重点来了：Docker Compose Plugin（v2.20+）和旧版独立二进制（v1.x）行为差异极大。qKnow的docker-compose.yml里用了profiles特性，这在v1.x里根本不支持。执行docker compose version确认输出类似Docker Compose version v2.21.0。如果显示command not found，说明Plugin没装好，别去下独立二进制，直接重装docker-compose-plugin包。

3.2 创建部署目录与基础配置

新建一个隔离的部署目录，避免污染系统路径：

mkdir -p ~/qknow-deploy/{config,logs,volumes/{mysql,neo4j}} cd ~/qknow-deploy

创建docker-compose.yml，这是整个部署的核心蓝图。注意以下关键细节：

mysql服务的volumes挂载点必须是绝对路径，相对路径在某些Docker版本下会失效；
neo4j的NEO4J_dbms_memory_pagecache_size环境变量必须显式设置，否则默认2G会吃光内存；
qknow-app的restart: always不是为了“服务永生”，而是防止DeepKE模型加载失败时自动重试（首次加载模型需3-5分钟）；
所有服务的network_mode: "bridge"确保它们在同一个Docker网络内互通，避免用host模式引发端口冲突。

# docker-compose.yml version: '3.8' services: mysql: image: mysql:8.0.33 container_name: qknow-mysql restart: always environment: MYSQL_ROOT_PASSWORD: rootpass123 MYSQL_DATABASE: qknow_db MYSQL_USER: qknow_user MYSQL_PASSWORD: qknow_pass volumes: - /home/ubuntu/qknow-deploy/volumes/mysql:/var/lib/mysql - /home/ubuntu/qknow-deploy/config/mysql.cnf:/etc/mysql/conf.d/mysql.cnf ports: - "3306:3306" healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-prootpass123"] interval: 30s timeout: 10s retries: 5 start_period: 120s neo4j: image: neo4j:5.14.0 container_name: qknow-neo4j restart: always environment: NEO4J_AUTH: none NEO4J_dbms_memory_pagecache_size: 1024m NEO4J_dbms_connectors_default__listen__address: 0.0.0.0:7687 NEO4J_dbms_connector_bolt_tls__enabled: false NEO4J_dbms_security_auth__enabled: "false" volumes: - /home/ubuntu/qknow-deploy/volumes/neo4j:/data - /home/ubuntu/qknow-deploy/config/neo4j.conf:/var/lib/neo4j/conf/neo4j.conf ports: - "7474:7474" - "7687:7687" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:7474/db/data/"] interval: 30s timeout: 10s retries: 5 start_period: 180s deepke: image: registry.cn-hangzhou.aliyuncs.com/qknow/deepke:1.2.0 container_name: qknow-deepke restart: always volumes: - /home/ubuntu/qknow-deploy/volumes/deepke_models:/app/models - /home/ubuntu/qknow-deploy/config/deepke_config.yaml:/app/config.yaml environment: PYTHONUNBUFFERED: 1 depends_on: mysql: condition: service_healthy qknow-app: image: registry.cn-hangzhou.aliyuncs.com/qknow/qknow:2.1.0 container_name: qknow-main restart: always ports: - "8000:8000" environment: DB_HOST: mysql DB_PORT: "3306" DB_NAME: qknow_db DB_USER: qknow_user DB_PASSWORD: qknow_pass NEO4J_URI: bolt://neo4j:7687 DEEPKE_URL: http://deepke:5000 LOG_LEVEL: INFO volumes: - /home/ubuntu/qknow-deploy/volumes/uploads:/app/uploads - /home/ubuntu/qknow-deploy/logs:/app/logs depends_on: mysql: condition: service_healthy neo4j: condition: service_healthy deepke: condition: service_healthy

3.3 配置文件精细化打磨（避坑核心）

配置文件是部署成败的关键，我逐个说明每个文件的必填项和易错点：

config/mysql.cnf—— 关键是禁用严格模式，否则DeepKE插入含emoji的文本会报错：

[mysqld] sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION" # 必须注释掉下面这行！否则qKnow插入长文本时报错 # sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

config/neo4j.conf—— 除了禁用认证，还要显式开放远程访问：

# 必须关闭认证 dbms.security.auth_enabled=false # 允许外部访问Bolt端口 dbms.connectors.default_listen_address=0.0.0.0 # 设置页面缓存大小（根据内存调整） dbms.memory.pagecache.size=1024m # 开启HTTP连接（Neo4j Browser需要） dbms.connector.http.enabled=true dbms.connector.http.listen_address=:7474

config/deepke_config.yaml—— 这是模型行为的总开关，ner_model和re_model路径必须指向容器内绝对路径：

ner_model: name: bert_base_chinese path: /app/models/bert_base_chinese max_length: 512 re_model: name: casrel path: /app/models/casrel schema_path: /app/models/relation_schema.json preprocess: split_by: "paragraph" # 按段落切分，比按句子更适配技术文档 min_length: 20 # 过滤掉少于20字符的碎片

3.4 启动与首次验证：三步诊断法

执行docker compose up -d后，不要急着打开浏览器。用三步法验证状态：

第一步：查容器健康状态

docker compose ps # 正确输出应类似： # NAME COMMAND SERVICE STATUS PORTS # qknow-deepke "python app.py" deepke running ... # qknow-main "uvicorn main:app..." qknow-app running ... # qknow-mysql "docker-entrypoint.s..." mysql healthy ... # qknow-neo4j "/sbin/tini -g -- /d..." neo4j healthy ... # 如果某个STATUS是"unhealthy"或"restarting"，立刻查日志

第二步：进MySQL查基础表是否存在

docker exec -it qknow-mysql mysql -uqknow_user -pqknow_pass qknow_db -e "SHOW TABLES;" # 应看到至少5张表：document, document_slices, entities, relations, users # 如果报错"Unknown database 'qknow_db'"，说明MySQL初始化失败，查mysql容器日志 docker logs qknow-mysql | grep -i "error\|fail"

第三步：手动触发一次抽取测试

# 向qKnow上传一个测试文件（用curl模拟前端） curl -X POST "http://localhost:8000/api/v1/upload" \ -H "Content-Type: multipart/form-data" \ -F "file=@/home/ubuntu/test.txt" \ -F "filename=test.txt" # 查看qKnow日志，确认DeepKE调用成功 docker logs qknow-main | tail -20 # 正常应看到类似：INFO: DeepKE response: {'status': 'success', 'triples': 12}

这三步走完，才算真正打通了数据链路。我见过太多人跳过验证直接用Web界面，结果上传100份PDF后才发现MySQL里document_slices表全是空的——因为deepke服务根本没连上MySQL，而Compose的restart: always掩盖了这个问题。

4. 常见故障的根因定位与修复（附真实日志）

部署中最折磨人的不是报错，而是“看起来正常却不出结果”。我把过去三个月帮客户解决的高频问题，按发生频率排序，每一条都附上真实日志片段和定位逻辑。

4.1 Neo4j 导入无声失败：Cypher语法陷阱

现象：qKnow Web界面显示“导入成功”，但Neo4j Browser里查不到任何节点，MATCH (n) RETURN count(n)返回0。

日志线索：在qknow-main日志里发现大量WARNING: Graph importer failed for batch 12: Invalid input '}'，但没堆栈。

根因定位：qKnow的graph_importer.py会把MySQL里的三元组拼成Cypher语句，如CREATE (:Person {name: "张三"})。但如果实体名里包含右花括号}，就会破坏语法。我们有个客户上传的PDF里有数学公式E=mc^2}，导致生成的Cypher变成CREATE (:Formula {content: "E=mc^2}"})——右花括号提前闭合了字符串。

修复方案：不是改PDF，而是升级qKnow的导入器。在qknow-app服务的volumes里挂载一个补丁脚本：

# 创建补丁脚本 cat > ~/qknow-deploy/patch/cypher_escape.py << 'EOF' def escape_cypher_string(s): return s.replace('\\', '\\\\').replace('"', '\\"').replace('}', '\\}') EOF

然后修改qknow-app的启动命令，注入这个补丁。实测后，含特殊符号的文档导入成功率从63%升至99.2%。

4.2 DeepKE 模型加载超时：GPU驱动不匹配

现象：qknow-deepke容器反复重启，docker logs qknow-deepke末尾总是Killed。

日志线索：docker stats显示该容器内存使用峰值冲到14GB后被OOM Killer杀死。

根因定位：DeepKE默认启用CUDA，但服务器没装NVIDIA驱动或驱动版本太低（<525）。PyTorch尝试分配显存失败，退回到CPU模式，但BERT模型在CPU上加载需要12GB内存，而容器限制只有8GB。

修复方案：强制禁用CUDA。在docker-compose.yml的deepke服务里加环境变量：

environment: CUDA_VISIBLE_DEVICES: "" PYTORCH_CUDA_ALLOC_CONF: max_split_size_mb:128

同时在deepke_config.yaml里加device: cpu。重启后，模型加载时间从报错变为2分18秒，内存占用压到3.2GB。

4.3 MySQL 连接池耗尽：并发上传卡死

现象：单文件上传正常，但同时上传5个PDF时，qKnow界面卡在“处理中”，MySQL日志里满屏Too many connections。

日志线索：docker exec qknow-mysql mysql -uroot -prootpass123 -e "SHOW STATUS LIKE 'Threads_connected';"返回200+，远超默认151上限。

根因定位：qKnow的database.py里每个请求都新建MySQL连接，没用连接池。5个并发上传触发25个连接，加上DeepKE、后台任务，轻松突破阈值。

修复方案：不是调高MySQL上限（治标），而是打连接池补丁。在qknow-app的volumes里挂载patch/database_pool.py，重写get_db_connection()函数，用SQLAlchemy的QueuePool管理连接，最大连接数设为30。实测后，10并发上传时Threads_connected稳定在28左右，响应时间波动小于5%。

4.4 文件上传失败：Nginx反向代理截断

现象：在qKnow前加了Nginx反向代理后，上传大于1MB的PDF报错413 Request Entity Too Large。

日志线索：Nginx错误日志/var/log/nginx/error.log里有client intended to send too large body。

根因定位：Nginx默认client_max_body_size是1MB，而qKnow允许上传100MB文档。

修复方案：在Nginx配置的location /块里加两行：

client_max_body_size 100M; proxy_buffering off;

注意proxy_buffering off必须加，否则大文件上传时Nginx会先缓存到磁盘再转发，拖慢速度。

这些问题没有一个是“重装一遍就能好”的，必须像侦探一样，从日志蛛丝马迹里还原现场。我建议把docker logs -f命令做成别名，随时盯着关键容器。

5. 生产环境加固与性能调优（非功能需求落地）

部署能跑只是起点，要让它在生产环境扛住压力、防住风险、省下资源，还得做四件事：日志归档、备份策略、资源限流、监控埋点。这些事看似琐碎，但决定了qKnow是“能用”还是“敢用”。

5.1 日志分级归档：用logrotate切割而非rm -rf

qKnow默认日志全打在/app/logs/app.log，不切割的话一个月就占满50GB。但直接rm -f app.log会导致qKnow进程写日志失败（文件句柄丢失）。正确做法是用logrotate：

# 创建logrotate配置 cat > /etc/logrotate.d/qknow << 'EOF' /home/ubuntu/qknow-deploy/logs/*.log { daily missingok rotate 30 compress delaycompress notifempty create 644 ubuntu ubuntu sharedscripts postrotate docker kill -s USR1 qknow-main 2>/dev/null || true endscript } EOF # 测试配置 logrotate -d /etc/logrotate.d/qknow

关键是postrotate里的docker kill -s USR1——这是告诉qKnow主进程重新打开日志文件，而不是粗暴杀进程。我见过有团队用cron每天rm日志，结果某天qKnow正在写日志时被删，进程卡死在write()系统调用上，整个服务不可用。

5.2 MySQL与Neo4j双备份：用docker exec自动化

备份不能只靠mysqldump，因为qKnow的图谱状态是MySQL+Neo4j共同决定的。必须两者同步备份：

# 创建备份脚本 cat > ~/qknow-deploy/backup.sh << 'EOF' #!/bin/bash DATE=$(date +%Y%m%d_%H%M%S) BACKUP_DIR="/home/ubuntu/backups/qknow_$DATE" mkdir -p $BACKUP_DIR # 备份MySQL docker exec qknow-mysql mysqldump -uqknow_user -pqknow_pass qknow_db > $BACKUP_DIR/mysql.sql # 备份Neo4j（用neo4j-admin dump） docker exec qknow-neo4j /var/lib/neo4j/bin/neo4j-admin dump --to=$BACKUP_DIR/neo4j.dump # 压缩并清理旧备份（保留7天） tar -czf $BACKUP_DIR.tar.gz $BACKUP_DIR rm -rf $BACKUP_DIR find /home/ubuntu/backups -name "qknow_*.tar.gz" -mtime +7 -delete EOF chmod +x ~/qknow-deploy/backup.sh # 加入crontab，每天凌晨2点执行 (crontab -l 2>/dev/null; echo "0 2 * * * /home/ubuntu/qknow-deploy/backup.sh") | crontab -

注意neo4j-admin dump必须在Neo4j容器内执行，且要求Neo4j停止服务。但qKnow不能停机备份。解决方案是：在docker-compose.yml里给neo4j服务加command: ["neo4j", "--foreground"]，让它前台运行，然后用docker stop临时停掉再dump——整个过程控制在12秒内，业务无感。

5.3 资源硬限流：用Docker内存/CPU配额防雪崩

qKnow没有内置熔断机制，一旦上传超大PDF或并发过高，可能拖垮整台服务器。必须用Docker层硬限流：

# 在docker-compose.yml的各服务下加 mysql: mem_limit: 2g cpus: "1.5" neo4j: mem_limit: 3g cpus: "2.0" deepke: mem_limit: 4g cpus: "3.0" qknow-app: mem_limit: 2g cpus: "1.0"

实测表明，当deepke内存限制设为4G时，单次处理100页PDF的峰值内存是3.7G，留出300MB余量刚好。如果设成3G，就会触发OOM Killer。这些数字不是拍脑袋，而是用docker stats --no-stream持续监控一周得出的基线。

5.4 Prometheus监控埋点：暴露关键指标

qKnow本身没暴露metrics端点，但我们可以用docker stats+cAdvisor间接监控：

# 启动cAdvisor收集容器指标 docker run -d \ --name=cadvisor \ --restart=always \ -p 8080:8080 \ -v /:/rootfs:ro \ -v /var/run:/var/run:ro \ -v /sys:/sys:ro \ -v /var/lib/docker/:/var/lib/docker:ro \ -v /dev/disk/:/dev/disk:ro \ google/cadvisor:latest # 配置Prometheus抓取cAdvisor # 在prometheus.yml里加： - job_name: 'cadvisor' static_configs: - targets: ['localhost:8080']

然后在Grafana里建看板，重点关注：

container_memory_usage_bytes{name=~"qknow.*"}：各服务内存水位
container_cpu_usage_seconds_total{name=~"qknow.*"}：CPU使用率
rate(container_network_receive_bytes_total{name=~"qknow.*"}[5m])：网络IO

当qknow-deepke内存使用率连续5分钟>90%，就自动发钉钉告警。这套监控上线后，我们提前37分钟捕获了一次DeepKE模型加载泄漏，避免了服务中断。

这些加固措施，让qKnow从“实验室玩具”变成了“生产级工具”。它不再是你个人电脑上的一个Demo，而是能嵌入企业IT流程、经得起审计、扛得住流量的真实基础设施。

6. 我的本地部署经验总结：三个反直觉认知

最后分享我在23个实际部署案例中沉淀下来的三个反直觉认知。它们不是技术细节，而是关于“如何与qKnow共处”的底层心法。

第一个认知：不要追求100%准确率，要追求可解释的错误率。qKnow的DeepKE模型在特定领域（比如电力调度规程）的F1值最高只能到0.92，剩下8%的错误不是模型缺陷，而是领域知识边界。与其花两周调参把准确率提到0.93，不如花半天写个error_analyzer.py脚本，自动把错误样本聚类：比如“所有‘接地’被误识别为设备名”的样本，批量打上type: grounding_issue标签，下次训练时加权重。可解释的8%，比黑盒的92%更有业务价值。

第二个认知：Neo4j的图遍历性能，80%取决于你的Cypher写法，而不是硬件。我见过客户把服务器从16核升到64核，图查询速度只快了12%；但把MATCH (a)-[r]->(b) WHERE a.name CONTAINS '变压器'改成MATCH (a:Equipment {type: 'transformer'})-[r]->(b)，速度提升7倍。qKnow导出的图谱，节点都有type标签，善用它比堆硬件管用得多。

第三个认知：最危险的不是部署失败，而是部署成功后没人维护。qKnow的Docker镜像每月更新，但很多团队部署完就扔在那里。直到某天MySQL 8.0.33的SSL默认策略变更，导致qKnow连不上数据库，而运维人员根本不知道这个服务的存在。我的做法是：在部署完成后，自动生成一份qknow-health-check.md文档，里面包含所有检查命令、预期输出、联系人，然后把它放进公司Confluence的“基础设施”目录，每周自动邮件提醒负责人执行一次docker compose exec qknow-main python health_check.py。

qKnow本地部署，本质上是一场与复杂性的谈判。你无法消灭所有不确定性，但可以把它框定在可观察、可干预、可追溯的范围内。当你能说出“今天Neo4j慢，是因为dbms.memory.pagecache.size设小了，而不是‘图谱太大’”时，你就真正掌控了它。

查看全文

http://www.jsqmd.com/news/1149574/