假设我们正在设计一个新系统,并决定使用MongoDB作为主数据库.数据模式与具有[增长]评论的博客非常相似.
在"MongoDB Developers"一书中,提示#6:不要嵌入具有未绑定增长的字段,它表示不断将数据附加到数组的末尾是有效的(但它也暗示评论是一个"奇怪的边缘情况") ).
假设我们的新系统就像博客中的那些"评论" - 一直在动态增长,但有时也在变化,或者有些被删除.
因此,在认识到使用MongoDB可能存在性能问题之后,还有什么其他替代数据库(必须是水平可伸缩数据库)才能实现此目的？(我们不介意使用MongoDB作为我们的主数据库,而是将"注释"与备用数据库分开.有哪些选项？
笔记:
将Hashes作为其数据类型的Redis功能符合我们的"注释"数据结构的描述 - 不断增长但有时被修改或删除 - 但我们不需要纯粹的内存数据库(我们不希望如此奉献当数据可以持久保存到磁盘时RAM - 否则这将非常适合我们的问题
那么使用CouchDB呢？我们没有对此产品进行调查.它如何通过不断增长的数据结构来执行？
我有一个基本的问题,我应该在mongo db中嵌入一组关注者/跟随者.在用户对象中嵌入一个嵌入式集合是有意义的,但同样嵌入逆向关注者集合也是有意义的吗？这意味着我必须更新并嵌入以下两个的配置文件记录中:
除非我以某种方式在某处保留事务或更新状态,否则我无法确保原子性.是否值得嵌入两个实体或者我应该更新#1,嵌入跟随者的个人资料中,并在其上放置一个索引,以便我可以查询所有配置文件中的反向跟随者？性能是否受到太大影响？
这是不应该嵌入的集合的候选者吗？我是否应该只有一个边缘集合,我将其存储在自己的集合中,并使用followerid和followbyId？
现在,如果我必须在跟踪或关注两个用户时更新供稿,我应该如何组织它？
至于用例,用户在查看他们的Feed时会看到他们正在关注的人,这种情况经常发生,并且当他们查看任何人的个人资料详细信息时也会看到个人资料的关注者,这也经常发生但不完全如同就像第一例一样.在这两种情况下,每个个人资料页面上都会显示关注者和关注者的总数.