假设需要存储大量法律合同文本（非结构化数据），设计一个数据库方案，包括表结构设计、索引策略，以及如何高效检索合同中的关键信息（如合同金额、签署日期、条款关键词）？

广东国鼎律师事务所律师助理难度：中等

答案

1) 【一句话结论】：对于存储大量法律合同文本（非结构化数据），应采用“关系型数据库存储结构化元数据（如合同金额、签署日期）+ 全文搜索引擎（如Elasticsearch）存储并索引全文内容”的混合方案，既能高效管理结构化信息，又能快速检索文本中的关键词（如条款关键词）。

2) 【原理/概念讲解】：首先，非结构化数据（如合同文本）的特点是内容复杂、无固定格式，直接存储在关系型数据库会导致查询效率低。关系型数据库（如MySQL）适合存储结构化元数据（如合同ID、合同号、金额、签署日期等），因为它们有严格的表结构，支持事务和ACID特性，保证数据一致性。而全文搜索引擎（如Elasticsearch）专为文本检索设计，通过倒排索引技术，能快速定位文本中的关键词，支持复杂查询（如模糊匹配、范围查询）。类比：关系型数据库就像“合同档案的电子台账”，记录每份合同的编号、金额等关键信息；全文搜索引擎就像“合同内容的电子字典”，能快速查找到合同中提到的“违约金”“保密条款”等关键词。

3) 【对比与适用场景】：用表格对比关系型数据库（RDBMS）和全文搜索引擎（ES）的特性：

特性	关系型数据库（如MySQL）	全文搜索引擎（如Elasticsearch）
数据类型	结构化（表、列、行）	非结构化（文档、字段）
查询能力	SQL查询，支持事务、ACID	全文检索，支持复杂查询（如模糊、范围、布尔）
适合场景	存储结构化元数据（合同ID、金额、日期）	存储并检索合同全文（关键词、条款匹配）
注意点	查询复杂文本效率低，需额外处理	需定期同步数据，保证一致性

4) 【示例】：假设合同表（contracts）和全文索引表（contract_text），其中contracts表存储结构化数据，contract_text表存储ES的索引映射。

表结构设计：

-- 合同表（关系型数据库）
CREATE TABLE contracts (
    id INT PRIMARY KEY AUTO_INCREMENT,
    contract_no VARCHAR(50) NOT NULL UNIQUE,
    amount DECIMAL(20,2) NOT NULL,
    signing_date DATE NOT NULL,
    creation_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    version INT DEFAULT 1
);

-- ES索引映射示例（JSON格式）
PUT /contracts
{
  "mappings": {
    "properties": {
      "contract_no": { "type": "keyword" },
      "amount": { "type": "keyword" },
      "signing_date": { "type": "date" },
      "text_content": { "type": "text", "analyzer": "ik_max_word" }  // 中文分词
    }
  }
}

插入数据示例：

-- 插入合同元数据
INSERT INTO contracts (contract_no, amount, signing_date) 
VALUES ('GD20240101', 500000.00, '2024-01-15');

-- 同步到ES
POST /contracts/_doc/1
{
  "contract_no": "GD20240101",
  "amount": "500000.00",
  "signing_date": "2024-01-15",
  "text_content": "本合同约定双方在2024年1月15日签署，合同金额为人民币五十万元，包含违约金条款。"
}

检索示例（ES查询）：

GET /contracts/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "text_content": "违约金" } },
        { "range": { "amount": { "gt": 400000 } } }
      ]
    }
  },
  "sort": [ { "signing_date": "desc" } ]
}

5) 【面试口播版答案】：各位面试官好，针对存储大量法律合同文本的问题，我的方案是采用“关系型数据库 + 全文搜索引擎”的混合架构。首先，用关系型数据库（如MySQL）存储结构化元数据，比如合同ID、合同号、金额、签署日期这些关键信息，因为它们有严格的表结构，能保证数据一致性和事务处理。然后，用全文搜索引擎（如Elasticsearch）存储合同全文，通过倒排索引技术，能快速检索文本中的关键词，比如“违约金”“保密条款”等。具体来说，合同表设计包含id、合同号、金额、签署日期等字段，全文索引表（ES映射）包含text_content字段，支持中文分词。检索时，先通过关系型数据库查询结构化信息（如金额大于400万的合同），再结合ES查询全文中的关键词，实现高效检索。这样既能管理结构化数据，又能快速匹配文本内容，满足法律合同的高效检索需求。

6) 【追问清单】：

问题1：如何保证关系型数据库和全文搜索引擎的数据一致性？
回答要点：通过数据库触发器或消息队列（如Kafka）实时同步数据，确保ES中的合同信息与数据库一致。
问题2：如果合同有多个版本，如何设计表结构？
回答要点：在合同表中增加version字段，记录版本号，ES索引也支持版本控制，通过版本号区分不同版本。
问题3：如何优化检索速度，比如处理大量合同时？
回答要点：对ES进行分片和副本设置，合理分配索引分片，同时优化查询语句，减少不必要的字段返回。
问题4：如果合同文本包含敏感信息，如何保证数据安全？
回答要点：对敏感字段（如金额、日期）加密存储，ES索引中不存储敏感信息，或通过权限控制访问。

7) 【常见坑/雷区】：

坑1：仅用关系型数据库存储全文内容。
雷区：关系型数据库查询文本效率低，无法高效检索关键词，导致检索速度慢。
坑2：表结构设计不合理，将全文内容存入关系型表。
雷区：关系型表不适合存储非结构化文本，会导致表结构复杂，查询性能下降。
坑3：未对关键字段建立索引。
雷区：如合同金额、签署日期等字段未建索引，导致查询这些结构化信息时效率低。
坑4：忽略全文搜索引擎的索引更新策略。
雷区：未定期更新ES索引，导致检索结果过时，影响查询准确性。
坑5：未考虑数据一致性，导致ES和数据库数据不一致。
雷区：合同修改后未同步到ES，导致检索结果错误，影响业务使用。