- 博客(43)
- 收藏
- 关注
RSS订阅原创 一条查询跑了 8 小时，改写后 519 毫秒？金仓子查询等价谓词传递优化深度解析
文章摘要：数据库查询优化中，当外层查询带有WHERE条件而子查询仍全表扫描时，会导致严重性能问题。金仓数据库V9R4C19通过谓词传递优化解决了这一痛点，采用谓词下推和上推策略，将过滤条件在查询树节点间传递。典型案例中，优化使10万次子查询扫描从8小时降至519毫秒，实现数量级提升。该技术让子查询能利用外层常量条件进行索引定位，避免重复全量扫描，开发者无需重写SQL即可获得自动优化，特别适用于包含嵌套子查询的复杂场景。
2026-04-26 22:51:00
345
原创 为什么WHERE中的函数调用会引发灾难？揭秘KES与Oracle的函数执行顺序之谜
文章摘要：在SQL查询的WHERE子句中使用有副作用的函数存在严重风险，这种做法类似于在高速公路上随机变道，可能导致不可预测的后果。作者通过一个实际案例揭示了三个关键问题：依赖函数执行顺序、依赖函数副作用以及假设数据库版本行为一致性。文章对比了Oracle和金仓数据库KES(KES)在处理WHERE子句函数执行顺序上的差异，指出即使KES当前版本保证从左到右执行，这种依赖仍不安全。主要原因包括会话污染、优化器重写风险和函数挥发度影响。最后提出了四种安全解决方案：使用存储过程显式控制执行顺序、参数传递替代全局
2026-04-26 22:50:52
511
原创 为什么DISTINCT加了ROWNUM反而数据变少了？揭秘KES与PG的执行优先级陷阱
摘要：同一SQL在不同数据库（如Oracle/KES与PostgreSQL）中返回不同行数，根源在于执行优先级差异。Oracle/KES的ROWNUM在DISTINCT前过滤（先截取后去重），可能导致结果少于预期；而PostgreSQL的LIMIT作用于最终结果（先去重后截取）。解决方案包括：1）嵌套子查询确保跨库一致；2）明确业务意图选择正确写法；3）使用窗口函数精确控制执行顺序。建议避免直接混用DISTINCT与ROWNUM，优先采用语义清晰的窗口函数实现需求。（150字）
2026-04-26 22:50:41
379
原创 突破批处理瓶颈：KingbaseES并行DML技术如何榨干多核CPU性能
金仓数据库KES的并行DML技术通过Leader-Worker架构实现高效并行处理，解决传统串行DML单核性能瓶颈问题。其GMQ模式支持全流程并行，包括查询、写入和索引维护，相比串行模式最高提升74%性能。关键调优包括开启并行开关、优化WAL参数、使用Hint控制并行度，并规避触发器等并行限制因素。测试显示，2.6亿行数据插入从8分钟降至2分钟，CPU利用率显著提高。KES PDML技术在不升级硬件前提下，为企业跑批业务提供高性能解决方案。
2026-04-26 22:50:24
637
原创 逻辑删除不等于物理销毁：KingbaseES敏感数据标记与销毁实操指南
数据库逻辑删除不等于物理销毁，DROPTABLE后数据仍可恢复，存在合规风险。金仓数据库KingbaseESV9提供"敏感数据销毁"功能，通过标记对象+多次覆盖擦除，彻底销毁敏感数据。支持多种对象类型，可配置覆写次数（1-7次），满足不同安全需求。销毁过程产生额外I/O开销，需避开业务高峰。该功能从物理层面确保数据不可恢复，符合等保2.0、GDPR等法规要求，是数据生命周期管理的必要安全措施。
2026-04-24 13:57:23
316
原创 警惕(+)语法误用：WHERE子句与ON子句位置如何改变连接结果
Oracle迁移到金仓数据库时，使用(+)语法编写的LEFT JOIN可能会被优化器误转为INNER JOIN，导致结果集缺失。关键问题在于：当外连接条件中非空侧表的过滤条件未加(+)标记时，会触发"外连接消除"机制。例如"t2.name2='cc'"未加(+)，该条件会被视为连接后的WHERE过滤而非连接条件，最终导致LEFT JOIN被转为INNER JOIN。建议迁移时逐步将(+)语法改写为标准ANSI JOIN语法，明确区分连接条件和过滤条件，避免语义歧义。数
2026-04-24 13:55:33
261
原创 还在用 root 装数据库、可逆加密存密码？金仓 V9R4C19 安全能力解读：从部署到数据的全链路防护
摘要：金仓数据库V9R4C19版本针对常见安全隐患进行了两项关键安全加固：1）禁止root用户安装和运维数据库，强制采用专用账号以符合最小权限原则；2）引入hashbytes单向哈希函数替代可逆加密存储敏感数据。这两项改进分别从系统层（部署安全）和数据层（数据安全）构建防护体系，有效隔离风险并满足等保2.0要求。其中hashbytes支持多种哈希算法，特别推荐SHA2_256/SHA2_512用于密码等敏感信息存储，从根本上杜绝密钥泄露导致数据全暴露的风险。
2026-04-24 13:54:15
408
原创 风险早看透：KingbaseES SQL防火墙如何用白名单机制阻断SQL注入
金仓数据库推出SQL防火墙功能，从内核层面防范SQL注入攻击。该功能通过三种模式实现防护：学习模式自动记录合法SQL形成白名单，警告模式仅记录异常SQL，报错模式直接拦截非法请求。相比传统预编译方案，SQL防火墙不依赖应用层代码，能100%覆盖所有SQL请求，准确率达99.99%，性能损耗低于6%。其特色在于采用SQL特征值匹配技术，对参数变化不敏感，有效降低误报率。最佳实践建议将预编译与SQL防火墙结合使用，先在测试环境完成学习验证，再逐步切换到生产环境。该方案已在政务、金融、医疗等领域成功应用，为数据库
2026-04-24 13:52:20
370
原创 2TB 数据库增量备份还要 200GB？KES块级永久增量备份，存储省 80%、速度快 60%
摘要：KingbaseES V9R4C19推出的块级永久增量备份技术解决了传统文件级增量备份效率低下的问题。该技术以8KB数据块为最小备份粒度，通过ktrack插件跟踪数据块变更，仅备份修改过的数据块，实测在2TB数据库中可节省80%存储空间并提升60%备份速度。支持永久增量备份和异步备份集合并功能，无需周期性全量备份，特别适合TB级数据库和高并发OLTP场景。相比传统方案，该技术显著提升了备份效率和资源利用率。
2026-04-24 13:49:09
377
原创 Oracle替代的“三重悖论”：兼容性越好，你可能越危险
2026年，Oracle替代已步入深水区。兼容性是替代的船票，但不是航行的终点。过度依赖兼容，会让我们在架构债务、性能陷阱和能力停滞的“三重悖论”中越陷越深。只有把兼容作为起点，以真实负载验证为基准，以架构跃迁为目标，我们才能真正跨越“平替”的浅滩，驶向自主可控与持续进化的深蓝。
2026-04-10 16:28:55
364
原创 HTAP替代Oracle RAC：为什么存算分离正在终结“Shared-Everything”时代
Oracle RAC的Shared-Everything，代表了过去集中式架构下追求“单系统解决所有问题”的极致努力。但在应用场景日趋复杂、数据量指数级增长的今天，这种“大一统”的紧耦合已成为创新的阻碍。从争抢到协同：计算与存储解耦，节点间不再为锁和缓存争用内耗。从割裂到融合：一份存储支撑TP与AP，消除数据孤岛与搬运时差。从刚性到弹性：资源按需分配，扩展不再受限。替代Oracle从来不是终点，而是走向架构自由的起点。
2026-04-10 15:37:30
379
原创 银行核心系统选型2026：集中式 vs 分布式，到底怎么选？
银行核心系统的选型，是一场关乎安全、成本与未来的战略决策。对于绝大多数中小银行、省级农信社以及大部分股份制银行的非核心交易系统：集中式数据库凭借其成熟稳定、运维简单、成本可控的优势，依然是首选方案。切莫为了“分布式”而分布式，陷入过度设计的泥潭。对于国有大行、头部股份制银行的核心交易系统：若业务规模确实达到海量数据（>30TB）、超高并发（TPS>10000）的量级，分布式架构是必经之路。但需做好迎接复杂运维挑战的准备。
2026-04-07 17:26:13
446
原创 时序数据库存储引擎解密：LSM-Tree vs B-Tree vs 倒排索引，谁最适合时序场景？
存储引擎作为数据库的“心脏”，其数据结构的选型直接决定了这些能力的天花板。目前主流的存储引擎架构主要有三种：LSM-Tree、B-Tree 和倒排索引。它们各有千秋，究竟谁才是时序场景的“天选之子”？让我们结合技术原理与实测数据一探究竟。
2026-04-07 17:18:41
654
1
原创 ORA-00933兼容错误解决办法
中文含义：SQL命令未正确结束。理解本质：ORA-00933本质是SQL语法错误，需要仔细检查语句结构分场景处理：区分是基础语法错误还是数据库兼容性问题预防为主：建立SQL开发规范，使用代码审查和自动化测试工具有效利用：善用SQL格式化、语法检查等工具迁移有计划：数据库迁移前做好充分的功能验证和性能测试在国产数据库替代Oracle的进程中，遇到ORA-00933错误是正常现象。关键是要建立完善的SQL兼容性处理机制，积累常见问题的解决方案，形成组织的知识库，这样才能确保迁移过程的平稳顺利。
2026-04-03 17:16:26
453
原创 Oracle的CONNECT BY在国产数据库中的实现
兼容性优先：如果使用的是金仓、达梦等高度兼容Oracle的数据库，可优先使用CONNECT BY语法标准SQL优先：在GaussDB、TDSQL等数据库中，建议使用递归CTE，符合SQL标准，可移植性更好性能考虑：递归CTE在复杂查询时可能需要更多优化，合理使用索引和限制条件迁移策略简单层次查询可直接使用数据库的兼容语法复杂层次查询建议重写为递归CTE对性能敏感的场景需要进行充分的测试和优化监控与调优：在生产环境中使用递归查询时，需要注意监控查询性能，防止深度递归导致的性能问题。
2026-04-03 16:58:22
228
原创 告别“sql_mode“噩梦：MySQL 8.0 vs 5.7兼容性全对比与升级避坑指南
MySQL5.7已结束生命周期，升级到8.0时sql_mode变更常导致兼容性问题。本文详解5.7与8.0在sql_mode上的核心差异：8.0移除了NO_AUTO_CREATE_USER等模式，默认启用更严格的校验规则。提供升级避坑指南：检查清理旧配置、处理ONLY_FULL_GROUP_BY报错、修正无效日期值等。建议采用滚动升级策略，先升级从库验证兼容性，确保平滑过渡。通过预先检查和处理这些关键差异点，可有效规避升级过程中的"sql_mode噩梦"。
2026-04-02 17:20:55
552
原创 2026年国产主流时序数据库选型指南
面对错综复杂的产品与技术路线差异，本篇指南旨在帮助企业构建一套多维评估体系，抛开单一指标偏好，以获得最佳的技术投资回报为目标，对业界主流时序数据库进行评估与遴选。在2026年，各主流国产时序数据库，不论是专精的极致性能，还是在多元数据融合的灵活性方面，都展现出独特的技术专长，包括金仓时序数据库、DolphinDB、TDengine、IoTDB、KaiwuDB等，均在各自的优势领域内发挥着重要作用，为不同应用场景提供技术支撑。但是，我们处理的是纯粹的时间标量呢，还是需要连接业务逻辑的多维变量？
2026-01-16 17:26:43
799
原创 2026年国产时序数据库盘点：格局嬗变下的多模态融合新锐
进入2026年，在“数字中国”与工业物联网浪潮的强劲推动下，国产时序数据库市场持续繁荣，竞争格局日趋清晰。本文将对当前主流的国产时序数据库进行梳理盘点，并特别聚焦于金仓数据库（Kingbase），深入剖析其以。
2026-01-16 17:02:01
1076
原创 从MongoDB到金仓：一家三甲医院医疗档案系统的国产化破局之路
目前，这套基于金仓数据库的医疗档案系统已稳定运行超过8个月。技术自主性增强：从底层基础设施到数据库内核，关键技术环节实现自主掌控；总体拥有成本下降：综合计算软硬件采购、维保和服务支出，整体TCO降低约40%；安全保障升级：满足网络安全等级保护三级要求，支持细粒度权限管理与全流程操作留痕；未来扩展性更好：新架构为后续接入医保DRG控费、区域医疗协同平台等新业务预留了良好接口。
2026-01-09 16:29:32
608
原创 Oracle迁移如何实现性能无忧？主流国产替代方案盘点
2024年，信创目录已覆盖超80%中央企业，国产数据库、Oracle替代方案、信创替换成为数字化转型的核心关键词。面对日益紧迫的供应链安全与合规要求，越来越多政企机构启动核心系统从Oracle向国产数据库的迁移工程。然而，“国产数据库能否替代Oracle？”仍是普遍关切——尤其是在金融、能源、医疗等关键行业，用户更关注迁移后的性能稳定性与业务连续性保障。本文将围绕主流国产替代产品，提供一套可落地的选型框架与迁移参考。
2025-12-26 18:20:51
979
原创 制造业Oracle迁移替换：集中式vs分布式架构如何选择？
若企业当前业务集中、数据规模可控、且核心系统强调强一致性与低延迟，优先考虑采用集中式架构，利用KES或KES RAC等产品实现在国产平台上的平稳过渡。若已面临大规模数据增长、多厂区协同或计划布局工业互联网平台，则建议引入分布式架构，借助KES Sharding、KES TDC等组件构建弹性数据底座。对于大型集团型企业，可借鉴“混合架构”思路，根据不同业务系统的属性分别部署，既保障关键系统的稳定性，又为创新业务预留发展空间。此外，无论选择何种架构，都应重视迁移过程中的工具链支持与专业服务能力。
2025-12-26 18:15:57
1140
原创 MySQL国产替代方案盘点：主流数据库选型指南
在推进数据库国产化替代的过程中，技术先进性并非唯一衡量标准。对于大多数政企用户而言，系统的稳定性、合规性、可维护性以及厂商的服务支撑能力，往往是决定项目成败的关键因素。
2025-11-25 16:50:17
1534
原创 主流国产数据库选型指南：助力企业平稳应对MySQL 5.7停服挑战
随着MySQL 5.7版本正式进入生命周期末期，国内众多企业正面临数据库系统停服带来的运维风险与安全隐忧。在此背景下，关键行业对数据自主可控、系统稳定可靠的要求持续提升，叠加信创政策的深入推进，数据库国产化替代已从“可选项”逐步转变为保障业务连续性的“必选项”。当前，企业在迁移路径上主要聚焦三大方向：升级至MySQL 8.0、采用国内开源增强分支，或切换至具备完整服务体系的国产商业数据库。
2025-11-25 16:33:51
677
原创 MySQL 5.7停服后国产数据库替代路径分析：聚焦兼容性、高可用与安全合规的综合选型策略
随着MySQL 5.7版本于2023年10月正式结束生命周期（EOL），大量仍在使用该版本的企业面临系统无法获得官方安全补丁、漏洞修复及技术支持的风险，运维压力显著上升。在数据安全威胁日益严峻、信创政策持续推进的大背景下，数据库的国产化替代已不再仅是技术层面的版本升级，而是涉及业务连续性保障、核心系统自主可控以及满足行业合规要求的重要战略举措。
2025-11-25 16:21:36
392
原创 MySQL 5.7支持将止，企业数据库迁移如何选型？
摘要：随着MySQL5.7支持周期结束，企业面临数据库升级或国产化替代的关键抉择。国产数据库如金仓、达梦等凭借自主可控、兼容性强等优势，正成为金融、政务等关键领域首选。迁移过程中需解决语法兼容、数据一致性等挑战，通过评估-迁移-验证六步方法论和工具链支持，可实现平稳过渡。实践证明国产数据库在性能和服务能力上已能满足高要求业务场景，助力企业构建安全自主的数字基础设施。
2025-11-25 16:15:20
359
原创 数据库选型：如何避开国产数据库选型陷阱
国产数据库正加速替代国外产品，预计2027年市场规模将超千亿元。但市场繁荣背后存在性能虚标、兼容性不足、运维支持薄弱等问题，导致企业选型困难。本文分析国产数据库现状及常见陷阱，并以金仓数据库（KES）为例，展示其高并发性能、Oracle兼容性和安全合规等优势。建议企业从性能、兼容性、安全性、生态支持四个维度构建科学评估体系，通过真实业务场景测试来避免选型风险，实现数据库平稳替代。
2025-11-21 17:24:58
735
原创 集中式 vs 分布式数据库：金融用户如何选择？——金仓数据库的双架构实践与选型指南
金融行业数字化转型中，数据库架构选型成为关键决策。本文对比分析集中式与分布式数据库的核心差异，结合金仓数据库（KES）实践案例，为金融机构提供选型建议。集中式数据库在强一致性、稳定运维方面表现优异，而分布式数据库则更适合高并发、弹性扩展场景。金仓数据库创新性地采用"集中分布一体化架构"，支持两种部署模式，既保障核心系统的稳定性，又能满足新兴业务的扩展需求。文章建议金融机构根据业务特征选择架构，并指出未来数据库将向融合演进方向发展，强调选型需立足业务实际，兼顾长期发展。
2025-11-21 16:37:18
490
原创 一文浅谈MySQL读写分离技术
读写分离作为提升数据库服务能力的重要手段，在应对高并发读写压力方面展现出显著成效。通过合理选用MySQL-Proxy或MyCAT等中间件工具，不仅可以实现高效的请求分流，还能增强系统的弹性与可靠性。然而，该技术也带来了数据一致性、运维复杂度等方面的挑战，需要结合具体业务需求制定科学的实施方案。未来，随着云原生数据库与智能路由技术的发展，读写分离将更加自动化与智能化。无论技术如何演进，始终应坚持以业务价值为导向，平衡性能、成本与稳定性之间的关系，打造可持续演进的数据基础设施。
2025-11-10 18:01:27
760
原创 信创产业链观察：从业者视角下的国产数据库技术趋势
信创是一项系统性、长期性的国家战略工程，需要全产业链的协同推进。国产数据库作为信息基础设施的关键支柱，肩负着保障数据安全、支撑业务连续的重要使命。金仓数据库凭借多年积累的技术实力、完善的生态布局和强大的服务体系，已成为信创生态中不可或缺的一环。面向未来，随着技术进步与市场需求的双向驱动，国产数据库将在自主创新道路上迈出更加坚实的步伐，为我国数字经济的高质量发展提供强有力的支撑。
2025-11-10 17:57:25
930
原创 信创数据库选型避坑：金融级数据库必备的5大核心能力解析
在信创战略持续推进的大背景下，金融级数据库的选型已不再仅仅是技术层面的比对，而是关乎国家安全、行业发展与企业长远竞争力的战略决策。综合来看，高性能、安全性、稳定性、自主可控与生态完备度五大能力构成了科学选型的核心维度。金融机构在进行技术评估时，建议结合自身业务特点，优先考察候选产品在真实场景中的表现，重点关注其在高负载下的性能一致性、故障恢复时效、安全合规资质以及与现有IT架构的融合能力。唯有如此，才能选出既符合当前需求、又具备未来发展潜力的理想数据库平台。
2025-11-10 17:46:31
833
原创 多模数据处理时代：国产数据库如何一站式支撑混合业务场景？
关系型数据、文档数据、GIS空间数据、时序数据等多种类型的数据在实际应用中频繁交织，形成复杂的多模数据处理需求。以智慧工厂为例，既要管理生产设备的静态属性（如型号、位置、负责人），也要实时采集其温度、振动、能耗等高频时序信号，同时还可能涉及厂区地理分布、巡检轨迹等空间信息。类似地，在城市交通监管、电力调度、金融风控等领域，跨模态数据联动分析已成为常态。相较于市场上多数仍处于“多模型拼接”阶段的产品，金仓数据库实现了从“共存”到“融合”的跨越，能够更好地适配互联网、制造、能源、交通等行业的复杂数据处理诉求。
2025-11-10 17:37:23
944
原创 国产数据库核心指标横评：兼容性、高可用、性能谁更能打？
作为信息系统的核心组件，数据库不仅承载着海量数据的存储与管理任务，更直接影响到业务系统的稳定性、响应效率和长期可扩展性。若新数据库支持多语法兼容能力，尤其是对Oracle、MySQL等主流数据库语法的高度适配，则可大幅降低代码改造成本，实现平滑过渡，减少停机时间与潜在风险。一个合格的企业级数据库应具备完善的访问控制机制、加密传输与存储功能、细粒度审计日志，并通过国家相关权威机构的安全认证，满足不同行业的合规要求。：提供主备架构与集群方案，具备基本的容灾能力，但在极端异常条件下，恢复时间略长于行业领先水平。
2025-11-10 17:28:58
849
原创 金仓KES MongoDB兼容性深度解析与实践
摘要：本文探讨国产数据库KingbaseES（KES）如何实现从MongoDB到国产数据库平台的平滑迁移。KES通过"多语法一体化兼容"和"多模数据一体化存储"技术架构，支持JSON/BSON类型数据操作，并提供GIN索引优化。文章结合电商平台迁移案例，展示了数据建模、索引优化和应用层适配的具体实施方案，验证了KES在文档型数据处理中的可行性。该方案为企业在信创背景下实现数据库国产化替代提供了技术路径和实践参考。（149字）
2025-10-30 18:34:36
950
原创 金仓替换MongoDB：金融交易数据一致性新解
摘要：本文以某股份制银行征信融资平台国产化改造为例，探讨金仓数据库替代MongoDB的实践。原系统使用MongoDB存储金融数据，面临数据一致性风险和高并发性能瓶颈。金仓数据库通过多模兼容、ACID事务支持和KFS同步工具，实现零停机迁移和金融级数据一致性。实施后，系统并发能力提升60%，查询延迟降低94%，事务错误率为零，满足监管要求。案例表明，金融核心系统数据库选型应优先考虑强事务支持，采用"评估-迁移-校验"闭环管理可有效降低替换风险。（149字）
2025-10-30 18:25:13
1158
原创 国产数据库替换MongoDB实战：浙江人民医院电子病历系统国产化升级案例
摘要：浙江人民医院成功将MongoDB数据库迁移至国产金仓KingbaseES多模数据库，实现了医疗核心系统的自主可控。该项目采用协议兼容和零代码迁移技术，通过读写分离架构将并发处理能力提升至1600+连接数，平均查询响应时间下降85%。2.3TB医疗数据在4小时内完成迁移，误差率低于0.001%，系统稳定运行8个月，年节省许可费用超百万元。该案例为医疗行业数据库国产化替代提供了"多模适配+工具链支撑+平滑过渡"的实施范式。
2025-10-30 18:22:52
807
原创 浅析数据库多租户
摘要：SaaS多租户架构通过租户资源隔离解决电商CRM、订单系统等平台类应用面临的性能瓶颈问题。核心挑战包括数据安全、资源分配、系统扩展性及运维复杂度。解决方案采用三种构建模式：独立数据库（最高隔离）、共享数据库独立Schema（中等隔离）和共享表结构（最低成本）。推荐配合中间件处理租户ID屏蔽、分布式事务等难点，并需根据数据敏感度选择合适模式，配合资源监控、定期备份等管理措施。该架构有效提升SaaS系统的扩展性和服务质量。
2025-10-30 18:17:19
495
原创 国产数据库MongoDB兼容性技术分析与实践对比
在全球技术自主可控趋势加强的背景下，国产数据库正加速补齐生态短板。在面对MongoDB这类广泛应用的NoSQL系统时，单纯的“能用”已不足以满足企业需求，真正的竞争力体现在兼容深度、迁移效率与长期可维护性。相较而言，达梦与GaussDB在传统关系型兼容方向积累深厚，但在文档数据库适配方面仍处于探索阶段；而金仓数据库凭借“多语法一体化”设计理念，结合等一系列配套工具，在NoSQL融合场景中展现出较强的综合能力。未来，随着多模数据库架构的发展，预计更多国产产品将加强对JSON、图、时序等多元数据模型的支持。
2025-10-24 17:33:26
1053
原创 国产数据库替代MongoDB：政务电子证照新选择
作为一名数据库从业者，我亲历了中国数据库从早期依赖国外产品到逐步实现自主可控的发展历程。曾经我们只能参考Oracle、MongoDB的技术实现；如今，金仓、达梦、OceanBase等一批国产数据库正在凭借扎实的技术积累和服务能力赢得广泛认可。这场发生在东南一隅的“数据迁徙”，看似平凡，却是中国基础软件进步的一个缩影。它告诉我们：只要坚持自主创新、深入业务场景、打磨核心技术，国产数据库完全有能力胜任关键业务系统的支撑任务。未来已来，属于中国数据库的成长之路，正在稳步展开。
2025-10-24 17:19:57
897
原创 ArcGIS产品构成
ArcGIS产品体系主要包括桌面GIS、服务器GIS、移动GIS和在线GIS四大类。桌面GIS包含ArcReader、ArcGIS Desktop（含ArcView/ArcEditor/ArcInfo）、ArcGIS Engine和ArcGIS Explorer等组件，提供数据创建、编辑和分析功能。服务器GIS以ArcGIS Server和ArcIMS为核心，支持企业级GIS应用与服务。移动GIS和在线GIS则扩展了GIS的移动应用和云端服务能力，满足不同场景需求。整个体系功能完善，覆盖从数据采集到分析应用
2025-10-24 16:26:47
1014
原创 一场“无感换心”手术：金仓数据库如何让电子证照系统平滑告别MongoDB
摘要：数据库专家老王分享某省电子证照系统国产化替代经验。面对原MongoDB数据库性能瓶颈和国产化改造时间压力，团队采用金仓数据库的MongoDB协议兼容方案，实现零代码修改的无缝迁移。迁移后系统性能显著提升，关键查询从5秒优化至0.3秒内，同时降低40%运维成本。该案例证明国产数据库不仅能满足核心业务需求，还能通过技术创新实现平滑过渡和性能超越，为政务等重点行业国产化改造提供了可复制的成功范式。（149字）
2025-09-26 16:52:26
729
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人