MongoDB BI架构

Question

我们有一个运行Mongo的生产应用程序，在不同的机器上有一个副本集。

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

我的问题是:我应该如何设置我的体系结构，使我不直接在生产环境中进行BI？

我是否应该创建一个单独的BI实例并向BI实例执行mongoexport，或者是否有其他我应该遵循的最佳实践？

Answer 1

根据您的数据集、BI要求和MongoDB服务器版本，有几个选项需要考虑。如果您只需要读取报表的数据，则有比写入数据更多的选项(例如，用于map/reduce操作)。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结合使用，以提供更精细的控制，以将查询定向到副本集或分片群集中的服务器。

MongoDB 1.8和更高版本，您可以将副本集与hidden secondary node一起使用。隐藏节点不会正常通告到连接到副本集的客户端，但可以直接连接以生成报告。注意:隐藏的节点将是只读的辅助节点，因此这限制了某些查询的使用。例如，map/reduce需要写访问权限才能保存到输出集合。但您可以使用内联map/reduce，这取决于您的BI requirements.

1. MongoDB 2.2具有数据库级写锁(这是对具有全局写锁的早期版本的改进)。如果您需要写入BI数据，可以将其保存到单独的数据库中，以最大限度地减少锁争用。你仍然需要考虑整体的资源效应。例如，为BI目的处理大量较旧的文档可能会与缓存由生产application.
2. If查询的最新文档相竞争。如果您希望将BI数据与生产环境完全分离，则可以使用其中一个MongoDB backup strategies创建一个单独的实例。如果启用了复制，则可以从副本集中的辅助副本创建备份。根据数据集的大小，对数据(包括已建立的索引)进行快照复制可能比执行完整的mongodump/mongorestore周期更快。

Answer 2

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