Auth0将不同的数据存储用于不同的目的。我们有大量的数据集，用于为客户提供各种各样的用例和特性。不幸的是，在数据泄露越来越普遍的时代，选择和使用数据存储的一个关键方面是考虑可靠性、耐久性和安全性。我们的平台每秒处理数千个请求（每月数十亿次登录），我们的增长非常快！站点可靠性团队是一个新的计划，什么是物联网技术，旨在以数据驱动的方式提高可靠性和正常运行时间，以支持客户的需求。我们的团队与其他团队密切合作，通过编码、编写、研讨会、培训和领导与可靠性、性能和可观察性相关的不同计划来定义和应用最佳实践。在这篇文章中，我们将讨论我们使用的工具，我们为什么要使用它们，大数据下，并展示关于我们内部设置的更多细节。其中一些工具从一开始就一直伴随着我们——比如MongoDB——而另一些则是广泛测试、研究和特性开发的结果——比如PostgreSQL。继续读！你喜欢通过调试和修复生产中的问题来弄脏你的双手吗？我们目前正在招聘工程师加入网站可靠性工程团队！蒙古达MongoDB是我们的中心数据存储；它是我们对客户重要的大多数数据的"真实来源"。我们存储设置、连接、规则、用户等等。我们的MongoDB集群每秒提供数千个请求，但是我们没有存储那么多数据：我们最大的MongoDB数据库有30gb。考虑到我们的数据量很小，我们仍然非常适合只使用几台大型机器（大量的RAM和CPU核心，以及高速磁盘），而且我们不需要像切分这样的花哨的东西——我们仍然可以用垂直扩展做很多事情，而且我们仍然不需要水平扩展。正如IBM的davidbeumont在文章How to explain vertical and horizontal scaling in the cloud中所解释的那样，垂直伸缩实际上可以在不改变代码的情况下调整服务器的大小，而水平扩展则提供了扩展以处理流量的能力。每个MongoDB集群有六个节点：主要区域1个主要区域主区域1个副本主区域仲裁人1人故障转移区域上有2个副本，隐藏故障转移区域上有1个仲裁器，已停止（"main"和"failover"区域将在我们的多个云提供商和地区post中详细介绍）。除了故障转移区域上的仲裁器，所有节点都始终连接到副本集。我们有一个主节点和副本，负责正常操作下的所有查询，而故障转移区域的节点仅用于灾难恢复。我们将MongoDB Enterprise用于我们所有的云部署：这有助于我们，因为我们有额外的指标，也因为我们从MongoDB获得了出色的支持。使用MongoDB最具挑战性的一面是对新查询进行性能测试：因为我们有多个环境和区域，它们的数据集和使用模式大不相同，易淘客，所以有时候MongoDB可能会因为某种原因决定不使用索引。我们依赖$hint来执行特定的查询，并专注于关键集合和代码路径的性能测试。"使用MongoDB最具挑战性的部分是对新查询进行性能测试，因为我们有多个环境和地区，其数据集和使用模式大不相同。"在推特上留言自从Auth0概念出现以来，MongoDB一直是我们基础设施的一个重要组成部分，它应该在很长一段时间内继续成为我们堆栈的一个重要部分；它允许我们快速迭代，增加到每月超过15亿个身份验证操作，免费企业管理软件，中国物联网，甚至更多。弹性搜索我们在Elasticsearch上有很长的历史，但并不总是一个快乐的故事。我们使用Elasticsearch存储三种类型的数据进行搜索：用户元数据。审计日志：租户可以通过仪表板和API访问的日志。应用程序日志：来自我们的微服务和"现成"解决方案的日志，如NGINX和MongoDB（运行Kibana）。它们被保存在完全不同的集群中，具有不同的权限、备份策略和Elasticsearch配置。我们每个环境有3-5个群集。仅在美国环境中，我们就有近80个Elasticsearch节点。如果我们把所有的环境和区域都加起来，那么运行ES的大节点可能不足200个。哎呀！