关联关系处理

现实世界有很多重要的关联关系(((“relationships”)))：博客帖子有一些评论，银行账户有多次交易记录，客户有多个银行账户，订单有多个订单明细，文件目录有多个文件和子目录。

关系型数据库被明确设计—毫不意外—用来进行关联关系管理(((“relational databases”, “managing relationships”)))：

• 每个实体（或 行 ，在关系世界中）可以被 主键 唯一标识。(((“primary key”)))

• 实体 规范化 （范式）。唯一实体的数据只存储一次，而相关实体只存储它的主键。只能在一个具体位置修改这个实体的数据。(((“joins”, “in relational databases”)))

• 实体可以进行关联查询，可以跨实体搜索。

• 单个实体的变化是 原子的 ， 一致的 ， 隔离的 ， 和 持久的 。 （可以在 ACID Transactions 中查看更多细节。）

• 大多数关系数据库支持跨多个实体的 ACID 事务。

但是关系型数据库(((“ACID transactions”)))有其局限性，包括对全文检索有限的支持能力。 实体关联查询时间消耗是很昂贵的，关联的越多，消耗就越昂贵。特别是跨服务器进行实体关联时成本极其昂贵，基本不可用。 但单个的服务器上又存在数据量的限制。

Elasticsearch ，和大多数 NoSQL 数据库类似，是扁平化的。索引是独立文档的集合体。 (((“indices”))) 文档是否匹配搜索请求取决于它是否包含所有的所需信息。

Elasticsearch 中单个文档的数据变更是 ACIDic 的， 而涉及多个文档的事务则不是。当一个事务部分失败时，无法回滚索引数据到前一个状态。

扁平化有以下优势：

• 索引过程是快速和无锁的。
• 搜索过程是快速和无锁的。
• 因为每个文档相互都是独立的，大规模数据可以在多个节点上进行分布。

但关联关系仍然非常重要。某些时候，我们需要缩小扁平化和现实世界关系模型的差异。(((“relationships”, “techniques for managing relational data in Elasticsearch”)))以下四种常用的方法，用来在 Elasticsearch 中进行关系型数据的管理：

• Application-side joins
• Data denormalization
• Nested objects
• Parent/child relationships

通常都需要结合其中的某几个方法来得到最终的解决方案。