许老师对存储和架构的理解确实不一样：开始学时还有些诧异为何只有此门功课的课程之间间隔相对较大；一路学来一路梳理，每次学完都会觉得有些疏漏需要自己去补；最终发现其实讲的太快根本无法理解所学的知识。
       最初的学习目的是因为当下的数据系统和中间件有问题：之前自己在其它电商和金融业的经验无法移植，虽然系统放在云上，可是还是有性能问题，刚好老师的课开课，就带着求知欲来学习；课程开课到现在5个月了，学习老师的课程之余带着困惑把相关的知识顺带把相关知识梳理了一遍，前几天刘超老师的操作系统跟完了；自己把部分最关心的知识再看第二遍时才理解老师的讲解。最终发现某些困惑是因为自己的理解不够深度和广度，深度和广度铺开了且研究了有些东西就明白了；还有就是其实业界一直有个问题，对于某些知识/系统的标准划分其实蛮混乱的，这同样造就了典型问题本质相同的东西会因为包装不同而被叫成2种东西，不知道老师是否有这种体会？我自己作为一个一直混迹于中小企业近10年的DBA兼OPS对此深有体会。
        关于存储中间层：其实这个定义老师应当是从物理层去划分的吧？其实关于这块选型我一直在研究存储中间层的选型：最近更是用了1个多月完全钻在里面，翻阅了不少书籍和看了一些极客时间里面其它老师的课，其实从设计层而已我们可以称为"数据系统"-这个概念其实是源自蔡超老师推荐的一本书籍中看到的;这个名词学生觉得更贴切-至少是设计层，无论是RMDB、NOSQL DB、MQ核心都是以数据为中心，他们的发展历程其实完全依赖的是硬件的发展-尤其是MQ。
       根据发展历史其实关系型和非关系型的概念其实是同时提出：不过由于历史原因以及硬件原因，RMDB首先发展起来了，NOSQL DB的发展源自内存的代价不再那么庞大，随着服务端的模式的改变以及分布式设计的出现MQ开始彻底出现；故而现在其实三者是相辅相成，老师今天提出API，其实差的系统都有一点共性：API写的很差，RMDB、NOSQL DB、MQ的读写比例、调度机制设计的再合理扛不住一个烂的API的一个操作，前段时间公司某套系统内测时就碰到过接口程序写的太烂直接把数据库和操作系统资源跑崩的情况。
        其实我现在非常好奇的是一件事情不知道许老师是否有所关注：其实现在很多的瓶颈已经从过去我们设计数据系统/存储中间件时硬盘、内存变成了CPU，AI 的聚焦其实一定程度上同样在CPU上：毕竟它有20年没有真正提升了，内存的廉价化其实已经让过去的数据库+数据仓库变成了NOSQL DB+ RMDB，CPU未来的提升会给现在的系统再次带来怎样的变化？
      今天是教师节：谢谢老师一路来的辛勤付出，祝愿老师节日快乐。