从 EAV 到 XTable

先把我想说的结论说在前面：XTable 系列产品如果技术上要成功，有一条路是走类似 TiDB 的路，再造一个数据库，毕竟本身就确实就是一个直接面向业务的数据库产品。当然，投入是巨大的，有多大，看看 TiDB 就知道了，而且也不一定保证就能成，同时还需要有真实业务做牵线搭桥，来引导技术不会跑偏不会闭门造车。所以这条路，风险巨大而艰巨，一般人真的不要随便尝试，要么技术关过不去，要么钱撑不下来，到最后都是死路一条。

所以，做业务系统的就死心塌地来认认真真做业务定制，尽量做一些些较为业务合理的抽象，满足市场中你那一部分的客户需求，养活你所能养活的那个企业，就足够了。客户需求永无止尽，不要贪大求全，抽象的极致抽象，就是做不到的。是的，不要贪，除非你有腾讯字节阿里巴巴这种体量，请得到，养得起，耗得住。

好，下面说回来。

很少有人可能像我这样的经历，从外贸公司到互联网 SaaS 软件技术公司，当初在外贸公司还是个业务小白，更不会想到某一天后来会进入技术领域的时候，就经常听过 EAV 的性能问题传说，即 Entity-Attribute-Value 数据存储模式，是外贸独立站圈子里面当产品数量多起来之后一定会遇到的问题。

不过其实算下来，独立站毕竟都还算是私有化部署，再顶天也不会多到哪里去，几百个毫秒勉强一下其实也不是不能接受。

当然，那个时候还没有 NoSQL 的兴起，也更没到后来 Json 列的出现，稍有点想法的，我猜他们有可能是存成字符串了，至于是什么格式，可能都不重要了，反正只要自己能解就行了，那时候甚至可能基于 Json 数据交换格式的 Restful API 都可能还没普及开。

当然，其实就是我确实不知道，毕竟那时候还没去深入接触他们那些细节的事情。

后来，大家也都看到了，独立站没落，亚马逊兴起。国内电商蓬勃发展，然后多年以后又纷纷杀向全球，一直到如今的这个样子。

说回来，今天真正想说的是一个什么问题呢？其实是想说一个技术和业务结合的综合性问题。

首先，我们目前大多数业务型系统大致上会有这么几个东西：用来显示和操作的UI层，一般叫前端，用来处理数据和执行操作的业务逻辑层，一般就是后端，这个后端在大多数情况下是“无状态”的，意思就是它本身是不保存什么数据的，而数据都会给谁去保存呢？数据库，各种各样的数据库，关系型 SQL，非关系型 NoSQL，后来 SQL 说我也可以管理非结构化数据，就有了 JSON 类型，

商城类产品的数据存储，由于产品的属性千差万别，在小型公司的的数据量规模下，就已经很经常出现性能瓶颈了，因为如果要用 EAV 模式，它形成的数据规模是巨大的，哪里大呢？行数。MySQL 之前的版本，多少行比较合适相比也有所耳闻了。把这个数字算一算，看看最大能撑下多少产品数量，这取决于一个产品到底有多少个产品属性字段。

更不用说，后来有些需求还想基于这些字段做筛选、排序、计数等操作。

技术层面有一个永远也不会过时的问题：规模。

在非常小规模的时候，你想怎么玩就怎么玩，有多少功能就上多少能力，把别人提供的功能全给我用上，以体现技术人员的能力也行，想体现产品人员的产品丰富度也行，随便玩。

但是，一旦规模上去了，就不能这么为所欲为了。

这也是很多产品，以及一些开源产品，你自己玩玩可以，私有化部署企业内部用用也可以，但是，要想基于它为你的外部客户提供服务，这就成了一个 SaaS 服务的通病：规模问题、租户问题。

一个客户的数据几万几百万，封顶了（这里就简单说下行数，其它就不说了，复杂的东西多了去了）。

但是作为 SaaS 服务，随便一百个客户，放在一起，数据规模随随便便就是亿级。

你说，干嘛不按客户分开放，那你愿意这样干也行，就是等于私有化部署嘛，那看你愿意投入多少资源去维护了。

反正简单说就是：在一个客户的规模下，很多功能随便玩，但是客户量一大，各个维度的规模自然就上去了，这时候很多功能就很难搞。

这个坑，在很多产品经理的眼里，从来没有考虑过。通常就是反问一句：为什么别人 XXX 能实现？

上面说的这个，还只是真正做业务系统，离业务最近的，等于是按业务进行定制化开发的。

后来，业务总是有泛化的需求：字段要能让客户随意自定义，自定义的字段还要能参与筛选、排序、搜索等等之类。

我曾想，是不是类似 AirTable 那样的产品能真正满足需求，从功能逻辑想，如果人家有那样的产品能力实现，是不是通用的底层能力就有了，什么客户自定义的需求都能完美满足？

只能说，图样图森破。

后来又真正去到了做这样的通用能力的产品的公司，这种产品，离业务又更远了，看似把很多需求都抽象出了通用能力，看似这个需求能满足，那个需求也能满足，但是回过头来看，好像又哪个领域的需求都没有真正深入满足，然后又收获到一堆客户的各种稀奇古怪的需求。

分析需求，抽象需求，设计产品功能，实现它，跑起来。

然后，堆得太多，跑不动。

技术上，性能关过不了。

业务上，需求关过不了。

需求关过不了可以砍需求，技术关过不去，就真的只能等死。

客户如果对一个产品没有了期望，就一定不会续费。

这对一个 SaaS 产品来说，就是等死。

在今天这个时间点，技术问题还在么？

在的。

取舍一些功能的前提下，把产品的属性存成字符串，这是最极端的。

能用上 JSON 类型字段，得是新版本新开发，需求要大胆地砍，否则无法推进。

能用上类似 MongoDB 这种 NoSQL 数据库，那也是有经验有了深刻理解才能用的好，更重要的是，产品需求也是一样要大幅度砍一砍的。

要想完全一个需求也不砍，只能重新再造一个数据库产品。

所以，通用型自定义字段需求，即 XTable 类型在线 SaaS 产品，除非家大业大，技术储备足够，基本没有普通公司什么事情了。

它在技术上，要想成功，等于再造一个数据库产品，如果没有很大的实力，玩不动的。

或者，别做 SaaS 在线产品，但是这个也仅仅只是稍稍降低了一点点难度，一个客户就没有可能数据规模大一点的了？也是有很多的。

而这部分“大客户”却刚刚好又是收入的主要来源的时候，又如何应对？

所以结论还是：XTable 类型在线 SaaS 产品，除非技术关有重大突破，否则业务关总之是闯不过去的。

想起我在以前开过的一个内部直播，以为 XTable 这种产品能彻底解决业务问题，惭愧了，是我见的世面还太少了。

看懂了就感谢捧了个场，没看懂恕我才疏学浅，请谅解。

再见。