互联网和移动技术的发展将权力牢牢掌握在消费者手中。每个行业都在转型，从金融服务到零售，再到娱乐。 Doctoralia 处于将这种转变应用于医疗保健行业的最前沿，其创新服务将患者与医生联系起来。它的用户可以根据位置、专业甚至其他患者的积极评价来发现医疗保健提供者。我与 Doctoralia 的首席技术官 Jordi Torra 坐下来，详细了解他们如何将数据置于患者体验的核心。
告诉我们一些关于贵公司的信息。你的使命是什么？
Doctoralia 促进了患者和医疗保健专业人员之间的联系。我们的服务在全球 20 个国家/地区提供，将 1.2 亿用户与 350 万医疗保健专业人员和机构联系起来。公司成立于2007年，由在医疗保健和互联网行业均有多年经验的团队创立。我们的使命是成为寻找和预订医疗保健专业人员和中心的全球领先目的地。
每个国家/地区的医疗保健都不尽相同，而 Doctoralia 调整其平台，以便在寻求医疗专业人员时为每个人提供最佳的本地化体验。用户可以按姓名、城市、专业、专长或其他标准搜索医生。我们不仅仅是寻找医生——用户可以阅读其他患者留下的评论，他们可以通过网络或移动设备与他们选择的专家在线预约。
我们还提供专家咨询服务，让患者有机会匿名询问与健康相关的问题，并从医生和专家那里得到答案。有数十万个经过审查的医学问题和答案，而且这个知识库每周都在增长。
最后，通过使用我们的服务，医生还可以接触到那些寻求咨询的人，并可以通过互联网的力量发展他们的实践。
请描述您对 MongoDB 的应用和使用。
MongoDB 用于在全球范围内存储和分发我们的患者和医生参考数据。
源数据全部存储在一个集中的 Microsoft SQL Server 中，但我们需要为我们的用户提供最快和响应最快的体验。为此，我们利用 MongoDB 的文档模型预先计算相关数据并将其聚合到丰富的嵌入式结构中，这些结构可以在对数据库的单次调用中访问。这样做使我们能够消除昂贵的关系数据库 JOIN 操作的性能开销。
然后，我们使用 MongoDB 的多数据中心复制将特定国家/地区的数据推送到更靠近用户的物理位置，从而减少地理延迟的影响。
当用户访问我们的网站时，他们通常希望通过多个标准搜索医生，包括位置、专业、预约可用性、保险公司承保范围、患者评论等。为此，我们使用 MongoDB 的 地理空间查询和索引 ，以及在选定字段上定义的附加二级索引，以根据用户的首选标准快速过滤医疗保健专业人员。这种丰富的查询和索引功能是我们服务实用性的关键之一。
在 MongoDB 之前你使用什么？这是一个新项目还是您是从其他数据库迁移过来的？
最初我们从 SQL Server 提供一切服务，但随着我们扩展到新的国家/地区，我们遇到了扩展挑战。我们在一个非常大的服务器上运行，这非常昂贵。我们意识到我们将用完空间，所以我们知道我们必须转向地理分布式架构。所以将近一年前，我们引入了 MongoDB 来减轻 SQL Server 的负担。
您是如何听说 MongoDB 的？
两年前，我在另一家公司工作，在那里我构建了不适合关系数据库模型的新一代应用程序。为了了解所有即将上市的新数据库，我参加了在科隆举行的 NoSQL Matters 会议，在那里我能够与来自开发人员和运营社区的其他与会者交谈。我收到的建议是试用 MongoDB，我照做了。我用它取得了很好的成果，所以当我来到 Doctoralia 并负责对我们的数据基础架构进行现代化改造时，在这里也使用 MongoDB 是一个很容易的决定。
请描述您的 MongoDB 部署。
我们将 MongoDB 分布到四个 Azure 区域：巴西、德克萨斯、波士顿和阿姆斯特丹。通过这种方式，我们能够让数据靠近我们主要市场的用户。每个区域都配备了一个 MongoDB 副本集 。这使我们能够应对这两种故障，并在升级等计划内维护事件期间保持服务连续性。每个副本集成员都提供给一个 Azure 虚拟机 。我们所有的开发都是在 C# 中完成的，因此我们使用 MongoDB 的 原生 .Net / C# 驱动程序 。
我们最近升级到 MongoDB 3.0 ，混合了 MMAPV1 和 WiredTiger 存储引擎。这有助于我们评估哪种存储引擎适合我们的工作负载。我对 MongoDB 3.0 为我们的表现感到非常满意。
您能否分享有关扩展 MongoDB 基础架构的任何最佳实践？
模式设计 很关键。考虑您要运行的查询，并从那里设计您的模式。不要停留在过去的关系数据建模概念上。不要害怕对数据进行非规范化，这样您就可以在对数据库的一次调用中访问解决查询所需的所有相关数据。
如果服务负载很重，我可以采用以下两种方法之一：
-
如果我期望在
临时数量激增，我使用 Azure 控制面板向我的实例添加更多资源。在不到 5 分钟的时间内，零停机时间，我的副本集在更强大的硬件上运行。您必须注意时间安排——当您执行副本集的滚动重启时，您的弹性会降低。
- 如果我需要永久增加容量，我会启动一个全新的虚拟机并对副本集执行初始同步。初始同步会给副本集带来更多的性能开销，因此主动的容量规划很重要。
如果您的工作负载是写入密集型的，即大量更新——正如我们将 MongoDB 与 SQL Server 同步时的工作负载——考虑使用 MongoDB 的 WiredTiger 存储引擎。它给了我们更高的性能。
由于 MongoDB 可以在单个副本集中混合多个版本和存储引擎，因此我很容易用真实数据对不同的配置进行基准测试。当我需要这样做时，我会克隆其中一个节点，然后对其进行升级。我停止原始节点并使用相同的 IP 和端口配置克隆节点，然后运行它几天。如果它通过了我的测试，我可以继续并删除原始节点。如果有问题，我可以删除克隆的节点并回滚到原始节点。这太容易了！
如果您打算这样做，则必须注意 OpLog 的大小。您不能等待整整一个月并期望原始节点在没有完全初始同步的情况下返回副本集。
MongoDB 的表现如何？
它的表现非常好。我衡量的性能 SLA 是应用程序必须在 50 毫秒的窗口内响应用户，无论是什么设备。数据库是让我们遵守该 SLA 的关键。 MongoDB 为我们提供了跨数千万文档的低延迟查询。
您使用什么工具来管理您的部署？
我们使用 New Relic 监控我们的技术栈。当事情开始出错时，这会向我们发出早期警告。如果我们发现问题与 MongoDB 相关，那么我们会使用 MongoDB Cloud Manager （以前称为 MMS）深入了解细节。它为我们提供了对关键指标的低级别可见性，以便我们能够在任何潜在问题导致中断之前对其进行诊断。
您如何衡量 MongoDB 对您的业务的影响？
两件事：速度和可用性。
随着 MongoDB 的引入，我们已经能够保持我们服务的响应能力，即使我们已经进入新市场。如果我们只依赖 SQL Server，我们将永远跟不上这种增长的步伐。对我来说，这就像开老爷车开得太快了。可能暂时还好，但到了某个时候，它就会坏掉，甚至可能导致事故。然后你把它弄好会花费一大笔钱！
MongoDB 的正常运行时间令人难以置信。我们能够将 MongoDB 从爱尔兰的数据中心迁移到阿姆斯特丹的新 Azure 区域。这是一个 700 公里的移动……MongoDB 的副本集使我们能够在服务零停机的情况下完成它。我们永远不可能用 SQL Server 做到这一点。我们会停机 20 分钟到 20 小时不等。
Jordi，感谢您与 MongoDB 社区分享您的经验。
要了解有关跨区域部署的更多信息，请阅读我们的 MongoDB 多数据中心白皮书。
