开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共1300人左右 1 + 2 + 3 + 4） 3群即将突破 400 (目前387)会关闭自由申请，新人会进4群,另欢迎 OpenGauss 的技术人员加入。
每天感悟
每时每刻我都认为我是正确的，每时每刻我都发现我的认知需要修正，不停的探索，不停的刷新自己曾经的认知，而不是和动物一样吃饱就行正文：——————————————————————————
这是2023年纽约NYC MongoDB大会的第二期，这期的主题是在企业级别从RDBMS 迁移到 NoSQL.
请不要找我要原文，没有原文，音译，翻译水平有限，如有错误，尽请谅解。
正文：
下面我们为大家介绍重量级的，或者都不需要介绍，Rick Houlihan, 他之前在 AWS 工作，现在他是全球NOSQL 技术上的领导，现在我们欢迎他
大家好，非常感谢大家抽出宝贵的时间，来参加纽约2023 MongoDB技术大会，正如刚才那位女士提到的，我在AWS工作了10年，作为NOSQL方面的全球的技术专家，我负责亚马逊零售 NOSQL 技术团队，你们下面的诸位可能会很熟悉，从有关系，到无关系的数据迁移，我的团队拥有最先进的设计模式和最佳的实践开发经验。
我想大家都感兴趣，为什么像 亚马逊这样的大型企业，选择的新技术是NoSQL ,而不是 RDBMS 关系型数据库，那些经过多年验证的数据库产品，实际上当初我们在这个名为 Rolling stone 的项目初衷并不是要替代传统数据库， 而我们的目的是让ORACLE 滚蛋，因为ORACLE的存在让亚马逊的领导非常的难堪，这样一个又贵有X的数据库的存在，让亚马逊的领导每次都需要在演讲台上重塑，aws 有非常出色的数据库服务，然后Larry(oracle ceo), 也站在讲台上反唇相讥，说既然你有最好的数据库服务，为什么ORACLE 是 AWS 最大的服务商。所以最早的这个项目的目的就是让ORACLE 滚蛋。
我们的技术路径就是，数据库是自由的路径，截止到今天我们的很多数据库工作都是在进行数据库的关系建模，归根结底我们的工作就是要让人们认识到，不存在关系性数据这类东西，非关系型的数据就和无线频道之间的空间传输一样，关系本身只存在于查询的时候，以及如何对这些关系型进行建模。
建模是否适合你，关系型数据库是否适合你，我们是否可以有效的进行设计，一旦你认识到我们再以全新的方式来定义，今天我们要谈的即使，The great migration ,why nosql ?
我们迁移路线是否正确，我们迁移的基准点在哪里，我们如何关心开发的模式。
台下很多人可能会说，AWS 就是云企业，你们迁移到NOSQL上很简单，实际上你们是错误的，AWS 诞生于1995年，他是开发面向服务架构前就存在的公司，价值50亿美元的企业，所以我们并不是你们想象的我们有很多传统的技术，各种堆栈，以及基于应用开发的大型的服务，我们要摆脱这一切是从rolling stone项目开始的，让ORACLE 滚蛋，我们曾经是Oracle 许可证拥有最多的企业，在2018年达到了顶峰 3000 多的ORACLE 上部署了10000个应用，当我们拆分这些服务的时候，我们发现工作量超级大，这个项目超级大。同时传统数据库项目的成本问题非常高，在转换了NOSQL后为什么同样的成本上，运行的工作更多了，效率更高了，这就是我们转换中的一些感悟。
（注明：这个老头的确是一个演说家，后面说的一些关于数据处理的历史问题，这里就不进行翻译了，大致意思是在数据库领域发展是曲折的，每次的发现数据处理瓶颈的开始都是一个新的技术产生的契机。）
在数据库发展的历史中，我们对于关系型数据库的依赖来源与廉价的CPU ，因为关系型数据库强依赖与CPU ，廉价的CPU 给关系型数据库的数据处理带来了强大的，传统数据库的依赖对象是硬件产品，强依赖，而NOSQL 数据库依赖的数据建模，这是这两种数据库产品最大的不同。从成本上，NOSQL数据库本身可以在好的建模设计的基础上，大量减少硬件的投资。
你们可以看看关系型数据库的推动者，你们看一下上面的图左面的图，这是当今全球最大的数据计算群前500，他们在技术的投入petaflops 或者叫浮点计算，已经不在遵从摩尔定律了CPU的能力被挤压到 10年没有符合摩尔定律的规则了，为什么因为CPU的性能提升趋势已经接近平缓了。为什么因为成本的原因，（这里讲了CPU的成本）为什么他们降低了5纳米的研发速度，因为3纳米的的晶圆每片 3万美元，CPU的成本上升，效率降低。我们能看到的是存储越来越便宜，CPU的成本越来越贵。这不是一个新闻，这是事实。
Edgar Frank 发明关系型数据模型，其中数据的范式就是要批量的规范化数据，和数据的通信的方式，去除冗余的数据，但是他本人也谈论过反范式的效率，如果你在系统中存在冗余的数据，你将大幅度的对于某些查询在CPU 方面进行提高。
埃德加·弗兰克·科德（Edgar Frank "Ted" Codd，1923年8月19日-2003年4月18日）是一位英国计算机科学家，曾在IBM工作期间发明了数据库管理的关系模型，为关系型数据库和关系数据库管理系统打下了理论基础。他在计算机科学领域还做出了其他宝贵的贡献，但关系模型作为一种非常有影响力的数据管理通用理论，被广泛提及、分析和赞誉为他最为著名的成就。
这点就印证了在开发NOSQL为数据库基座的应用产品，你可能想的是提高查询的效率， Edgar说运行100次 ，运行1000次这是我关心的成本的问题。每天，每周运行一次，我才不在乎什么运行效率。SQL的口头禅就是，在最重要的地方最大化效率。所以这个人告诉我们上面那张图的标准化成本的 ERD，实际上我们为什么没有遵循 ERD的理论，还是依赖了CPU 效率的提高，满足了我们不使用ERD 某些的理论。
但是在进行AWS 应用程序的拆分中，我们发现关系型数据库本身和工作负载之间存在着成本效率的差异关系。在我们的工作中，如果你的对未来的查询是什么不清楚的情况下，传统数据库是一个好的解决方案，尤其OLAP，这些是对运行的时间不存在要求的。他们可能是对数据进行分析或帮助后台寻找一些潜在的问题之类的数据查询，没有人关心他是在10毫秒还是100毫秒内返回。
而NoSQL要工作的地方和传统数据库是不存在矛盾的，NoSQL 不构建SQL ，对于大规模的OLTP，我们将为高速查询优化查询的数据模型设计，和MongoDB 一样，通过分片进行扩展，同时从 MongoDB Altas你可以用SQL 来读取MongoDB 来支持OLAP 的工作负载的工作。通过MongoDB 开发人员只需要学习一个 API 就可以了，而不是10个，通过一个API 就可以完成大部分的工作。
关系数据库是怎么设计，运行和维护的，实际上在我们AWS进行数据库转换中，3000个实例的ORACLE 中，70%的数据查询都是单表查询，实际上很多数据被写入，并没有被读取过，最后我们分析发现10%的查询是JOIN 的查询模式，非常的昂过的查询模式。
这是一个产品的目录，我们来看看如何将这些产品目录的数据存储在关系型数据库，我们可能会在这些表中分解内容，我们这里会有一个产品表，里面存储不同类型的产品，这些表有一对一的链接，专辑和曲目之间有一对一的链接，在此之间演员之间有多对多的链接，如果我们考虑一下系统如何访问他想要的，按照类别来选择产品，可能按照价格排序或按某些特定的属性进行排序等等，所以我不想要的数据也被卷入到计算中，这就是为什么很多传统数据库前面会放置一个缓存，因为我知道每次查询数据的成本很昂贵，现在我不需要这样了，同时原来我还需要通过ETL 来将数据传输到另一个数据库上，还要确保数据的一致性，现在我也不需要了。以前我对产品的列表需要进行关系的设计和查询，现在我不需要了我只需要一个Documents 就存储了产品的列表。
以前我们建模讨论时间复杂度的问题，然后把代码编译好，去找关系型数据库，然后你的应用程序 和 你的数据库存储之间的中间层抽象层，数据被分散的存储，在进行重组进行查询，这些查询被转换为时间的复杂度，我在传统数据库中看到的就是一个表和多个表有关系，一对一，一对多，多对多，等等然后在重复上面的额关系，时间复杂度在复杂查询里面，直接爆炸了，这就是传统关系型数据库。
我们在回过头看看NOSQL ，我们首先讨论的是键值的访问模式，当然我们不止讨论这个，应用程序讨论的访问模式有很多种，但是键值的查询的速度是最快的。（后面讲了一个例子，如何将传统数据库中的JOIN 多表，在MongoDB中通过重新设计建模的方式进行数据查询方式的重新设计），比如建立索引表，将原有的多链接查询变为简单的索引查询，通过这些设计，我们降低了CPU 额外的消耗。
在上周我们的电话会议上，金融机构Temenos 他们的全球金融服务运营完全架设在yugabyte 和 mongodb 两种数据库上，基于之前的传统数据库的硬件需求，与他们在转换新的开发模式和使用mongodb 后，整体的硬件设施，削减了一半，每秒负载 150000 个事务，为什么他们能减少硬件，因为他们把 JOIN 都取消掉了。
现在越来越多的和我们当初在 AWS 一样的项目，正如我们提到的，一些在转换了开发方和数据库的使用后，在数据库基础架构方面的支出，与2017年一样多，并未增加。就像我所说的，现在企业中最大的IT花销就是数据库，我们能够降低正在执行查询的时间的复杂性我们就可以降低数据库基础的成本。
实际上如何执行这个计划，其实很简单我们现场有没有DBA ，来回答我一下，开发人员有几个懂SQL 和 懂RDBMS数据库的，或者对于关系数据库的建模他们擅长吗？ 台下有声音，NO 。
这些开发根本就不知道怎么建立关系，怎么建立索引，怎么优化，开发很难掌握这些，程序员需要的是对象，对象 ，对象，他们熟知怎么构建对象，我们的数据库就是面向对对象的反映了应用程序需要的数据。看上图的一个曲线，在两个技术都需要学习的情况下，开头是一样的，都很难，但后面，适合的技术给你带来的不是，干了半天不知道那是个什么东西的情况，NOSQL数据库跨越了这个鸿沟，可以说MongoDB 在这个领域属于外太空的科技，但现在还有很多人，不知道也不知道如何使用这项技术。虽然我这样说，但是我不是销售，我讨厌销售，我不会告诉你，来你来消费MongoDB吧， 我所做的事情就是让你们了解有这样的技术，适合你的开发团队并且我们要做的就是和你们聊聊天，然后你们的开发人员恍然大悟，原来还能这样解决问题。这就是我今天所有TALK 和大家分享的关于NoSQL 我知道的东西。
注：后面他说的太快了，跟不上，并且说的与数据库无关，但口才真不是一般的好。
