「分布式系统之美」知乎圆桌精选大放送第二期｜不要放过任何你感兴趣的话题

相信大家看完上周「分布式系统之美」知乎圆桌精选大放送后还意犹未尽，新的一轮热门讨论已被小编盘点下来，快来跟随小编一起看看有什么新的答案吧。

精选问题 & 回答

1. MySQL 单表日均 15 万数据,主要用来存储数据。有什么可靠的方案？

作者：cx3ptr （伴鱼基础架构负责人）

单表、单日 15w，一年数据是 5000w，三年是 1.5 亿，从数据量的角度来看并不算大。“主要是存储数据” 可以认为没有复杂的计算，那就从容量、高可用两个角度来阐述下吧。

容量方面: 保存三年热数据

1. 字段少且简单：直接用 MySQL 来扛也没问题，超过三年的冷数据逐渐归档到 hdfs、s3 之类的文件存储上或者 Hbase 上作为冷数据提供查询。

2. 字段比较多或容量增加比较大：这里其实假定单机容量、IO 性能达到瓶颈，需要进行分片存储，也就是常说的分库、分表操作。以分表为例也有几种方式: hash、range、日期，hash 方式比较均匀，但是扩容不方便，只能进行翻倍扩容(像是 vitess 具备 resharding 能力，也是我感觉 proxy 里做的最好的，这种可以任意增减分片扩缩容量)，rang 方案没有扩容的压力，但是不能缩容并且随着时间的推移，最近访问的范围往往会成为热点，如果是 IM 业务我们可以按照日期进行分表。当然分库分表也有客户端、proxy 代理、data mesh (趋势，很少用)几种方式，可能因为自己做中间件，我比较喜欢 proxy 的方式，控制力比较足、业务侵入小，方便架构、运维统一治理。这类 proxy 有很多 vitess (部署难度比较大，但是功能很强大)、kingshard、gaea、shardingsphere (好像也有 proxy 方案)、mycat 等...

我以前也搞过 kingshard、gaea，中间件方案搞起来是真挺痛苦的，加入分布式事务、resharding 功能也挺难的，所以如果有容量问题，还是比较推荐 TiDB 的...

扫描二维码查看完整回答

2. 什么是云原生数据库？

作者：笨猫儿 （送外卖的资深互联网 DBA，热爱 MySQL、分布式数据库）

云数据库时代，云厂商承接了数据库的基础设施支撑，把传统 DBA 从日常繁杂琐碎的运维工作中解脱出来，我理解中的云原生数据库包括以下几大特性：

（1）自动容错：故障可自愈，包括宕机自动迁移，故障隔离，异常流量自动调度，负载均衡，自动限流降级等。

（2）弹性伸缩：能够根据业务 CPU Load 负载自动伸缩，做到秒级扩缩容能力，灵活动态分配或释放资源，结合弹性计费策略，可以大幅度降低用户的使用成本。

（3）弹性计费：支持按量（如流量，存储量，调用次数，时长等）、固定的如年/月/日/时…等多种定价策略，成本低廉可控，可根据业务情况灵活匹配出一个最优计量模式...

扫描二维码查看完整回答

3. 目前有哪些先进的存储模型适合 HTAP 数据库？

作者：韦万 （TiFlash 存储负责人）

利益相关：TiDB 研发一枚。

业界关于 HTAP 数据库适合的存储模型，徐文起同学的回答概括的挺全面，点个赞。当前也有其他的数据库在宣传 HTAP 的概念，这里就不一一列举了。

在数据库领域，OLTP 我们通常理解为需要较低 Latency 和较高 TPS 的业务，一般每条 SQL 涉及的数据量较小，比如在线购物对物品的增删改查操作；OLAP 则通常是指对大量数据的分析、处理，比如统计当前所有在售物品的平均销量。而我们称一个数据库属于 HTAP （Hybrid Transactional Analytical Processing）数据库，它应当同时拥有 OLTP 和 OLAP 的能力。我们这里只讨论关系型数据库，因为它应用最广泛也最流行。

TP 和 AP 很纠结

我们这里只讨论存储模型对 TP 和 AP 业务的影响。

我们知道关系型数据库，基础的数据模型是以行和列组成的一张张表。通常行有一个唯一标识 Row Id，且存在有限个字段，字段就是列的值。行数可以达到非常大的量级，而列数通常是有限的...

扫描二维码查看完整回答

4. 如何用形象的比喻描述大数据的技术生态？Hadoop、Hive、Spark 之间是什么关系？

作者：Xiaoyu Ma （工程师 @PingCAP）

大数据本身是个很宽泛的概念，Hadoop 生态圈（或者泛生态圈）基本上都是为了处理超过单机尺度的数据处理而诞生的。你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，虽然奇怪的组合也能工作，但是未必是最佳选择。

大数据，首先你要能存的下大数据。

传统的文件系统是单机的，不能横跨不同的机器。HDFS (Hadoop Distributed FileSystem)的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取 /hdfs/tmp/file1 的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS 为你管理这些数据。

存的下数据之后，你就开始考虑怎么处理数据。虽然 HDFS 可以为你整体管理不同机器上的数据，但是这些数据太大了…

那什么是 Map 什么是 Reduce？

扫描二维码查看完整回答

5. 学计算机专业的你后悔了吗？

作者：kylin （伴鱼技术中台负责人）

看到这个问题的时候，才恍惚又想起报考计算机专业的原因。2000 年前后的无数个深夜里，昏暗嘈杂的网吧里面，一群小镇青年正在「星际争霸」游戏中大杀四方，4 VS 4 已经在镇上找不到对手了，又一局团战胜利后的间隙，不知道谁一句，以后学计算机专业是不是可以天天打游戏，心想要这样真嗨啊，可以光明正大的玩游戏，不用东躲西藏，不用翻围墙，这样的好事谁能不干？想想我们为了好好玩一把游戏所经历的惊心动魄，哪有人能不心动呢？

1、寝室在二楼以上，晚上查寝后楼梯门被锁下不去怎么办？人多的时候，大家把被子都拿出来，一床一床铺开往下丢，厚度足够了后，然后从二楼跳直接下去；人少的时候，从排水管爬下来，有一次一个同学快爬下来了，被一楼老师的手电筒照到了，立即再迅速的爬回二楼，吓得老师紧张得喊“同学，慢点，慢点。”

2、翻学校围墙出现的一些情况…

扫描二维码查看完整回答

6. 未来的数据库是什么样的，应该有哪些特征？

作者：孙晓光 (知乎)

未来的数据库在每个人心中可能都有不同的见解，带着个人对未来数据库产品的期望和工作中遇到的需求，尝试聊一下个人对未来数据库最期望的几个特征。

Geo Replication & Transparent Location Awareness

在业务规模增长到一定程度后，不论是从容灾还是改善用户体验的角度看，基础设施层面引入异地多机房甚至是跨云厂商的多机房是一个必然的选择。然而异地多机房架构在带来更强的可用性和扩展性保证的同时，也为业务开发带来了新的挑战。用户、服务和数据的地理位置分布情况组合在一起，放大了整个数据访问链路的问题规模。在 Geo Replication 的帮助下服务可以确保本地一定拥有一份可以高速访问的数据，再配合 GSLB 解决服务和用户的地理位置匹配问题，整个端对端的业务路径上都可以就近地提供服务改善用户体验。一个具备 Geo Replication 能力的数据库，同时也应当具备数据地理位置分布的全局掌控能力。可以为服务提供透明的地理位置感知能力，自动选择适合当前服务所在地理位置的数据库副本来支撑业务。

Super Scalability

...

扫描二维码查看完整回答

「分布式系统之美」线上圆桌直播来啦！周三晚上 20:00 不见不散！查看下方海报获取更多直播详情。