凯文·蒙塔尔博：在这段鸡尾酒中，我们将与MongoDB的开发者JoeKarlsson讨论NoSQL数据库。Joe分享了他对NoSQL和SQL数据库的见解，它们的相似之处和不同点，以及您应该在下一个项目中选择哪些。
好的，乔·卡尔松，欢迎来到节目。
乔·卡尔松：嗨，欢迎。欢迎。谢谢你邀请我。
知识管理：非常感谢你能来这里。对我们的播客来说真是一个充满活力的开始。我们跳进去吧。您能告诉我们什么是NoSQL数据库吗？为什么开发人员应该考虑它？
JK：NoSQL不仅是SQL的缩略语，我们刚开始研究其他不是SQL或关系的数据库模型时就出现了。NoSQL是一个庞大的术语，它基本上包括任何不是关系数据库的内容，包括时间序列数据库、图形数据库、键值存储库、基于文档的数据库。我肯定我忘了几个，但是很多。是的，当然。
大卫·布朗：MongoDB适合什么类别？
JK：MongoDB是一个基于文档的数据库.这意味着您不是将数据保存为类似于关系行和列表类型的格式，而是将其保存在文档中。程序员习惯于在类似于JSON的对象或字典中保存和处理数据。我们可以按照自己的想法保存数据，而不必使用ORM在数据之间来回映射。
DB：为什么失去表和关系的概念是一件好事，为什么有人想要转向基于文档的数据库呢？
JK：你不需要摆脱人际关系。它有很多好处，但就像不能直接使用数据库和不使用ORM实际上消除了整个抽象层和连接的累赘一样，粗糙的性能使得处理数据更加容易。我可以用我想的方式保存数据。我不需要来回映射它。直接将数据嵌入文档可以获得一些关键的性能提升，而不是对外键进行连接。
DB：开发人员花费大量时间考虑实体设计。在NoSQL数据库中，您不再需要担心实体设计了，他们基本上可以动态地构建自己的联系人实体，并根据需要添加额外的字段，诸如此类。
JK：其实恰恰相反。对于NoSQL数据库，尤其是基于文档的数据库，我认为这是一个常见的误解。我是MongoDB的开发倡导者和软件工程师。因此，我将从基于MongoDB文档的角度来讨论这个问题。你还得担心。模式设计和SQL开发一样，是提高查询性能和性能的关键环节之一。我认为这是人们在开发或喜欢开发NoSQL数据库时没有给予足够的时间和精力的事情之一。事实上，我今天刚刚在一个会议上谈到了这个问题。这会影响表演。我认为很多人抱怨他们的MongoDB数据库，不是很好的扩展，它是10次中的9次，这是一个模式设计问题，并且确保他们实际上试图重新考虑它。
DB：这如何影响您的文档设计的未来修改？如果您确实想要更改实体中的字段和类似的内容，您应该重新构建文档还是为了保持性能，这是如何工作的呢？
JK：您可以，老实说，我不会像您推荐的那样，但是数据需求和功能需求总是在变化。它们总是在增长，即使使用SQL数据库，甚至像第一天，当您启动它时，很少，六个月到一年之后，就是数据库仍然是您在开始时需要遵循的完全相同的模式。MongoDB数据库也是如此，它是正确的软件，它永远不会结束。
软件开发永远不会结束。它总是被更新，改变，扩展。所以模式设计的改变是，这只是生活的一部分。你无法避免，对吧。即使是第一天，你也是不存在的完美模式。但它会改变的。通常，我们使用SQL数据库运行迁移并对其进行更改，但您可以使用MongoDB对no SQL数据库执行相同的操作。
这绝对不是反模式。然而，您可以暂停它，转储它，然后再次重新启动它。我不建议大多数时候您可能会有一些停机时间，这是没有必要的。我可能会将这些数据复制到另一个dev数据库，然后开始运行一些迁移查询，或者像对所有数据进行迁移更新一样，然后运行查询。
DB：开发人员在模式设计和性能优化方面应该考虑什么？这是与关系数据库相同的考虑因素，还是与关系数据库相同？
JK：这让人感到困惑，所以我将从SQL的角度来讨论它，人们可能熟悉它，也可能不熟悉它。对于SQL模式设计，有非常明确和深入研究的方法。我们通常是通过规范化来做到这一点的。大多数开发人员都归一化为第三种形式。这意味着，与关系数据库一样，您关心的不是如何使用关系数据库。这是你掌握的数据。我不是说这是真的，但我有八个用户，我有一些用户数据，我有一些职业。也许他们有一个课程表，然后说：“哦，我应该把它分开，我们会加入一些，然后用外键。”标准化是我们通常要做的事情。对于MongoDB，模式设计和基于文档的模式设计，没有规则，没有进程，没有算法。
唯一重要的是根据数据库的需要设计模式。模式可能适用于您，但在非常类似的应用程序中，它可能对其他人完全不同。我给你举个例子。我最近才建了一个小猫的垃圾箱。它测量我的猫的体重，随着时间的推移，他使用洗手间的频率。我根据如何使用和读取这些数据来设计模式。有了物联网数据，你就可以记录传感器的数据。我正在用时间序列类型的模式来设计我的模式，这个模式将被优化，以便实时读取图表上的数据。这对我的申请是有意义的。对其他人来说没有意义。您仍然可以映射关系和建模任何您想要的东西。
DB：用于小猫监控的物联网设备，这是你在亚马逊市场上可能看到的一条新的职业道路吗？
JK：我还没辞职呢。我只是在看“连线”，今天市场上有一个机器人物联网垃圾箱。“连线”给了他们10个中的8个，他们的价格是500美元一瓶。如果有人想从我这里窃取这个想法，所有的代码都是开源的。你完全可以去拿它，然后把它货币化。我不会那么做的。我这么做只是为了好玩。我在会议上谈论这件事。
DB：会有很多人对这种事情感兴趣。
JK：我发现这也是真的。到目前为止，它一直是我最受欢迎的演讲和博客文章，也是我最受欢迎的开源项目。
DB：让我们来谈谈关系数据库的设计，关系数据库很好地处理关系，所以它们就是这样产生的。您有一个数据库模式设计，它是高度相关的，比如CRM系统，或者事务性系统(如水管理系统)，SQL数据库通常是首选数据库。对于那些认为关系数据库更适合于高度相关的数据的人，你能说些什么呢？
JK：关于MongoDB的两个最大误解是，它不支持ACID事务，这是错误的。第二，它不支持关系连接，这也是假的。在我们的聚合管道中，您可以做一个连接或者我们称之为一个查找，并且您可以从不同的集合数据库连接数据，没有问题。建立关系不是问题。当您设计MongoDB模式时，您可以做两件事：您必须为每一段数据制作它，要么将其直接嵌入到文档中，要么我使用外键引用它，就像使用关系数据库一样。嗯，我想是这样的，我承认这是一个更新的功能，我们已经听过社区的报道了。
他们已经要求很多年了，所以我们建造了它。我想它已经发布了，就像4.2版一样。您可以使用SQL数据库建模任何关系，也可以使用MongoDB数据库进行建模。实际上，您有更多的灵活性，因为您可以将数据直接放入其中，从而提高性能。如果我不需要进行查找，即使是在SQL数据库中，联接也是非常昂贵的。我不知道你是否知道它是正确的，但是如果我在两个独立的表中有数据，我会加入它们。它基本上把记忆中的所有表格都拉出来了。然后，它对内存中的联合数据集运行一个SQL查询，该数据集在时间上和内存上都是昂贵的，并且可以成为规模上的阻塞操作。但如果你不需要这样做，那是一个巨大的收获。
DB：人们会惊讶于MongoDB也支持ACID事务。
JK：这是我对MongoDB的最大误解，它不支持ACID。我认为，甚至在六个月前，你也可以在岸上对数据集群进行资产交易。所以，你有分布在世界各地的数据。您仍然可以在此上运行ACID事务，并且可以控制正确关注点的数量、将其发送到多少复制碎片或可以控制所有这些。
DB：我在你的博客上注意到了。在MongoDB和SQL数据库之间的术语方面，您有类似的相似之处。它在SQL中称为联接，在MongoDB中称为其他类似的东西。所以，就MongoDB和SQL数据库而言，现在似乎存在类似的情况，是这样吗？
JK：百分之百。我们称自己为通用数据库，我也一直被问到，就像文字一样，我该用什么呢？我用这个还是这个？这个数据库或这个数据库，以及90%或99%的用例在MongoDB数据库上都能正常工作。
DB：因此，这可能是向MongoDB的拥护者提出的错误问题。那么，不利因素在哪里呢？那10%是什么？
JK：完全是。那得看情况。如果有人告诉你一件技术是一颗银弹，他们就是在撒谎，对吧？并不存在。我也讨厌科技，我们用这个东西，有人进来说，哦，你得用这个语言或者这个框架。我在堆积如山。这没什么用。如果您已经是一个SQL商店，酷，伟大的PostgreSQL是可怕的。我已经用了好几年了。我还在用呢。我觉得很棒。它有很多很好的用例，就像基于Word文档的数据库一样，也许像Redis这样的键值存储更适合保存用户会话ID或一些Memcache来进行更快的查找。我们写信给光盘。这取决于您要解决的问题、使用的数据结构类型以及您已经在使用的是什么。
DB：还有你自己的技能，你已经可以利用了。
JK：百分之百。如果您是一个SQL主，酷，但我认为数据库应该有助于您的生活更轻松。如果这让事情变得更困难，那可能是个问题。如果你已经是超级高效的一项技术，酷，去吧。
DB：您刚才提到Postgres，Postgres现在支持JSON-B。在关系数据库跨越边界并支持NoSQL类型功能的情况下，这是如何被视为威胁的呢？
JK：这很讨人喜欢，因为我想我们现在看到了很多公司。Amazon在Azure中有一个文档DB破坏Cosmo DB，他们已经完全删除了MQL，MongoDB查询语言语法，这是很棒的。这是超级奉承。我们做得很对。这个行业正在转向我们正在设计的查询语言，太棒了。PostgreSQL也是如此。实际上，我通常看到SQL数据库变得更像NoSQL数据库的趋势。我们可以更像SQL数据库，就像我们支持ACID事务之类的东西。但是JSON-B我想，我也经常被问到这个问题，理解与MongoDB文档相比，如何处理JSON-B文档是很重要的。
例如，查询JSON-B文档比使用MQL或MongoDB查询语言要困难得多。您必须使用专用SQL。这通常是相当复杂的SQL查询。获取您可以使用更简单的MQ或MongoDB查询获得的数据。您还必须拥有所有遗留的关系开销，而这些开销是您不需要的。你还得做地图。你仍然需要一个ORM来帮助与那些额外的抽象交互，这是YouTube上的一个额外的性能重击。JSON-B文档中没有数据治理。您必须有一个客户端的数据治理模型来保护您可以或不能访问的内容，或者在那个JSON文档中的模式设计。
基本上是个小斑点，对吧？使用MQL或MongoDB，您可以在数据库级别上强制执行架构。您只需控制结构，就可以使用MongoDB向JSON文档的深嵌套组件添加索引。这是非常相似的，但是SQL数据库的特性完整性和额外开销要大得多。如果你想走那条路的话，这也是应该考虑的问题，但我已经用过了。太棒了。这并不复杂，JSON小块，而且您已经在使用Postgres了。这是有道理的，去做吧。
DB：有一个用例。你提到甜点之类的东西是在AWS文档DB中出现的。几年前，MongoDB改变了其许可模式，引起了一些争议。这是第一批改变课程模式的公司之一，因为有传言称，公共云提供商正在使用他的技术，而没有支付费用。它改变了授权，呃，为那些你将要在公共云环境中使用它的人获得一些收入。现在关于Atlas服务周，您可以在MongoDB上托管它。好的决定对公司来说很好。你知道，这会被看作是开源领域的一种普遍趋势吗？
JK：我想我们看到的越来越多了。我同意，当它第一次出现的时候，人们对此有很多反对意见。我也觉得对此有很多误解。在SSPL中，它还没有得到开源基金会的认可，但关键是正确的。如果您将MongoDB作为提供程序出售，您必须打开您的堆栈或支付我们的许可。其他人都可以走了。如果您有一家电子商务商店，使用不应用许可的MongoDB并将其应用于您，那么开放源代码规则仍然是一样的，但是您正在从我们为生成代码而支付的代码中赚钱。我认为这个行业也在软化，因为我认为开发人员对此感到奇怪。
我想，作为一家公司，你需要赚钱。有了开源，就很难做到这一点。我认为SSPL是一个很好的方式来做一件事情，而不是像有一个像亚马逊，谷歌或微软这样的巨人从你的智力工作中敲诈你或赚钱。我认为它也有很多好处。我认为，如果你不是那些试图将表面货币化的大公司之一，你就没事了。阿特拉斯系统对我们来说是伟大的，它也让我们更加开放。
如果您进入Cosmo或Document DB，正确的数据库，但您被锁定在供应商周围的超级硬传输，我们刚刚推出了多云上周。您将在Google、Azure和GCP上安装MongoDB集群，您可以同时进行复制，所以如果整个数据中心崩溃，您就完全可以了。你不能和别人这样做因为我们不在乎你去哪。
DB：云不可知论者。许多公司正在花费大量的精力，试图成为云不可知论者。正确的。
JK：没人想被锁在里面。这就是它如何让你，便宜，他们拉你，他们开始抬高价格。但如果你给我灵活性，那是一场巨大的胜利。
DB：那么，你认为竞争主要来自哪里？是来自云本地解决方案吗？类似于您的文档DB，还是更多的是您的开源解决方案？就像沙发上的DB？
JK：我甚至都不认为是在这两种情况下。同样要注意的是，随着Cosmo文档的竞争，让我们把文档DB和AWS放在一起吧。AWS，它们是基于最后一个完全开源的版本，即2.4版本，运行4.4。所有这些都是关于独立测试的，我们已经看到了MongoDB的65%的功能完整性，这是我们目前发布的版本。我们看到的是功能上的巨大不足。
另一件事是DocumentDB是基于SQL的，它是后台支持的关系数据库。所以，通常发生的情况是，他们复制MQL查询语言，但将其放在关系数据库之上，您将得到相关的缺点，包括不能分割或分割数据。通常情况下，运行这些数据的成本会变得非常昂贵，这些数据库都是在它们的竞争对手身上运行的，而这些公司都是很棒的。它们是很棒的产品。如果你已经在那个生态系统里了，酷。合乎道理。重要的是要明白你在那里牺牲的是什么。我认为人们认为他们获得了完整的MongoDB体验，但他们没有。
DB：据我所知，在Postgres数据库中，它们复制了MongoDBAPI。
JK：一点儿没错。这是个讨人喜欢的复制品。我们对此非常高兴。这意味着我们做的是对的。开发人员社区喜欢MQL查询语言。很简单，很直观。但你失去了好处。
DB：开源播放器呢？
JK：我是说，他们很棒。他们太棒了。他们没有看到我们所看到的大规模增长。大量的投资，比如当有平台的时候，我认为我们正在尝试成为一个数据平台，而不仅仅是一个数据库。我们在上面建立了一个无服务器平台。我们刚刚发布了一个全新的图形QL端点，因为我们知道数据库的JSON类结构。您可以点击一个按钮，我们将生成一个图形，一个无服务器的图形QL点，使欺诈操作对您的数据立即。
DB：太棒了。我想问你这件事。我确实读过你在GraphQL和Support上的一些内容。什么使MongoDB成为您在使用API时的自然选择？
JK：JSON是Web的有效负载数据。这就是我们要发送的全部信息。这是一个图形QL的工作。我们现在甚至使用相同的数据结构进行查询。我们发送数据，作为开发人员，我们保存数据，我们从文档、JSON、对象和字典的角度考虑嵌套的键值对。保存正在传递的数据是有意义的。如果我能保存一个文档，这就是我需要发送回一个完全有意义的客户端的有效载荷形式。您可以更详细地说明它是什么。我们不会将事情保存为JSON。
如果您知道JSON，您将看到键值对都是字符串，由浏览器或客户端来对字符串、浮动或日期进行解码，但我们是bson，它是二进制对象符号，而不是JavaScript。我们可以保存更详细的东西，但我们也可以告诉客户更详细的信息。所以TLDR，我们在网络上发送数据，就像我们在MongoDB中保存数据一样，这是有意义的。
DB：如果您能够详细说明您正在讨论的GraphQL支持。这种原生GraphQL查询支持，它是如何工作的？
JK：我被它迷住了。我觉得这是最酷的事。我想我们还没谈过呢。我不认为足够多的人知道这件事。我是一个完整的JavaScript开发人员。凉爽的。不过，我要说实话。我已经很久没有写服务器了，过去几年我一直在做的是在云中建立一个数据库。我使用前端的无服务器提供程序将数据传输到静态前端。贾姆斯塔克完全是这样给我们带来的，但这只会让我们更容易设置。
有了数据库，您就可以设置一个无服务器提供程序来向客户端发送一些数据。你先设置前端然后转过来。但是这个图形QL，我喜欢图形QL。我觉得它很有表现力。我觉得很有趣。我在上一次工作时在一家大型电子商务商店里帮助实施了它。它为我们节省了大量的时间。它只会让前端开发者在类似的开发上更快。因为我可以索要我要的东西然后把它拿回来。更容易被陷害。过去，我必须建立自己的节点微服务来处理所有的图形端点，并且必须完成所有的设计、架构和部署。这是一个巨大的痛苦的屁股，但现在我们不必这么做。我真的按了一个按钮，它为我生成了整个东西。
DB：所以，这就是我们现在谈论的不同之处。本机GraphQL支持的是，在MongoDB数据库中进行查询不需要中间件。
JK：完全正确。我们比任何人都更了解你的数据。我们知道它的结构，因为它就像一根鞭子。我们知道数据类型、图QL和基于API提供程序的自述模式。我们想好了，嘿，我们可以免费为你做这个，这太酷了。
DB：我爱死它了。我对此很兴奋。
JK：我爱死它了。我希望更多的人知道这件事。从节省时间的角度来看，这太容易了。
DB：显然，现在仍然有一个休息的地方，我不想和我们其他人进行一场全面的辩论。每个人都有个地方。我们显然是RESTfulAPI的忠实拥趸，特别是对开放API的支持，但我们也越来越多地支持GraphQL，您将看到我们在GraphQL空间上也出现了一些东西。
JK：你可以两者兼得，我们在我的上一家公司做了同样的事情。如果您同时坐在一起，它会发出API请求和一些GraphQL请求。
DB：是。因此，在MongoDB的REST支持方面，我们是否只是在讨论，您知道，是否需要在中间添加某种层来进行REST请求？
JK：不，我们还有一个无服务器的，这叫做领域。我们有一个完整的无服务器前端，基本上位于您的MongoDB数据库前面。你可以设置触发器。根据数据更改，您希望激发一些无服务器功能或向其发出API请求。没问题。我们免费为你做这一切。这些都是你在竞争中得不到的东西。我们想让处理数据变得非常容易。你想让事情变得如此简单。大多数开发人员并不关心其中的大部分内容。没有。他们不关心复制和正确的关注点和碎片，没有人在乎。有些人这样做，这很重要。
别误会我的意思。大多数人只是想把一些数据放在某个地方，尽可能容易地把它拿回来。让我们把它做得尽可能简单。这是我对未来的疯狂猜测：但我认为，赢家，下一个甲骨文(Oracle)将比其他任何人都更容易地处理这些数据。我们看到，随着时间的推移，在开发者社区中，更容易使用的工具，开发人员是聪明的，但你仍然必须做到这一点，如果你必须跨越太多的障碍，你就会输。我认为，我们将看到更多的抽象和易用性，只需在很少到没有停机时间的情况下检索和扩展您的数据。
JK：我对未来还有另一个疯狂的猜测。如果有人在2026年听这个，或者我可能在这件事上走得太远了。我对数据未来最好的猜测是机器学习，拥有机器学习模型，根据查询对索引进行自动调整，根据用例自动分块、分区、分发数据，比如，你在香港有一群用户。让我把这些数据复制到一个香港数据中心。太快了。
作为一个人，我们都必须做到这一点。我们现在看到更多这样做的警报。比如，嘿，我们看到了这些建议，因为那是我们的数据公司。我们可以开始建立模型，开始大规模的分析，并为人们提供非常聪明的建议。这样就更容易了。我们已经有了性能查询监视器或类似的索引建议。比如，嘿，我们看到这个查询被做了很多，通过实现这个索引，你可以通过Blah，Blah，诸如此类来增加你的平均查询时间。我很想知道自动化能在未来帮助我们开发出多少数据库。
DB：凯文，把你的日记2026，我们会做，我们将重新访问这个网站，这个播客。
JK：你可以在2026年的推特上烤我，如果这些都不能通过的话。我不知道什么时候会发生这种事。我觉得那只猫已经不需要数据建模了。
DB：这很有道理。您刚才讨论的是如何通过RESTful请求直接查询MongoDB的GraphQL。在MongoDB前面设置某种代理(您可能想要转换数据和操作数据)有什么用例吗？
JK：总之，您可能希望从一个单独的数据源中获取数据，比如关系数据库，并且您希望在将数据发送给请求它的人之前将这些数据放在一起，或者您已经建立了自己的数据库。关于图QL的伟大之处在于，它与数据库无关。你可以建立一堆不同的数据库，它只是在查询一堆不同的东西，并将它们整合在一起。勇敢点儿。凉爽的。
DB：那是我去马提尼的天然通道，很明显，这是我们的产品。
JK：绝对一点儿没错。再说一遍，没有银弹。勇敢点儿。搞混了。我想这个词是什么意思？用一堆东西，随便你想要什么。我的大多数应用程序都至少使用了键值存储和基于文档的数据库。
DB：好东西。太感谢你了乔。我们没时间了。很高兴你能参加节目。
JK：我的天啊。我玩得很开心。这真是一场大爆炸。谢谢你邀请我。希望我们能再来一次。
DB：太棒了。我很愿意。
JK：我去年夏天刚去过堪萨斯城，但希望很快就能回到堪萨斯城。
DB：好的。我们的听众在哪里可以跟踪你，了解更多关于你的信息？
JK：你们都可以在推特上把我烤到Joekarlsson 1。第一，我在那里制作TikToks和有趣的视频。我也经常发一些编程技巧，有些人会说，但我有很多很棒的东西，但是我们要聊一聊我在那里和你一起玩的东西。
知识管理：非常感谢乔·卡尔松和我们在一起。对于我们的听众来说，您正在处理数据库吗？你有什么想分享的故事吗？请在您正在收听的任何播客平台的评论中告诉我们，请访问我们的网站www.toroCloud.com，了解我们的博客和产品。我们还在社交媒体、Facebook、LinkedIn、YouTube、Twitter和Instagram上。在那里跟我们说话，因为我们在听，再去找托罗·克劳德就行了。非常感谢您今天收听我们的节目。这是乔·卡尔松, 戴维·布朗和凯文·蒙塔尔沃为你提供鸡尾酒编码服务。
