11 | NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？

精选留言(38)

• 

  Richeir 置顶

  这一节学到了很多新东西，感谢唐老师的总结！

  2019-10-11

  

   4
• 

  jiangjing

  希望可以深入讲解nosql的业务使用场景，比如微博用户关系具体如何使用，模型定义。尤其是该使用场景，如何做到关系数据库不好实现的功能
  

  2019-10-12

  

   9
• 

  Lion

  我们正有这些痛点，思路不错，能更深入一些就更好了！

  2019-10-11

   1

   8
• 

  无形

  之前在讲座业务重构中，用es查询数据，其他组的小伙伴维护的es，但是es性能不行，where条件里七八个字段，排序两个字段，查询es基本两千左右QPS，难以支撑支撑十几万人的直播讲座，而且直播人数增长很快，es已经成为了性能瓶颈，查询条件是类标签的，比如几年级，哪个学科，直播类型，还有时间类的，对于这些字段我是可以打标签的，还有开始时间、结束时间，根据类标签的查询特点，我使用了倒排索引+ roaring bitmap 来过滤，使用快速排序对多字段进行排序。使用类延时队列来完成时间的检索。整个检索过程在微秒级，而且对查询的结果做了缓存，查询条件相同的直接从缓存中取，避免了重复检索和排序，查询缓存会在讲座下次修改，更新倒排索引之后清空。重建查询缓存。重构完讲座的检索性能达到了几十倍的性能提升

  作者回复: 👍👍👍

  2019-11-01

   5

   4
• 

  jc9090kkk

  感谢老师分享，对于文中的知识点有一些疑问，希望老师能解答下：
  1.采用LSM树的nosql，跟mysql的WAL机制类似，mysql通过redo log和bin log的两阶段提交来保证数据的crash-safe，那么nosql的日志是用来做什么呢？也是为了做数据恢复的吗？
  2.像Hbase这样的nosql，涉及的初衷应该是为了做统计而设计的，它支持事务吗？如果支持的话，使用场景是什么？事务的隔离级别都有哪些？因为以我的理解，统计业务，基本都是读请求，很少有写请求，用事务的场景应该极少吧？
  3.因为nosql相比传统的关系型数据库来说，拓展性更好，那么就更适合做分布式系统？后期老师有想法讲一讲比如类似redis或者mongoDB这样的系统，分布式系统的一些实际经验或者说踩过什么坑么？很想了解下。。。
  
  思考问题：
  公司现在用的nosql包括Redis，ES，Kafka，ClickHouse，采用Redis是用来做cache和秒杀活动，也会有一些异步化的处理，采用Kafka+ES是一是为了采集业务端用户行为，二是ES+Kibana可以提供可视化的数据分析平台供运营部门使用，而且ES在后期的水平拓展的方案上来讲配置和维护比较简单（相比Sphinx而言），为什么采用是因为公司之前接的是第三方的数据统计平台，后期发现统计需要单独定制而且会污染业务代码不好维护，而且有时候会发现数据日志还有丢失的情况导致数据统计异常，所以采用Kafka+ES一起来支撑，从而将业务端的一些耦合较重的埋点逻辑分离出去便于维护，CLickHouse主要是为了生成一些离线的数据报表。

  作者回复: 1. LSM使用WAL也是为了恢复memtable的数据的
  2. 是不涉及事务的
  3. 好的呀~

  2019-10-11

  

   4
• 

  Y

  老师你好
  业务中有个模块写极多读少，这种情况下是不是直接把这个数据拆分出来用单独nosql存储比较好？还是先写到nosql，再慢写到mysql好？
  如果慢写到mysql一是可能会出现数据不一致问题，二是写请求会积累很多，内存型nosql支撑不住，可能要用leveldb之类的，磁盘多了一份数据，等要迁移的时候又增加了运维管理成本
  

  作者回复: 如果是长期都是写多读少，那么可以考虑nosql
  如果是瞬时峰值的话，还是用消息队列削峰填谷

  2019-10-30

  

   2
• 

  旅途

  学到了很多 第一次知道nosql快是因为索引，顺序io,赞赞赞

  2019-10-11

  

   2
• 

  yaomon

  目前的项目就是 MySql 配合 Elasticsearch 使用。Elasticsearch主要是做搜索用，写还是 MySql，同时发Kafka消息，消费端写ES。ES存在丢数据的问题，所以会定时全量/增量从 MySql 中捞数据，覆写 ES，保证数据的一直性。

  作者回复: 是的 应该是这样

  2019-10-11

   2

   2
• 

  gogo

  老师您好，你文中微博关系的例子中提到传统关系型数据库扩展性的短板，又说明了nosql有很好的性能和扩展性，请问拿微博关系的例子来说，是可以单独用nosql存储呢，还是既要存在nosql中又要保存在msylq中呢？

  作者回复: 大部分放在mysql，像是粉丝数据是在nosql
  

  2019-10-11

  

   2
• 

  饭团

  老师，再问个问题！如果一类数据需要在nosql和关系形数据库都存储，需要存2次吗？现实开发中这样的情况多吗？能举个例子吗？

  作者回复: 是的呀 比如你的业务数据放在mysql，索引数据放在es

  2019-10-11

   1

   2
• 

  饭团

  老师，是不是这个意思：
  首先不管是sql数据库还是nosql数据库，提升写性能都是靠的将随机写转化为顺序写！在这方面mysql使用WAL机制已经做的很好了！但是关系形数据库主要是在扩展性方面有缺陷！相对于除了kv型的nosql数据库，其他类型的和mysql性能都差不多！
  感觉mysql主要是在扩展性上有所欠缺！

  作者回复: benchmark结果来看，nosql的写入性能要好一些

  2019-10-11

   1

   2
• 

  XD

  老师不提一下tidb？

  2019-11-03

  

   1
• 

  ChenLicong

  关于《使用 NoSQL 提升写入性能》的那段，我还是有点想法：
  即使是NoSQL的一些组件，假如是写磁盘的话，再怎么优化改进，也跟MySQL等传统的关系型数据库的写入性能差不多，都是同一个量级的。
  Redis、MemCache等NoSQL数据库之所以读写性能高，是因为直接读写的内存，跟关系型数据库读写磁盘（也会缓存部分数据在内存中），利用的物理资源的性能都完全不是一个数量级。跟具体操作的物理资源的特性关系比较大。

  作者回复: 在实际运用中，nosql数据库比如leveldb确实比mysql有后来更好的写入性能

  2019-10-16

   2

   1
• 

  longslee

  打卡。咱用到了ElasticSearch和Redis。 选用ES是用来存储海量的，从Kafka入过来的。 Redis用于一些逻辑的过滤或者按时间聚合。 踩过的坑呀，我不知道算不算坑，还是说我们运维能力不够，Redis分布式以后，某个Key在哪，要去好多地方查- -

  作者回复: 怎么会呢，分布式之后应该可以知道某个key在哪个分片上

  2019-10-14

   2

   1
• 

  Liush

  老师你好:
  其实我对什么时候使用SQL,NOSQL,或者是NEWSQL一直存在很多疑问，就比如微博来说，每天微博增加的博文数量应该是非常大的，如果这部分用关系型数据库来存储是不是分库会很快达到瓶颈？这样会造成重新迁移分布数据,如果手动去迁移分布这部分数据，由于存在大量的历史数据迁移时间是否又是一个问题呢？像微博博文这部分是存储在SQL中还是NOSQL中？如果用nosql的话后续只要简单的将节点加入集群即可，auto sharding的特性会方便很多。如果按照我的理解在电商领域中，订单是核心系统，而且和订单系统关联的商品等数据，这部分使用关系型数据库分库分表的方式去处理，因为这部分系统需要保证事务，但是像商品详情这部分并不需要强事务的数据是否可以存储在NOSQL中？谢谢

  作者回复: 微博的博文是放在MySQL里面的，其实博文的数量没有关系那么夸张，而且热点明显，用户很少会翻之前的微博。
  订单的数据可能和博文的数据相当，我觉得放在mysql中应该就够了

  2019-10-14

  

   1
• 

  大鸡腿🍗

  有点异议：原文说主键可能会随机IO，但是我觉得既然聚集索引物理，逻辑都有序，应该是顺序IO才对呀，老师

  2019-12-02

  

  
• 

  布小丫学编程

  工作中使用过的Nosql数据库：
  ES，主要用来解决首页查询，通过logstash同步各个表的数据到ES，然后根据关键字进行查询。还有关键字联想也做了。
  Redis主要用来做缓存的，提高查询效率的，还有秒杀也会用到缓存先减库存。
  MongoDB主要用来存储非关系型数据，比如节点下再有节点。还有使用它来计算坐标点的距离。

  2019-11-19

  

  
• 

  海罗沃德

  使用MongoDB作为一个中间层，把前端需要的跟展示页面相关的数据都按照JSON格式保存起来，后端通过消息队列的形式从实际业务数据库中读取数据维护MongoDB中的数据，前端写入数据时候也是直接更新MongoDB的数据，然后给消息队列发消息，让后端异步的去更新数据库，同时MongoDB中通过定时任务保证只存储热数据，超过10页以上的数据移动到AWS S3这样的文件存储系统中作为冷数据保存
  
  在非支付的业务场景下，这样避免前端直接查询和写入数据库，是否是一个可取的方案，老师对这样的方案有什么建议么？

  作者回复: 其实这就是把MongoDB作为“缓存”了，是可行的
  不过从描述来看，前端写入数据会更新MongoDB，再异步更新数据库；然后还会有一个消息队列会从业务数据库读取数据更新MongoDB，这两个是不是有重复？

  2019-11-04

  

  
• 

  XD

  对于mysql，插入时使用自增主键+WAL，更新时配合changebuffer似乎可以解决随机io带来的性能问题？

  作者回复: 可以缓解

  2019-11-03

  

  
• 

  无形

  之前单表热点数据接近亿级，查询时间达到了8秒左右，后来进行了分表，按照ID取模分了一百张表，历史数据取模插入到分表中，新建了一张表用来保存全局唯一ID，每次新建热点都会更新全局唯一ID，保证分表之后ID唯一性，查询使用es，GitHub上找了一个开源的MySQL数据同步到es的工具，模拟的从库，保证了数据同步的实时性，热点数据查询性能降低到了1秒内。性能得到很大提升

  2019-11-01

  

  