ahern882020-06-15是不是可以基于时序数据库如InfluxDB或OpenTSDB做更加合适呢？作者回复: InfluxDB和OpenTSDB都是时间序列数据库，当然可以做到。OpenTSDB是基于HBase的，HBase原理和Cassandra相似，都是基于列的数据库，都适合存时间序列数据。
6
平凡的世界2020-10-17mysql表设计这个有点没看懂。1.这里好像只有聚合表，没有开始说的每个视频事件单独存储的表。2.space_info一般有些什么字段为什么要单独做一个表。作者回复: 你好，视频中的mysql表设计只演示了聚合数据，一般原始数据可以考虑单独存ES或者Cassandra/HBase等NoSQL数据库。 space_info存放空间相关数据，比方说空间名称，我的视频，我的文章等，可以参考波波在B站上的空间：https://space.bilibili.com/518029478
2
空空如也2020-06-28最近在用TimescaleDB，这个场景也适用的。它支持自动按时间列分区，插入和查询的性能单机就很高。 优势： 1.标准sql查询，学习成本低。 2.查询性能高，数据量越大优势越明显 3.面向时间的特征，支持大量时间的方法 4.写入快，且不受数据量影响，官方数据111 K/s 5.支持持续聚合，可以近实时保存指定时间范围的聚合指标。 6.支持时序数据表与关系型数据表join如图中的Video_Stats可以改为时序数据表，其它关联表可以不变。 劣势： 1.多节点集群写暂不支持，功能正在开发中 2.其它缺点（其它人总结吧）作者回复: TimescaleDB是在PostgreSQL基础上，针对时间序列场景的扩展，完全可以实现分布式计数服务。
2
三尾鱼2020-06-22如果一个事务中有读有写，那么读写分离的场景，读和写会分别访问主库和从库，还是都是访问主库？分别访问的话会不会有数据不一致的问题作者回复: 读写分离以后，系统就引入了分区，根据CAP原理，在P分区的情况下，CA不可兼得，需要做出牺牲，如果要可用性A，那么一致性C就需要牺牲，如果要强一致性C，那么可用性A就需要牺牲。 后面第四章会讲分布式事务和一致性问题，请耐心等待第四章。
2
ple2020-06-19想知道主从分离如果保证高可用，那为什么不直接多台机器集群。如果是为了高性能，让查询更快，读从库减少主库压力，那为什么不用分表，或者加缓存解决？主从分离有没有一种特殊的适用场景？作者回复: 你好，像mysql主从+读写分离，是目前互联网企业普遍做法，我之前工作过的公司像携程/拍拍贷等，大量应用mysql主从+读写分离。分表分库和缓存可以部分解决性能问题(课程第三/第五章有案例)，但不能解决所有性能问题，有的时候还是需做DB层的主从+读写分离。课程第四章会讲到CQRS技术， CQRS可以认为是服务层的一种读写分离，在大规模微服务架构中有很多应用场景，第四章我会进一步介绍。 像mysql MHA之类的技术，是可以做到主从高可用的，一主二从，主如果挂了，其中一个从可以自动升级成主，具体细节可以查网上资料很多。
共 2 条评论2
托尼斯威特2020-07-13表结构设计 "聚合数据"表有三列, 怎么理解Timestamp这一列? 是最后更新事件, 还是聚合数据所属的一分钟? 看视频似乎是第二个, 可是这样要查询总的观看数, 依然要把每分钟的观看数加起来呀? 是否还需要一个总的聚合数据表加速查询?作者回复: 对，第二个表中的timestamp表示每分钟的聚合数据。 如果要查询总的观看数，后面在后台还要进一步聚合每小时/天/月/年的数据，这样可以加速查询。
共 2 条评论1
loris2020-07-04nosql数据模型设计和数据读取模式有很大关系作者回复: 当然，数据模型设计一定要考虑读写模式。
1
D.2020-06-25消息中间件需要考虑消息丢失，补偿机制吧？作者回复: 现代消息系统比如Kafka，只要写入了可以保证不丢消息。但是生产者客户端因为网络等因素，可能会重发，造成消息重复，所以消费端要做去重或者幂等处理。
1
远方2020-06-20为什么不用hbase，也是高可用的，而且运维人员多作者回复: 可以用hbase，还有基于hbase的opentsdb也可以。课程只是演示用cassandra，也是可以的。具体看公司的现有技术栈和运维能力等。
1
SuperSu2020-06-15shardingsphere跟cetus能否对比下？作者回复: 分库分表中间件，其实原理大多类似。shardingsphere java开发的，开源时间也比较久，社区生态也比较好(Apache背书)，文档也不错，国内企业落地案例多，生产应用推荐。cetus是c开发，号称性能第一，开源时间不长，可以关注。
1