使用MongoDB提高企业的IT性能

本文的目标读者是正在为他们的IT系统寻找开源应用的开发人员和架构师。作者描述了一个实际的企业情况，他们在工作流程中采用了MongoDB来加速流程。

在过去十年左右，产生的数据量呈指数级增长。存储，管理和可视化数据的方式已经从旧的传统方法转向新的方式。开源数据库的数量和种类亦出现了爆炸性增长。许多设计旨在提供高可扩展性，容错性和核心ACID(Analysis Console for Intrusion Databases:入侵数据库分析控制台)数据库功能。每个开源数据库都有一些特殊的功能，因此开发人员或任何企业都要谨慎选择并独立分析每个特定问题陈述或使用案例，这一点非常重要。在本文中，让我们看看我们在企业生态系统中评估和采用的其中一个开源数据库，以满足我们的案例。

如其文档中所定义的，MongoDB是一个开源，跨平台，面向文档的数据库，可提供高性能，高可用性和易扩展性。

MongoDB使用集合的概念，您可以将其与MySQL和Oracle等RDBMS中的表关联。每个集合都由文档（如XML，HTML或JSON）组成，它们是MongoDB中的核心实体，可以与Oracle数据库中的逻辑行进行类比。

与普通Oracle数据库相比，MongoDB具有灵活的模式。在前者中，我们需要具有定义明确的列的明确表，并且所有数据都需要适合表格行类型。但是，MongoDB允许你以JSON格式和非关系方式以文档形式存储数据。每个文档都可以有自己的格式和结构，并且独立于其他文档。其代价是是无法对数据表进行连接。我们作为开发人员或架构师在采用Mongo DB时必须经历的一个主要转变是习惯上的转变 - 习惯于存储规范化数据，摆脱冗余，在我们需要将所有可能的数据存储在形式的文件，并处理并发问题。

水平扩充特性由“分片”概念实现，数据在不同的机器和分区（称为分片）上分割，这有助于进一步缩放。通过在不同的机器或数据中心镜像数据来启用容错能力，从而在服务器出现故障时使数据可用。另外，一个自动的进程调度过程在整个服务器集群中提供高可用性。

传统上，数据库一直支持单一数据模型，如键值对，图形，关系型，分层，文本搜索等; 但是，今天推出的数据库可以支持多个模型。MongoDB就是一个具有多模型功能的数据库。尽管MongoDB提供了空间数据和文本搜索功能，但它不如Solr或Elastic Search那样好，后者可以提供更好的搜索引擎。

对我们的案例的分析

我们目前正在订单管理领域工作，订单数据通过我们的中间件与270多个应用程序进行交流，将订单数据传达给近120个应用程序。

我们在内部实施的主要组件之一是我们的自定义记录器，该记录器用于记录事务事件，为我们的系统启用消息跟踪和错误跟踪。大多数消息是异步的。这些集成是异构的，因此我们连接到Oracle，Microsoft SQL关系数据库，IBM MQ，Service Bus，Web服务和一些基于文件的集成。

我们的中间件进程在订单在IT系统中传输的路径中生成大量事件，而这些事件通常包含订单元数据以及搜索所需的几个订单属性; 指示成功，错误，警告等的状态; 在某些情况下，我们会存储整个有效负载以进行调试等。

我们的自定义记录器框架传统上用于将这些事件存储在每个服务器的本地文件系统中的纯文本日志文件中，并且我们有一个后台Python作业来读取这些日志文件并将它们分解到关系数据库表中。尽管记录速度很快，但是，跨多个服务器跟踪消息并试图获得订单的实时视图仍然是不可能的。然后在调度程序和需要监视的后台作业等方面存在问题。在一个集群中，Prod和DR以16个物理服务器的主动模式运行，我们必须运行16个调度程序作业，然后监视它们以确保它们一直在运行。我们可以使用多线程提高数据提取的速度，或者以较小的时间间隔进行调度；然而，当我们扩展集群时，跨多个域管理它们使得维护起来将会很头痛。

为了获得实时视图，我们用轻量级Web服务重写了日志框架，该服务可以直接写入RDBMS数据库表，但这降低了系统的性能。最初，当我们在本地文件系统上写入文件时，处理速度大约为每分钟90-100k条消息。现在，通过写入数据库表的新设计，性能仅为每分钟4-5k条消息。这在性能上是一个很大的折衷，我们承受不起。

我们用Oracle AQs重新编写了框架，其中Web服务将数据写入Oracle AQ; 数据库中有一个调度程序作业，它将来自AQ的消息出队并将数据插入表中。这将性能提高到每分钟10k条消息。至此，我们对Oracle数据库和及此系统功能的优化进入一条死胡同。现在，为了在不损失大部分性能的情况下实时查看订单，我们开始关注开源生态系统，并着手开始使用MongoDB。

它适合我们的用例。我们的需求是一个数据库，可以在多个进程并行记录事件的情况下进行高性能写入。我们对这个日志记录数据的查询率大大降低。我们根据以前的经验快速建立了文档的模型，并能够迅速推出使用MongoDB后端的自定义记录器。性能大幅提升至每分钟约70k条消息。

这使我们能够在需要的基础上对多个流程和系统的订单的查看接近实时，而不会影响性能。它不再需要跨服务器集群的多个调度进程也更不需要管理它们中的每一个。另外，无论我们的主机应用程序有多少个进程或多少个服务器，我们的托管在不同基础架构上的记录器框架都能够以面向服务的方式迎合所有需求。

目前，我们正在通过经验学习。在采用MongoDB时，在涉及到数据增长的管理以及整理数据碎片方面我们遇到了一些挑战。这不是直接可用的，需要我们在创建碎片时进行规划和管理。碎片管理需要改进以提供最佳的存储使用。此外，副本和副本的位置决定了我们的灾难恢复能力。我们能够毫不费力地维护基础架构，并且正在寻找机会将此日志框架推广到其他领域，例如IT中的产品主控或客户主控集成空间。这是可行的，且由于MongoDB的灵活的JSON文档模型，因此不需要太多的返工或更改。