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