https://CoderAmedal.github.io/tags/%E6%95%B0%E6%8D%AE%E5%BA%93/Recent content in 数据库 on BIT & 42Hugo -- 0.160.1zh-CN2025 Bit &amp; 42. 这是生命、宇宙以及一切的终极版权声明Mon, 24 Jun 2024 00:00:00 +0000https://CoderAmedal.github.io/posts/neo4j-usage-scenarios/Mon, 24 Jun 2024 00:00:00 +0000https://CoderAmedal.github.io/posts/neo4j-usage-scenarios/<h1 id="neo4j图数据库的使用和常用场景分析">Neo4j图数据库的使用和常用场景分析</h1> <h2 id="图数据库解决了什么关系型数据库做不好的事">图数据库解决了什么关系型数据库做不好的事</h2> <p>关系型数据库用外键和 JOIN 来表达实体间的关系，这在关系层级较浅（一两层）时工作得很好。但当关系深度达到三四层甚至更多时，SQL 的 JOIN 会急剧膨胀，性能断崖式下降。</p> <p>举个例子：<strong>查找&quot;和用户 A 有共同好友的所有用户&quot;</strong>——在 SQL 中需要自连接好友表两次，而在 Neo4j 中，这只是一行自然表达的 Cypher 语句。</p> <p>图数据库的核心优势：<strong>关系是一等公民，遍历关系的成本是 O(1)</strong>，而不是 JOIN 的 O(n)。</p> <h2 id="典型使用场景">典型使用场景</h2> <h3 id="1-社交网络与推荐系统">1. 社交网络与推荐系统</h3> <p>最经典的场景。用户-好友-帖子-点赞-评论构成了一个天然的图。Neo4j 可以轻松查询：</p> <ul> <li>二度/三度人脉</li> <li>共同好友推荐</li> <li>基于&quot;购买了 A 的人也购买了 B&quot;的协同过滤</li> <li>内容传播路径追踪</li> </ul> <h3 id="2-反欺诈与风控">2. 反欺诈与风控</h3> <p>欺诈行为往往是<strong>团伙作案</strong>：一群虚假账户共享相似的设备、IP、银行卡。在关系型数据库中检测这种环形关联非常困难，但 Neo4j 可以用路径查询快速发现：</p> <ul> <li>资金环形流转检测</li> <li>关联人/关联账户网络分析</li> <li>多跳关联风险传播</li> </ul> <h3 id="3-知识图谱">3. 知识图谱</h3> <p>知识图谱本质就是实体-关系-实体的三元组。Neo4j 天然适合：</p> <ul> <li>企业知识管理（文档-知识点-部门-项目关联）</li> <li>智能问答的后端存储</li> <li>供应链追踪</li> </ul> <h3 id="4-权限与组织架构">4. 权限与组织架构</h3> <p>公司组织架构是天然的树/图结构。Neo4j 在处理：</p> <ul> <li>汇报链查询</li> <li>权限继承</li> <li>RBAC 角色层级</li> </ul> <p>等场景时比递归 SQL 简洁得多。</p> <h3 id="5-网络与基础设施拓扑">5. 网络与基础设施拓扑</h3> <p>CMDB、微服务依赖图、网络拓扑、路由分析——这些都是图结构的天然应用场景。用 Neo4j 存储后，可以通过路径查询快速回答&quot;服务 A 宕机会影响哪些下游&quot;这类问题。</p> <h2 id="cypher-基础语法感受">Cypher 基础语法感受</h2> <p>Cypher 是 Neo4j 的查询语言，风格上有点像 SQL 但专门为图设计。几个基础操作：</p>https://CoderAmedal.github.io/posts/rdbms-comparison-performance/Sun, 24 Apr 2022 00:00:00 +0000https://CoderAmedal.github.io/posts/rdbms-comparison-performance/<h1 id="主流关系型数据库的差异及性能分析">主流关系型数据库的差异及性能分析</h1> <h2 id="一份中立的对比">一份中立的对比</h2> <p>工作中先后接触过 MySQL、PostgreSQL、Oracle，也用过 SQL Server 和 SQLite。每个数据库都有自己的设计哲学和适用场景。这篇文章整理一下个人理解，不吹不黑，尽量实事求是。</p> <h2 id="核心差异速览">核心差异速览</h2> <h3 id="mysql互联网的首选">MySQL：互联网的首选</h3> <p><strong>核心优势</strong>：简单、运维成熟、社区庞大。</p> <p>MySQL 的设计哲学是&quot;够用就好&quot;。它不像 PostgreSQL 那样追求 SQL 标准的完备性，而是优先保证简单场景下的性能。InnoDB 存储引擎是绝大多数场景的唯一选择——B+ 树索引、MVCC、行级锁。</p> <p><strong>需要注意的点</strong>：</p> <ul> <li>对复杂查询（窗口函数、CTE）的支持较晚，直到 8.0 才比较完善</li> <li>JSON 支持和全文索引够用但不强</li> <li>复制架构基于 binlog，GTID 复制在管理上很便利</li> <li>幻读问题：InnoDB 在可重复读隔离级别下通过 Next-Key Lock 解决，但实际上还是可能发生（快照读 vs 当前读）</li> </ul> <p><strong>适用场景</strong>：OLTP、互联网业务、读写分离架构、中小规模数据。</p> <h3 id="postgresql功能最完备的开源数据库">PostgreSQL：功能最完备的开源数据库</h3> <p><strong>核心优势</strong>：SQL 标准兼容性最好、扩展性强、适合复杂查询。</p> <p>PostgreSQL 是一个&quot;学院派&quot;数据库，它的功能完备程度在某些方面甚至超过商业数据库：</p> <ul> <li>最完整的窗口函数、CTE、递归查询支持</li> <li>优秀的 JSON/JSONB 支持（可以当半个文档数据库用）</li> <li><strong>丰富的索引类型</strong>：B-Tree、Hash、GiST、SP-GiST、GIN、BRIN</li> <li>原生支持地理空间数据（PostGIS）</li> <li>外键、触发器、函数等支持非常完整</li> <li>MVCC 实现基于多版本行存储，会产生死元组，需要定期 VACUUM</li> </ul> <p><strong>需要注意的点</strong>：</p> <ul> <li>连接开销比 MySQL 大，高并发短连接场景需要连接池（PgBouncer）</li> <li>VACUUM 和 ANALYZE 需要关注，否则性能会逐渐下降</li> </ul> <p><strong>适用场景</strong>：复杂业务逻辑、数据分析、GIS、需要高度 SQL 标准兼容的场景。</p> <h3 id="oracle企业级标杆">Oracle：企业级标杆</h3> <p><strong>核心优势</strong>：最成熟的优化器、最完善的高可用方案、最强的硬件利用率。</p> <p>Oracle 的核心竞争力在于它的优化器和 RAC（Real Application Clusters）。Oracle 的 CBO 优化器的成熟度是其他数据库难以比拟的——同样的复杂查询，Oracle 往往能选出更优的执行计划。RAC 实现了多节点共享存储的集群架构，提供了极高的可用性。</p>