共计 3114 个字符，预计需要花费 8 分钟才能阅读完成。
置信大家看完上周「分布式系统之美」知乎圆桌精选大放送后还意犹未尽，新的一轮热门探讨已被小编盘点下来，快来追随小编一起看看有什么新的答案吧。
精选问题 & 答复
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 不见不散！查看下方海报获取更多直播详情。
