Meta Feature：解决方案架构师的宝藏
说到这里 ， 我想进一步展开一个概念 ， 有一些功能和其它功能不一样 ， 这类功能可以作为构建其它功能的基础 ， 组合出新的特性 。 这类功能我称之为：Meta Feature ， 上面提到的 Placement Rule 就是一个很典型的 Meta Feature, 例如：Placment Rule + Follower Read 可以组合成接近传统意义上的数据库一写多读（但是更灵活 ， 更加细粒度 ， 特别适合临时性的捞数或者做临时的查询 ， 保证数据新鲜的情况下 ， 不影响在线业务） ， Placement Rule + 用户自定义的权限系统 = 支持物理隔离多租户；Placement Rule + Local Transaction + 跨中心部属 = 异地多活（WIP）；Placement Rule 还可以将精心设施数据的放置策略 ， 让 TiDB 避免分布式事务（模拟分库分表） ， 提升 OLTP 性能 。

文章图片

Meta Feature 通常不太会直接暴露给终端的用户 ， 因为灵活性太强 ， 用户会有一定的学习成本和上手门槛（除非经过精心的 UX 设计） ， 但是这类能力对于架构师/解决方案提供商/生态合作伙伴尤其重要 ， 因为 Meta Feature 越多 ， 一个系统的‘可玩性’越高 ， 造出来的差异化方案也越多 。 但是通常我们会犯一个错误：灵活性是否等于产品价值？我认为不是的 ， 虽然工程师（尤其是 Geek）对这类开放能力有天生的好感 ， 但是对于终端用户到底能否说好这样的故事 ， 我是存疑的 ， 看看 Windows 和 UNIX 的终端用户的市场占有率就知道了 。 在这个例子上最近我听到了个绝佳的例子 ， 和大家分享：你并不能对一个美式的爱好者说拿铁更好 ， 因为你可以灵活的控制含奶量 ， 奶降低到 0 就包含了美式 。
我们再看一个场景 ， 关于批处理 。 熟悉 TiDB 历史的朋友肯定知道我们最早这个项目的初心其实是从 MySQL Sharding 的替换开始的 ， 后来慢慢的很多用户发现：反正我的数据都已经在 TiDB 里了 ， 为什么不直接在上面做计算？或者原来一些使用 SQL 做的复杂的数据变换工作遇到了单机计算能力瓶颈 ， 而且因为一些业务要求 ， 这些计算还需要保持强一致性甚至 ACID 事务支持 ， 一个典型的场景就是银行的清结算业务 ， 本来年轻的我还不太理解 ， 这类批处理业务直接 Hadoop 跑就好了 ， 后来了解清楚情况以后才发现还是年轻了 ， 对于银行来说 ， 很多传统的清结算业务是直接跑在核心的数据库上的 ， 而且业务也不简单 ， 一个 Job 上百行的 SQL 家常便饭 ， 很可能开发这个 Job 的开发商已经不见了 ， 谁也不敢轻易改写成 MR Job ， 另外对于批量后结果 ， 可能还要回填到数据库中 ， 而且整个过程需要在短短几个小时内完成 ， 完不成就是生产事故 。 原本如果数据量没那么大 ， 跑在 Oracle ， DB2 小型机上也没啥问题 ， 但是最近这几年随着移动支付和电子商务的兴起 ， 数据量越来越大 ， 增长也越来越快 ， Scale-Up 一定迟早成为瓶颈 。 TiDB 在其中正好切中两个很高的价值点：

1. SQL 兼容的能力（尤其在 5.0 支持 CTE 后和 5.3 引入的临时表功能 ， 复杂 SQL 的兼容性和性能得到很好提升） ， 也支持金融级的一致性事务能力 。
2. 横向的计算扩展能力（尤其在 5.0 支持 TiFlash MPP 模式后 ， 解锁了在列式存储上进行分布式计算的能力） ， 理论上只要有足够多的机器 ， 吞吐能够扩展上去 。

对于银行的批量业务来说 ， 令人头疼架构改造问题变成了简单的买机器的问题 ， 你说香不香 。 但是在 TiDB 早期设计的解决方案中 ， 有几个痛点：

1. 大批量数据导入
   • 上一页
   • 1
   • 2
   • 3
   • 4
   • 5
   • 6
   • 下一页

   特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。