MongoDB BI架构

Question

我们已经有一个生产应用程序，运行Mongo并在不同的盒子上设置了一个副本。

我想开始在数据上做一些BI，可能使用Pentaho。

我的问题是：我应该如何设置我的架构，以便我不直接在生产环境中执行BI？

我应该创建一个单独的BI实例并对BI实例执行mongoexport吗？还是应该遵循一些其他最佳实践？

Answer 1

根据您的数据集，BI需求和MongoDB服务器版本，可以考虑几个选项。如果您只需要读取数据报告，则有更多的选项比如果您还想要写入数据（例如用于地图/缩减操作）。如下所述，MongoDB 2.2还引入了一些非常有用的功能和改进。

通常，使用replica set配置对于管理目的非常有用，因为这可以在不中断主MongoDB服务器的情况下使数据集的完整副本可用。对于更大的数据集和水平写入扩展，MongoDB的sharding功能也可以与以下任何建议结合使用。

在走下分离BI数据的路径之前，应该先确定在临时环境中测试的实际影响。

以下方法可大致孤立的顺序从生产环境：

1. 与副本设置，您可以使用read preferences直接查询到相应的服务器。在2.2之前的MongoDB版本中，一般阅读偏好仅限于从主数据读取或允许从非隐藏次级数据读取“slaveOK”（相当于“secondaryPreferred”）。在MongoDB 2.2中，有一些额外的读取首选项，包括“次要”（如果可用，则从次要读取，否则错误）; “主要首选”（如果可用则从主要读取，否则为次要）;和“最近”（根据网络延迟从最近的主节点或次节点读取）。 MongoDB 2.2中的读取首选项可以与tag sets结合使用，以提供对定向查询到副本集或分片群集中的服务器的更细粒度的控制。

2. 对于MongoDB 1.8及更高版本，您可以使用hidden secondary node的副本集。隐藏节点将不会被通告给连接到副本集的客户端，但可以直接连接到报告生成。注意：隐藏节点将是只读辅助节点，因此这限制了一些查询的使用。例如，map/reduce需要写入权限才能保存到输出集合中，但您可以使用内联映射/缩减，具体取决于BI需求。

3. MongoDB 2.2有一个数据库级的写入锁（与先前版本有一个全局写入锁的改进）。如果您需要编写BI数据，则可以将其保存到单独的数据库中以最大限度地减少锁争用。您仍然需要考虑总体资源效应。例如，为了BI目的而处理大量较旧的文档可能会与生产应用程序正在查询的最新文档的缓存竞争。

4. 如果要将BI数据与生产环境完全分开，可以使用MongoDB backup strategies之一创建单独的实例。如果启用了复制，则可以在副本集中从辅助节点创建备份。根据数据集的大小，执行数据快照副本（其中包括已构建的索引）可能会更快，而不是完整的周期。

Answer 2

使用副本集并在辅助节点上运行分析（只要涉及）。