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

4

本文将介绍如何基于 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+PHP+MYSQL

系统模块:

  • 应用中心

  • 属性中心

  • 标签中心

从技术角度描述RBZ的运转流程大致如下:

  • 通过[属性中心]配置和管理属性。

  • 通过[标签中心]配置和管理标签。

  • 通过[应用中心]选择[实体、属性、标签],自动生成表单,录入数据。

  • 通过[CMS]动态模版输出给C端用户。

下面逐一讲解,他们分别是什么。:)无比接近干货地段了。

系统设计

架构

RBZ架构图

表结构

基于列模式的表设计。(我们常规的工作都是行模式

举个栗子:A公司售卖鞋子和衣服。(比较极端,勿喷)

行模式(产品表)

PID PNAME 类型 尺码 颜色
0001 鞋子1 1 42 黑色
0002 衣服1 2 XL 蓝色

列模式(属性表、实体表)

属性表(类型、排序、启用、默认值、可选值、必填...)

属性ID 属性名称 属性字段 数据类型 属性分组
1 尺码 size input 鞋子
2 尺码 size input 衣服
3 颜色 color input 鞋子
4 颜色 color input 衣服

实体表

ID 应用ID 实体ID 属性ID 属性值
1 1 0001 1 42
2 1 0001 3 黑色
3 1 0002 2 XL
4 1 0002 4 蓝色

这番设计,两个益处。

  1. 省存储空间。

  2. 易动态扩展。

动态表单

我们的常规工作是静态表单,避免在Code Monkey的路,越走越远,我们需要改变。

设计动态表单模型,基本的思路应该是数据和表现显示的分离。抛开表现层,一个表单包含的若干个字段和填写的数据。所谓动态,就是这些字段名称可能改变,数量可能有增减。

配置字段(POI中文名称)

POI中文名称

配置中。。。

POI属性列表

见证奇迹的时刻。(表单自动生成)

表单

这番设计,两个益处。

  1. 猴子做架构了(再也不用写FORM了)。

  2. 用户自定义。

CMS

通过CMS定义RBZ标签,结合自定义样式模版,任意组合吐出数据。

用了一个叫 Mustache 的模版语言。


{{#cmsRbzItems}}
中文名称 {{attr_cnname}}
英文名称 {{attr_enname}}
岛屿图片 {{attr_pic}}
所属群礁 {{attr_class}}
酒店品牌 {{attr_hotel}}
费用信息 {{attr_price}}
产品推荐 {{attr_managerrecommend}}
岛屿星级 {{attr_islandstar}}
岛屿排序 {{attr_islandrank}}
上岛时间 {{attr_timecost}}
{{/cmsRbzItems}}

API

为确保RBZ接口的持续交付,我们选择用 Postman 来做接口的自动化测试工作。

某一个请求。

请求

每一次发布。

发布

RBZ-应用

处子秀:马尔代夫选岛工具

需求:

  • 提取马尔代夫的所有岛屿(POI)

  • 扩展岛屿属性(费用信息、岛屿星级、产品经理推荐)

  • 给岛屿打标签(蜜月、亲子、一价全含、WIFI)

  • 选岛工具

只需配置,无需研发

  • 配置属性

  • 配置标签

  • 配置应用

    • 选POI

    • 编辑属性

    • 编辑标签

灯灯灯灯。。。

筛选项:

筛选项

实体:

实体

在这里,代表官方,诚邀各种应用接入。

RBZ-ROI

浅谈RBZ的回报率。

  • 成就工作快,降成本,提效率。(之前这样的后台开发任务至少需要15人天)。

  • 可能成为运营层数据字典

  • 聚合页需求配置化

  • 精细化运营:脱离底层数据,在运营层通过属性、标签配置,精细化呈现。

结论

理解EAV模型确实需要时间。它有一个明确的学习曲线,使的初级开发人员在真正理解其概念前,需要为此付出更多的精力。

应用实体-属性-值时,应考虑以下条件:

  • 数据是稀疏的、异构的,一个实体的属性范围较广,且常引入新的属性。

  • 类的数量非常大,有许多实例类,即使属性是非稀疏的。

结束语

我们的终极目标是:

人人都是程序员。

你可能感兴趣的

hsfzxjy · 2016年05月14日

个人觉得eav效率低,我用的是postgresql的jsonb字段完成类似功能

回复

tuniutech 作者 · 2016年05月14日

@hsfzxjy 的确,EAV已经是古董技术了,效率的问题建议推Solr去处理。为了解决稀疏表存储的问题,建议基于 Column Family(列族)来处理,Cassandra是不错的选择。

回复

tuniutech 作者 · 2016年05月14日

@hsfzxjy EAV只是整套系统中的一个模块,结合动态表单和模版语言的应用,使其成为一个生产闭环应用。

回复

hsfzxjy · 2016年05月14日

学习了

回复

载入中...