我正在编写一个具有用户文档的rails应用程序,该用户文档具有大约20个不同的属性。每次更新属性时,我都需要将其存储在交易文档中,该文档将更改谁,更改了哪个属性以及属性的旧值和新值。
有一个单独的文档存储交易是否有意义?或者我应该使用像CouchDB这样默认支持版本控制的noSQL DB,然后我不必担心创建交易文档。
如果我决定创建交易文档,那么文档的关键字将是动态的。
当我需要提取历史记录时,我可以提取文档的所有版本并动态计算出来吗?
答案 0 :(得分:1)
我不会将给定用户的所有交易存储在单个文档中。此文档将变得非常大,当您必须将其带入内存时,它可能会开始占用大量内存。查询各种事务可能也很困难(即查找修改了name属性的给定用户的所有事务)。
答案 1 :(得分:0)
CouchDB中的版本控制和类似的NoSQL数据库有点误导,我也像你之前那样犯了同样的错误。版本控制只是意味着 - 乐观并发。这意味着如果要更新文档,则需要提供旧版本号,以确保没有任何内容被覆盖。因此,当您获得文档并且同时其他人更改它时,您的版本号已过期(或不同步),您需要再次阅读它并在将其提交到数据库之前应用所需的更改。此外,一些NoSQL商店允许您忽略此版本控制,而其他商店(如CouchDB)则强制执行它。
回到主题 - 版本控制不会做你想要的,你宁愿寻找经常写的日志存储,很少读(因为我认为,你不会经常阅读历史记录)。在这种情况下,如果您需要高吞吐量,Cassandra是完美的,但任何其他NoSQL或SQL DB也可以完成这项工作,具体取决于您的性能要求。