途牛原创｜基于EAV模型的运营系统架构实践

序

本文将介绍如何基于 EAV 模型，来构造一个准自动化的运营系统，服务运营研发部的相关工作。

我们的痛点

运营研发部对接三端（PC、M、APP）后台工作，劳心劳力。。。

• 头疼的稀疏表（ 稀疏表通常会有很多列，但是每一行有值的列又比较少。）＋头疼的各种表。
• 持续的迭(xu)代(qiu)升(bian)级(geng)（每一次功能升级，都需要变更表结构）。
• 基础数据的维护代码坑好多，打个标签加个属性，都好怕。
• Code Monkey，熟悉的表＋熟悉的套路（设计表单、设计字段、CRUD…）Boom！

漫漫选型路

其实我们的愿景很“简单”。

• 可以舒服地给各种［途牛实体］打标签、扩展属性。
• 可以简单地记录任何结构的新数据，而不需要修改任何数据结构。
• 可以极好地迅速扩展应用，因为它可以防止(属性)不断变化的后果。

漫漫长路。。。

为了高可用&扩展性，我们学习了Drupal的元数据操作、Magento的产品建模、以及各种CMS。

为了解决稀疏表，我们尝试基于 Column Family（列族）来处理，BigTable、Cassandra、HBase，曾经都是我们的“座上客”。（事实上，很多团队已经这样解决掉了）

然而，

踏破铁鞋无觅处，得来全不费工夫。

一种数据模型悄然而至，实体属性值模型。

来自百度百科：实体属性值模型（EAV）是一种用数据模型描述实体的属性（属性，参数），可以用来形容他们潜在巨大，但实际上将适用于给定的实体的数量是相对较少。 在数学中，这种模式被称为一个稀疏矩阵 。 EAV也被称为对象的属性值的模式，垂直的数据库模型和开放式架构。

这里不详细介绍EAV是什么，因为我们的设计在EAV之上。（站在巨人的肩膀上）

下面即将进入全文干货集中地段。^_^

RBZ

系统代号：RBZ（肉包子）

系统构成：EAV＋DF＋AC