当我在mongodb中映射相同的东西时,我觉得使用基于日期的“分片”.但问题是它使我的数据分发变坏.如果所有新数据都在同一个分片中,那么该分片将会很热,因为有很多人访问它们,并且包含较旧数据的分片将减少用户的负载.
我可以有一个基于集合的清除.我可以有30个集合,我可以丢弃最旧的集合以容纳新数据.但是有几个问题是1)如果我将集合缩小,那么我不能从分片中获益,因为它们是按照每个集合完成的. 2)我的查询必须更改为从所有30个集合中查询并进行联合.
请建议我一个很好的清除机制(如果有的话)来处理这种情况.
解决方法 在MongoDB中只有三种方法可以进行清除.看起来你已经确定了几个权衡因素.>单个集合,删除旧条目
>每天收集,丢弃旧的收藏品
>每天数据库,删除旧数据库
选项#1:单一集合
利弊
>易于实施
>易于运行Map / Reduces
缺点
>删除与插入一样昂贵,导致大量IO以及需要对数据库进行“碎片整理”或“压缩”.
>在某些时候,你最终会处理“写入”的两倍,因为你必须插入一天的数据并删除一天的数据.
选项#2:每天收集
利弊
>通过collection.drop()删除数据非常快.
>仍然映射/减少友好,因为每天的输出可以与摘要数据合并或重新缩小.
缺点
>您可能仍然存在一些碎片问题.
>您需要重新编写查询.但是,根据我的经验,如果您有足够的数据要清除,则很少直接访问该数据.相反,您倾向于对该数据运行Map / Reduces.所以这可能不会改变那么多查询.
选项#3:每天数据库
利弊
>删除速度尽可能快,文件只是被截断.
>零碎片问题,易于备份/恢复/归档旧数据.
缺点
>将使查询更具挑战性(期望编写一些包装代码).
>编写Map / Reduce并不容易,但请看一下聚合框架,因为它可以更好地满足您的需求.
现在有一个选项#4,但它不是一般的解决方案.我知道有些人通过简单地使用Capped Collections来“清除”.肯定有这样的情况,但它有一些警告,所以你真的需要知道你在做什么.
总结以上是内存溢出为你收集整理的数据库设计 – 如何处理Mongodb中的数据库清除全部内容,希望文章能够帮你解决数据库设计 – 如何处理Mongodb中的数据库清除所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)