我是noSQL技术的新手,我很惊讶没有任何交易支持.我的主要问题是当我完成一些插入任务时,插入包含~5个单独的插入.我们必须通过4个不同的ID找到一份文件.问题是该文档相当大,存储它是非常昂贵的:
关键| 值
user1 HugeDoc1
user2 HugeDoc1
user3 HugeDoc1
因此,我们提出了一个内部标识,指向文档.是的,我知道这个设计有点违反了整个noSQL概念,但它节省了大量内存.如果文档插入失败,则ID没有意义,应该删除.编写自己的回滚处理,跟踪成功的插入/更新是一个好主意吗?或者整个概念是错的?
我知道这个设计有点违反了整个noSQL概念,但它节省了大量内存.
这是一种非常1970年代的思维方式.关系数据库理论起源于磁盘空间昂贵的时候.1975年,IBM以每兆字节 11000美元的价格销售硬盘.到1980年价格下降,你可以以不到100万美元的价格购买一块千兆字节的存储空间.今天,您可以花费60美元购买NewEgg并购买一个TB级硬盘.现在磁盘空间很便宜,处理时间也很昂贵.
在非关系(NoSQL)数据建模中,您应该根据查询数据的方式构建表结构.这与关系数据建模不同,您可以根据存储数据的方式来构建表.通常,基于查询的建模会导致存储冗余数据...... 这没关系.速度重复数据,完整性参考数据.
编写自己的回滚处理,跟踪成功的插入/更新是一个好主意吗?或者整个概念是错的?
我在一个Cassandra项目中,我们实现了类似于应用程序端事务/回滚的东西.它真的不能很好地工作,并最终创建了几个墓碑.最后,我会问你自己为什么你的应用程序需要一个非关系数据库,因为听起来你仍然需要一些关系数据库的好处.如果您确定您绝对需要非关系数据库,那么您可能需要重新考虑数据建模的方法.