|
物化视图的问题在于什么时候刷新。通过用 SQL 定义 impactSet，我们可以由 mysql binlog 触发物化在 clickhouse 中的物化视图表刷新。
用户行为表
物化视图的来源是业务数据。用户行为因为数据量比较大，不太适合直接插入到 mysql 中。把用户行为单独提供一张宽表来记录用户做过什么操作。写入可以是内存缓冲，或者经过 kafka 这样的队列缓冲。
宽表的列应该是按业务需求扩展的，如果业务上关心用户操作的订单id，或者商品id，则要加上这些字段。大概的 api 也类似 mixpanel 这些老牌分析厂商的上报接口。
物化视图在计算报表的时候可以 join 用户行为表和业务数据表来得出分析结果。
查询的时候直接用这个 class 来指代这张数据库表就可以了。
视图表
能够做好权限校验的前提是只暴露单表的简单查询。那么 count / sum / join 这些怎么处理? 难道是要发明一种 SQL 变种，然后搞 SQL 解析么?
一个简单的做法就是引入“视图表”的概念。把这些聚合查询都建模成一张虚拟的视图表。这样在查询的时候仍然是单表查询。
-
解决了 rpc 请求的时候如何表达复杂 query 的问题，避免了 sql over http
-
解决了权限校验难以确定目标是什么的问题
物化视图表
如果所有的聚合查询都要按需计算则会非常慢。经常我们需要一些按日期，按维度提前聚合好的中间结果。这个可以用物化视图表来表达
答：Backend as a Database, Sort Of
直接把 Mysql 暴露在公网给前端使用会有什么问题：
-
I/O 边界 => 性能考虑
-
批量获取多条数据
-
对数据进行 count / sum 等聚合
-
把聚合结果做提前计算，冗余字段
-
组织边界 => 安全考虑
-
数据权限校验，防止非法访问
-
校验业务规则
-
产生的订单价格应该等于商品单价之和
-
出库单要创建，需要xxx领导签字单
要做到 Backend as a "Database"，就是回答以上问题如何解决。
User 表
Mysql / Postgresql 的权限太粗了。肯定是要在 Mysql / Postgresql 外边套一层去校验权限。这里有如下的挑战要解决
-
B 端权限需要非常细致，不仅仅要到行，甚至到格。权限可能是按职位授予，也可能是因为工单分配临时授予。
-
权限校验开销不能太大，如果拿来做 C 端业务，单据数量和用户数量都可能会非常大。要减少因为行级别权限引入的开销。所以要能按需打开不同的授权模式。
-
没有登录的用户需要登录，或者能够匿名浏览。如何方便给没有用户的访问做适当的提权。
-
非真实人类用户的访问，比如夜间的批处理，需要能够有机器人的账号
-
账号的初始化是如何描述的，谁来分配最初的那个管理员
-
如果有多个 Project，每个 Project 有自己的用户体系，不同的 User 表。这两个 Project 要互相访问，用什么 User 身份?
解决了以上问题，我们就获得了一个内建权限的“Database”，可以开放到公网给前端访问。实际拉数据的时候，用的是人类用户自己的身份。只要用户自己对要访问的数据表或者行有权限，就可以访问到，否则就访问不到。
业务数据表
写一个 Typescript 的类，然后把 Mysql 的表建好。和 Java Hibernate 一样
（编辑：柳州站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
