我想了解在MongoDB上存储大数据的最佳方法是什么,以便更快地进行读取和写入,同时对硬件资源的影响最小。
目前,我们有SQL Azure数据库,用于存储各个帐户的用户的审核日志。该表目前的总记录约为200万,并且每天都在增长。
我会考虑使用每个帐户的一个对象移动到MongoBB,并嵌入所有日志对象。每个帐户的日志数据可能会超时,当前在帐户上设置的最大日志大约为200,000个日志,我们希望这是无限制的。
accountLogs文件
{
_accountid: 100,
Logs: [
{
username: 'xyz'
action: 'logged in'
actionDate: 01/03/2015
companyid: 123
},
{
username: 'xyz'
action: 'logged out'
actionDate: 01/03/2015
companyid: 123
}
]
}
答案 0 :(得分:0)
在您的情况下,特定帐户的日志没有上限和mongodb文档,每个文档的硬限制为16 MB,您当前的解决方案将无法正常工作。即使数据大小超过2-4 MB,也很难查询,因为数组大小太高。您可以应用的解决方案之一是为每个帐户创建bucker,以便架构看起来像这样。现在,您可以使用目前为止的日志数保留帐户ID的全局计数,并将其除以桶大小示例10000,因此它将是这样的。您可以使用mongodb的upsert命令创建一个新存储桶,以防它不存在。
int bucketId = totallog / bucketsize;
现在,您可以为日志提供统一的存储区大小,并在帐户ID和存储区ID上创建复合键以进行快速搜索。
{
_accountid: 100,
bucketId : 4,
Logs: [
{
username: 'xyz'
action: 'logged in'
actionDate: 01/03/2015
companyid: 123
},
{
username: 'xyz'
action: 'logged out'
actionDate: 01/03/2015
companyid: 123
}
]
}
答案 1 :(得分:0)
在MongoDB上存储大数据以实现更快的读取和写入而对硬件资源的影响最小的最佳方法是计划您的查询以使索引字段满足您的需求…您发布了1 acct的示例文档(已登录/注销字段-本质上是acct的会话。很好,假设您将查询这些字段并且将对这些字段建立索引。数据量很小,以至于索引本身可以满足查询要求-这称为覆盖查询,是最有效的方法。