由于Linode的赞助，我上周参加了2022年MongoDB世界大会。在这篇文章中，我将详细介绍我在那里的时间，以及我正在为即将到来的教程编写的一些代码片段。我还制作了一段视频，回顾了我在MongoDB世界的经历。
我的240字总结：
MongoDB World让我确信我需要更经常地使用MongoDB。目标受众可能是管理人员而不是开发人员，因为大多数的会谈（包括我自己的会谈）并没有进入开发人员经常喜欢的技术深度。我推荐你参加!
地点：纽约市
贾维茨中心的位置很完美，会场也很迷人。对于一个会议来说，像纽约市这样的城市正是你需要的能量类型。外面有这么多事情发生，自然会渗透到会议中。
评价：9/10
主题演讲
为了启动这次活动，我们听取了MongoDB首席执行官Dev Ittycheria的发言。如果我只听了Dev的主题演讲，我就会更经常地使用MongoDB了。Dev强化了这样一个概念：MongoDB的存在是为了帮助团队以更少的资源提供更多的服务，在我参加会议的整个过程中，这似乎是真的。
德夫很快就被另一位主持吸引住了，他真的把房间里的能量吸走了。这种感觉是可想而知的。在分组讨论开始前，德夫回到舞台上，提供了一些急需的能量。
在主题演讲期间，我们也有一些现场演示，突出了MongoDB的一些神奇之处。正如你所想象的那样，现场演示往往是灾难性的，但就我所知，这些演示都很顺利。
在第一天的下午，CTO马克-波特发表了我所见过的最好的科技主题演讲之一。很明显，他首先是个老师，其次才是CTO。他的气质就像一个冲浪营的教练，而他的技能是一个经验丰富的数据库专家，从技术上讲，他可以绕着绝大多数的CTO们跑一圈。如果我在整个会议期间只听了一个讲座，那就是马克的主题演讲。
听到最后一天的主题演讲，我真的很兴奋：雷-库兹韦尔。雷是一位成功的未来学家，在他的职业生涯中做出了一些出色的预测。多年来，他还写了几本畅销书，并举办了许多讲座。
在MongoDB世界大会上，Ray重申了很多我多年来听他说过的事情。现在回想起来，这并不令人惊讶，但它确实让我得出这样的结论：Ray应该接受Dev或Mark等人的采访，以便为最后的主题演讲提供一个动态的对话。
评价：7/10
分组会议
分组会议提供了关于团队在其组织中利用MongoDB的各种工具和技术的有趣概述。
这里有几个我觉得非常有趣的话题：
- 境界
- 无服务器的MongoDB (Atlas Serverless)
- 时间序列
境界
Realm似乎是一个非常引人注目的产品，使移动设备和物联网能够与管理的MongoDB集群（如Atlas或Linode管理的数据库）进行数据同步。
边缘数据的挑战是确保本地/设备上的数据库经常与云数据库不同步。乍一看，这似乎是一个小问题，但一旦你达到规模，如10万台移动设备，这个问题就会变成一个大问题。
我还没有测试，但我参加的会议肯定使MongoDB的Realm成为解决边缘到云数据库同步的各种问题的完美解决方案。
Realm的几个主要好处：
- 为动态数据同步到MongoDB而做的
- SQLite/核心数据替换
- 对设备的影响小
- 跨平台API（Kotlin、Swift、JavaScript等）。
- 帮助处理移动/物联网设备的连接问题
在这里了解更多信息。
无服务器的MongoDB
如果你问我，无服务器这个词有点傻，因为我倾向于把无服务器看作是 "可管理的规模托管"。无论名称如何，无服务器都将继续存在，我完全支持它。
无服务器是扩展你的计算资源以满足需求的过程，不管是多大还是多小。有多大往往有待商榷，但将规模缩小到零往往可以节省大量的资源，而且往往可以节省美元和意义。
让我们摆出一个场景，帮助突出无服务器的好处：
无服务器场景：某网站在体育赛事期间实时跟踪统计信息。
当一个体育赛事正在发生时：网络应用程序有大量的活动跟踪数据；网络应用程序根据球迷的数量、一天中的时间、赛季中的时间点等有不同的流量；网络应用程序需要在整个活动期间对每个人都是快速的。
当一个体育赛事没有发生时：网络应用程序的活动跟踪为零；网络应用程序大部分时间的流量为零；理论上，网络应用程序可以完全关闭，没有人会知道。
无论事件之间的时间有多长，上述情况几乎都是真的。这个理论上的网站工作方式的多变性是一个戏剧性的例子，说明为什么无服务器是伟大的：前一秒你有10万个请求，后一秒是8个请求。下一秒是25万个请求，再下一秒是76个。无服务器的设计是为了优雅地处理这些场景，并且有难以置信的延迟。
无服务器数据库：难以捉摸的梦想
上述情况在无服务器网络应用中很适用，但无服务器数据库又如何呢？
现代网络应用，无论是否无服务器，都需要以尽可能低的延迟访问数据的能力。如果数据库是无服务器的，这意味着它可以扩展到零实例运行，或者干脆数据库可以基本关闭。因此，如果数据库被关闭，再打开就会有延迟；这样一来，传统上数据库层的无服务器就很难做到。
扩大或缩小数据库的问题涉及到数据的大小；更多的数据意味着打开或关闭数据库需要更长的时间。从历史上看，由于Kubernetes和各种Docker的实现，在你的应用程序可以无服务器（或无服务器）的情况下，只需保持你的数据库服务一直在运行就会更容易和无摩擦。
我还没有看到一个无服务器的SQL替代方案能与Atlas Serverless所做的相提并论，而这也是MongoDB团队的一个不小的成就。很高兴看到他们成为无服务器数据库的先驱。
我没有看到的是对开源无服务器MongoDB的支持。也许那也会到来。
无服务器：速度、成本和摩擦
我部署应用的速度越快，我就能越快地了解哪些是有效的，哪些是无效的。无服务器为我们提供了进行这类测试的能力，而这样做的成本增加很少。我认为，这是使用无服务器的最大好处之一。
如果你的应用程序不工作，让它坐在那里，但运行的资源为零。在有流量的第一个迹象时，扩大规模以满足需求。当需求减弱时，再缩小规模。这与做A/B广告测试完全一致，所以你的应用程序可以在需要的时候工作，而不是一直工作。
如果你的应用程序正在运行并且运行良好，那么维持持续负载的开销就会通过各种管理服务从你的团队中抽象出来。这意味着一个小团队可以用很少（如果有的话）的额外工作处理大量的负载。
所有这些都是说，无服务器提高了团队的效率，同时降低了处理该应用的需求要求所需的总体成本。
无服务器并不是一个完美的解决方案，但它肯定是解决了资源受限团队的许多问题。
MongoDB上的时间序列
MongoDB（至少从版本5开始），支持内置的函数来做时间序列分析。如果你不熟悉创建时间序列数据，它只是在你的数据库集合（表）中的每一条记录上添加某种时间戳的过程。
时间序列分析是很好的选择：
- 改善需要销售预测、产品需求、流量估计等的财务决策。
- 购买股票、债券等。
- 随着时间的推移，跟踪传感器和物联网设备。
- 性能指标（如网站性能、广告等）。
当然，这种分析的应用还有很多，但正如我们所看到的，使用时间序列数据对组织中的许多角色都是至关重要的。MongoDB让这种分析变得更加容易。我将会在将来更多地讨论MongoDB的时间序列分析，但现在，这里有一个使用MongoDB和Python pymongo包的快速样本：
1.初始化MongoDB客户端
import os
from pymongo import MongoClient
# this assumes you have a running MongoDB cluster/instance
mongodb_un = os.envion.get("MONGODB_USERNAME")
mongodb_pw = os.envion.get("MONGODB_PASSWORD")
mongodb_host = "localhost"
mongodb_port = 27017
db_url = f"mongodb://{mongodb_un}:{mongodb_pw}@{mongodb_host}:{mongodb_port}"
client = MongoClient(db_url)2.创建时间序列集合
# create/select a database
db = client.business
# create time series collection
db.create_collection(
"rating_over_time",
timeseries = {
"timeField": "timestamp",
"metaField": "metadata",
"granularity": "seconds"
}
)3.添加模拟的时间序列数据
from datetime import datetime, timedelta
from random import randint
# Insert a lot of fake time series data
names = ['Kitchen','Animal','State', 'Tastey', 'Big','City','Fish', 'Pizza','Goat', 'Salty','Sandwich','Lazy', 'Fun']
company_type = ['LLC','Inc','Company','Corporation']
company_cuisine = ['Pizza', 'Bar Food', 'Fast Food', 'Italian', 'Mexican', 'American', 'Sushi Bar', 'Vegetarian']
_count = randint(0, 10_001)
for x in range(1, _count):
now = datetime.now()
delta = now + timedelta(days=randint(0, 2), minutes=randint(0, 60), seconds=randint(0, 60))
if randint(0, 1) == 1:
# randomly vary the direction of the timestamp
delta = now - timedelta(days=randint(0, 2), minutes=randint(0, 60), seconds=randint(0, 60))
random_company_index = randint(0, (len(company_cuisine)-1))
business = {
"metadata": {
'cuisine' : company_cuisine[random_company_index],
'name' : names[randint(0, (len(names)-1))] + ' ' + names[randint(0, (len(names)-1))] + ' ' + company_type[randint(0, (len(company_type)-1))],
},
'rating' : randint(1, 5),
"timestamp": delta
}
#Step 3: Insert business object directly into MongoDB via insert_one
result=db[db_name].insert_one(business)4.进行时间序列的汇总
# run an aggregation
list(db.rating_over_time.aggregate([
{"$unwind": "$metadata"},
{"$project": {
"date": {
"$dateToParts": { "date": "$timestamp" }
},
"rating": 1,
"cuisine": "$metadata.cuisine",
}
},
{
"$group": {
"_id": {
"cuisine": "$cuisine",
"month": "$date.month",
"day": "$date.day",
"year": "$date.year",
},
"avgRating": { "$avg": "$rating" }
}
}
]))这就造成了：
[{'_id': {'cuisine': 'American', 'month': 6, 'day': 16, 'year': 2022},
'avgRating': 2.75},
{'_id': {'cuisine': 'Italian', 'month': 6, 'day': 12, 'year': 2022},
'avgRating': 3.0},
{'_id': {'cuisine': 'American', 'month': 6, 'day': 14, 'year': 2022},
'avgRating': 3.0655737704918034},
{'_id': {'cuisine': 'Pizza', 'month': 6, 'day': 15, 'year': 2022},
'avgRating': 3.0508474576271185},
]上面的数据来自于我自己对Python 和MongoDB的实验，但主要是受到一个会议的启发，该会议谈到使用MongoDB时间序列分析来自动购买基于历史价格的股票。这个讲座在技术上并不深入，因为正如你在上面看到的那样，它真的不需要深入MongoDB似乎降低了做一些惊人事情的摩擦。
评论
总的来说，分组会议缺乏我作为一个开发者真正喜欢的技术深度，但这是有意义的。大多数会议都在一个小时以内，通常是30分钟。在如此短的时间内，在听众如此广泛的背景下，很难进入技术细节的核心和螺栓。
我参加的会议所展示的内容一般都很出色，但也有一些失误。
评价：8/10
伙伴馆
合作伙伴展馆里有很多公司为可能（或不可能）在业务中使用MongoDB的公司提供相关服务。在这些展位上工作的人通常是针对其组织的决策者的销售人员。
在这里，我有机会见到更多的Linode和Akamai团队成员，并与他们进行交流。简而言之，能与他们联系是件好事，因为我们的大部分交流都是通过互联网进行的，我想他们的大量客户也是如此。我当然有偏见，但我发现Linode/Akamai团队非常平易近人、开放，而且非常愿意集思广益，提出各种想法。
我能够与几个关键的公司进行交谈：
- HashiCorp：与Terraform （除其他外）的制造者聊天，听到他们致力于使DevOps对更多人来说更好更容易的承诺，真是太好了。当然，我真的很喜欢使用目前状态的Terraform ，但未来似乎很光明。也许我也需要去看看未来的HashiConf活动!
- Vercel：Next.js的制造商由于最近宣布与Atlas整合而在主题演讲中得到了很大的关注。在适当的时候，我将会花更多的时间在他们的平台和Next.js上！
- MongoDB大学：很明显，教育是MongoDB战略的重要组成部分，这绝对让我们对未来的教育感到兴奋：通过需求、实用和适销对路的技能来获取和驱动。
- Datadog：谁使分析日志变得很酷？就是Datadog。我被拉去参加一个演示，我很高兴我这么做了。我肯定需要更多地了解这家公司。
一般评级
主题演讲（上文已讨论）：7/10
- 一些伟大的发言者与一些乏善可陈的发言者
分组会议（上面有更多讨论）：8/10
- 总的来说，会议很精彩，但缺乏我作为开发者喜欢的技术深度。
教程：6/10
- 在我参加的主要活动中，出现了wifi问题。为什么不采用有线的以太网备份？
- 演讲者对问题的处理很好，但内容最终还是有点太慢。
食物：3/10
- 第2天的热狗？真的吗？
- 离会议三个街区远的惊人的比萨饼。
家庭友好型：3/10
- 如果你有5岁以下的孩子，那就是0/10。
- 除了受欢迎的旅游目的地，年轻的孩子几乎没有什么可做的。
- 纽约很拥挤，很吵，行人走路很凶，车辆也很凶。
- 是的，我住在德克萨斯州奥斯汀附近的一个小镇上，所以这个评价是基于此。我们有很多空间，纽约则没有。
地点：9/10
- 从专业的角度来看，在纽约市举行的活动是不可思议的。这里有很多美味的食物、餐厅、酒吧、场地等，可以娱乐并与其他专业人士联系。
- 纽约市的活力几乎是世界上所有地方都无法比拟的；总是有东西在建造/重建，人们总是在外出，几乎总是有好东西吃。
- 在纽约市，15英里的路程竟然需要2个多小时的车程。对于一些人来说，这可能会将地点的评分降低到3/10。
- 如果我没有被赞助参加，评分将是2/10（哈哈！），因为纽约的一切费用很高。
酒店：5/10
- 对于一个小房间来说，价格昂贵。
- 好的一面是，我所在的酒店的自助早餐非常好，我听说其他酒店的情况也是如此。
- 有很多选择。
机场：3/10
- 不惜一切代价避开肯尼迪机场的8号航站楼。它很破旧，食品/纪念品的选择很差。
- 离开机场有很多选择，而且都比较快。
- 如果我在正确的终点站着陆，它可能会提升到6/10。
运输：7/10
- Uber/Lyft/出租车/等等，到处都是。
- 当你需要乘坐时，运输成本很高。
- 来往机场的交通费最后几乎是我机票费用的1/4。
- 纽约的步行环境非常好，因此交通很方便。
会议零食：6/10
- 好的选择，太少了
会议饮料选择：5/10
- 基本上是3大可乐产品。
会议咖啡：8/10
- 当地酿造的咖啡很扎实，但我又喜欢几乎来自任何地方的新鲜酿造的黑咖啡。
公司投票率：6/10
- 我估计有20家公司到场；我以为会更多。
挥霍：3/10
- 寻宝游戏换取礼品？很可爱，但不用了，谢谢。
会议娱乐：8/10
- 亭子里有钢琴决斗的喜剧演员。他们很厉害。
- 看上去有一些游戏比赛，但似乎每次只限于几个参与者。
- IDEA休息室里的司仪很不错。
- 对于参加的人来说，会后的聚会听起来很有趣。
听觉无障碍：
- 在需要时，至少有3名ASL翻译在活动中工作。
- 我不能说质量如何，但看起来他们很好。
视觉可及性：不适用
- 我没有寻找或看到对视力障碍者的支持。
自然，每个人的经验都会有很大的不同，所以对上述内容要有一个清醒的认识salt 。
总体评价：8/10
MongoDB世界让我相信，我需要花10倍到100倍的时间来使用MongoDB。这对我来说不是一件小事，因为我的职业生涯中的大部分时间都归功于SQL和与之集成的工具。
我很喜欢MongoDB世界，如果你有能力，你可能会考虑在2023年参加。如果你时间紧张，我认为你只需参加第一天的会议就可以得到很多东西。如果你真的参加了，我们总是可以在活动结束后观看/重新观看会议的点播（我相信最多可以观看30天）。第2天和第3天仍然有很多活动，但在第2天下午，出席者开始减少。
我认为会议很难为所有的技术专家提供服务，但我认为MongoDB World在这方面做了很好的平衡。许多演讲者在会议结束后都可以进行更深入的讨论，这是非常好的现象。我参加的大多数演讲都很专业，而且执行得很好，正如人们所期望的那样。与会者似乎真正有兴趣联系和了解其他人在这个领域的工作。
纽约的贾维茨会议中心令人难以置信，当然给整个活动的氛围带来了宏伟的感觉。会议中心的宏伟壮观真的突出了我的小酒店房间是多么的可怜。
会议上食物的不足被以下事实所弥补：纽约市几乎每个街角都有一些世界上最好的食物。如果你是一个美食家，你可能想在午餐时间跳出去，去哈德逊院子或时代广场那边。就像任何好的会议一样，咖啡是流动的!
如果你想在参加会议时带上你的家人，你可能要重新考虑，因为当你在会议上忙碌时，没有很多年幼的孩子（5岁及以下）可以真正做。
对我来说，这次活动的重点是帮助教导与会者如何在其业务中最好地使用MongoDB。对于这一点，我认为他们完全做到了，而且我对MongoDB绝对有信心。我们不要忘记，SQL首次出现在1974年，而MongoDB的首次发布是在2009年。在这个时代，MongoDB用现代的方法来解决云优先的组织和项目所面临的现代问题，其差异是显而易见的。这个会议存在的事实本身就证明了他们对推动发展的执着，并将我们所有人带入其中。
对于2023年的MongoDB世界，也许我们可以相互见面。
干杯!
Justin Mitchel
教师和创始人
CodingForEntrepreneurs.com
注释