2018-06-04关于NoSQL，看过一张图，挺形象：“1970，We have no SQL”->“1980，Know SQL”->“2000，NoSQL”->“2005，Not only SQL”->“2015，No，SQL”。目前，一些新型数据库，同时具备了NoSQL的扩展性和关系型数据库的很多特性。
关系型和NoSQL数据库的选型。考虑几个指标，数据量、并发量、实时性、一致性要求、读写分布和类型、安全性、运维性等。根据这些指标，软件系统可分成几类。
1.管理型系统，如运营类系统，首选关系型。
2.大流量系统，如电商单品页的某个服务，后台选关系型，前台选内存型。
3.日志型系统，原始数据选列式，日志搜索选倒排索引。
4.搜索型系统，指站内搜索，非通用搜索，如商品搜索，后台选关系型，前台选倒排索引。
5.事务型系统，如库存、交易、记账，选关系型+缓存+一致性协议，或新型关系数据库。
6.离线计算，如大量数据分析，首选列式，关系型也可以。
7.实时计算，如实时监控，可以选时序数据库，或列式数据库。展开作者回复: 求原图😃
138
2018-06-03No SQL并非银弹，如ACID方面就无法跟关系型数据库相比，实际运用中，需要根据业务场景来分析，比较好的做法是，No SQL+关系型数据库结合使用，取长补短。如我们之前的做法是将商品/订单/库存等相关基本信息放在关系型数据库中(如MySQL，业务操作上支持事务，保证逻辑正确性)，缓存可以用Redis(减少DB压力)，搜索可以用Elasticsearch(提升搜索性能，可通过定时任务定期将DB中的信息刷到ES中)。 21
2018-06-03需求驱动架构，无论选用RDB/NoSQL/DRDB，一定是以需求为导向，最终的数据存储方案也必然是各种权衡的设计妥协。
没有银弹，因为不同的应用需求对数据的要求也各不相同。当前我们不可能找到一个存储方案能满足所有的应用需求，但是我们可以通过认识到各种存储方案的优点与缺点（陷阱），在实际应用中，根据应用场景的不同要求（比如对可用性、一致性、易用性、支持事务、响应延迟、伸缩性等），按照上述特性要求的优先级排序，找到最合适的方案并“混合搭配”使用各种数据存储方案。
多种方案搭配混用必然会增加应用的复杂性与增加运维成本，但同时也带来了系统更多的灵活性。
举例：传统/互联网金融领域目前就不可能离开RDB。展开 15
2018-06-02看过一些资料，RDB当年（比我还大好多）也是在数据库大战的血雨腥风中一条血路杀出来的。现在回魂的document db当前也是RDB对手之一。如果真有这么多问题，怎么还能脱颖而出，主宰软件开发领域这么久。只能说现互联网和物联网的兴起使得应用场景向海量数据，线下上分析，读多写也多这些情况偏移了，这些场景对ACID的要求很低。
但现在大多数应用的也许还是直接面对用户，要求数据有一定可靠性，数据总量和并发量并没那么高。RDB技术成熟，人才易得，声明式SQL语法让开发者忽略底层实现，关系型的模型也符合人的思考模式。而且现在大多数一流的RDB都集成了基本的文档存储和索引，空间存储，全文检索，数据分析等功能。在没达到一定规模和深度前，完全可以用个RDB来做MVP，甚至搞定中小型也许场景。
从码农的角度看，我还是更崇拜关系型数据库，因为其底层实现里包罗了算法，系统，网络，分布式，数学统计学各种绝世武功。
前几年在NoSQL炒起来没多久，NewSQL的概念又被提出了。现在各路牛人都投入到D RDB的研发中，成型的也有不少。虽然不太可能完全取代现在的各种NoSQL，但也许能收复不少失地。
历史就是个循环，天下大势分久必合合久必分...展开作者回复: RDB的功能是最强大的
15
2018-06-04认真的看到现在，有两点疑问。
1.es和lucene这种，一般当做搜索引擎，也划在nosql里面合适吗?
2.能否给一些常见nosql性能和数据量的数据，
网上搜不大到，唯一知道的都是从ppt里面扣的
另外，nosql那个图原图应该在reddit上，地址是
http://i.imgur.com/lkG9Vm8.jpg展开作者回复: 1. 只要是为了弥补关系数据库的缺陷的方案，都可算nosql
2. 量级一般都是上万，但和测试硬件测试用例相关，如果要用，最好自己测试 10
2018-06-02NoSQL出现的原因是针对解决某一特定问题，这个问题用关系型数据库无法很好的解决。所以就注定了NO SQL不会是个大而全的东西，虽然这几年特性不断增加，使得部分业务场景可以完全不依赖关系数据库，但是关系数据库仍然是最容易理解，适用场景最广泛的数据库。就像OLAP无法完全代替离线计算，HTAP无法完全代替OLAP+OLTP一样，NOSQL是很好的补充，不是为了代替 8
2018-06-02华仔，我们公司刚起步的时候有2个应用，数据库用的mysql, 日志也存储在mysql, 用户增长很快，没有专职架构师，现在准备重构以适应业务增长，考虑jhipster on kubernetes , 昨天同事之间交流了一下方案: gateway + registry + k8s traefik ingress, 通过k8s 实现hipster技术栈的高可用，所有微服务容器化， 第一阶段准备拆成5个service, 在gateway做路由规则和鉴权，日志部分用mongodb, mysql暂时不分库，订单rocketMQ队列化, 这样合理吗？有什么更好的建议?作者回复: 我感觉你们一下子引入这么多对你们来说是新的技术，风险有点大。
8
2018-06-03跨库操作如何做事物呢？看到这期了还是没有答案吗？作者回复: 跨库操作不建议事物，效率低，容易出错，用最终一致性
7
2018-06-18本章最大的收获是了解了nosql数据库的四种类型以及特点、使用场景和关系型数据库的区别，比如redis中的list结构的强大之处、列式存储为什么压缩比会高很多，这也是作者比较强的地方。作为存储数据的系统，肯定有共同的地方，但既然能单独拎出来又说明有不同之处，掌握了相同之处可以快速理解系统能力，了解了不同之处可以明白其使用范围，并且对自己以后的架构设计方案选择提供基础。
自己之前总觉得要掌握一个系统要从看源代码开始，但后来发现这种方式太过耗时，效率过低，就开始转变为了解这个系统主要的能力是什么，然后根据能力去进行拆解，看那些是自己已经掌握了解的，那些是陌生的，对于陌生的部分了解其实现思路是怎么样的，对于实现思路的主要细节看下代码了解，这样有针对性的看效率得到了比较大的提升。
对于本篇的问题，在文章中其实已经说明白了，关系型数据库是不可替代的，比如事务能力、强管控、经常性读取多列的场景都需要关系型数据库。展开作者回复: 这种方法叫做“比较学习法”，对比学习，效果最明显
6
2018-06-14文档数据库和es有何区别，es我看也是对scheme不敏感的啊作者回复: 文档数据库定位于存储和访问，es定位于搜索，但目前差别并不是很大，因为系统边界的扩充，就像mongodb也要支持ACID，mysql也要支持文档存储
6
2018-06-11你好，我有找到一张 history of nosql图档，分享给您。
https://www.reddit.com/r/ProgrammerHumor/comments/2mk8sb/history_of_nosql/ 5
2018-06-05老师您好，问个题外话😂
如今各种新技术层出不穷，像那种底层的大块头之类的书籍，比如深入理解计算机系统，编译原理这样的，还有必要深入学习吗？
像深入理解计算机系里面的反汇编分析在实际工作中确是是用不到，更别提开发个编译器了
面对这些看似不错的书籍，但又觉得里面的内容无法运用到实际中，有些迷茫，望老师指点作者回复: 请到聊聊架构公众号搜索《当我们聊技术实力的时候，我们到底在聊什么》，我写了一篇文章来回答你这个问题
5
2018-06-03mongodb4.0不是支持acid事务吗？作者回复: 官方宣称会实现事务，但需要看最终实现，实现事务不是完全没有代价的，要么性能降低，要么灵活性降低
5- 2018-06-02有个商品搜索的需求，怎么评估elasticsearch和solr哪个更合适？
作者回复: 功能上其实都可以，关键看实时性和性能，如果都满足，按照简单原则，你熟悉哪个就用哪个
4 
2018-09-29关系数据库就是行式存储，从硬盘读到内存的时候，是整行读取，实际上还是整页读取的。不明白这个整页指的是？这个整页指的是 包括很多行数据吗？这个整页的数据都是我需要的吗？作者回复: 为了存储高效，文件存储在磁盘上是分页存储的，每页包含很多行，不一定都是你要的，更多信息可以参考innodb得文档
3
2018-06-28我认为，行式数据库读取的时候，用sql可以指定关心的列，无需读取所有。
所以，这一段是不是笔者笔误？求赐教作者回复: 数据库返回你需要的列给你，但是数据库将数据从磁盘读入内存的时候，是整行读取的，事实上是读取行所在的整页数据
3
2018-06-27mongo4 开始支持事务了吧作者回复: 我不敢用，我相信MySQL😊
3
2018-06-18保险行业用的关系型数据库多些，No SQL少些。保险行业一个重要的要求是数据不能丢失！作者回复: 主要还是保险行业技术不够开放😄，保险行业数据和支付宝相比一下就知道了
1 3
2018-06-06提一个问题，数据本来是存在mysql的，然后将数据同步到es中，中年如何保证一致性作者回复: 更新mysql成功后就更新es，再加一个定时校验
3
2018-12-27华哥，我想问下，我之前在做电商时，将商品全部存到redis中以hash结构存储，同时商品下面有个库存也存在其下面，库存在做减操作时，我用hincrby来进行，并发小的时候问题不大，库存不会超。
并发大了以后会不会数据库一样超了？作者回复: redis本身不存在并发访问，因为是单进程的，但你的业务代码很可能会有问题，例如先get然后判断后再hincrby就会出现并发问题
1 2