Question

我有一个NoSQL设置如下：

UserId : ContentId : OrderId
User1  : Content1  : 0 
User1  : Content2  : 1
User2  : Content3  : 0
User2  : Content4  : 1
User2  : Content5  : 2
User2  : Content6  : 3
User2  : Content7  : 4

我得到按订单排序的User2项目列表

SELECT * FROM table WHERE UserId = 'User2' SORT BY OrderId DESC

导致

UserId : ContentId : OrderId
User2  : Content3  : 0
User2  : Content4  : 1
User2  : Content5  : 2
User2  : Content6  : 3
User2  : Content7  : 4

大！现在我想交换，以便表格如下所示：

UserId : ContentId : OrderId
User2  : Content3  : 0
User2  : Content6  : 3
User2  : Content4  : 1
User2  : Content5  : 2
User2  : Content7  : 4

所以我将Content6移到Content3之后和Content4之前。现在的缺点是更新OrderId我必须更新Content3之后的每一行，导致多次写入数据存储区。

在NoSQL数据库中执行此操作的更好方法是什么？

Answer 1

您可以使用更复杂的算法解决此问题，您可以在键之间创建一个很大的间隙，然后您可以将项目从一个位置移动到其他键之间。

过了一段时间，一些空格可能会耗尽，所以这种情况下的算法必须规范化表格，甚至是密钥之间的间隙，导致一次性程序在数据库上稍微重一些。例如，当您检测到您正在运行/用完空间时，可以定期或按需完成此操作。

所以原始表格如下：

在

UserId : ContentId : OrderId
User2  : Content3  : 0
User2  : Content4  : 1000
User2  : Content5  : 2000
User2  : Content6  : 3000
User2  : Content7  : 4000

在

UserId : ContentId : OrderId
User2  : Content3  : 0
User2  : Content6  : 500
User2  : Content4  : 1000
User2  : Content5  : 2000
User2  : Content7  : 4000

Answer 2

在一个好的NoSQL解决方案中进行大规模更新是没有问题的，因为更新看起来像是附加到通常称为Write Ahead Log的文件。例如，如果您发出1000000个更新，并且每个更新大小为32个字节，那么它将导致只写32MB到一个文件，即使在磁盘上也可以在不到1秒的时间内完成。此外，如果所有这些更新都在一个事务中，那么这应该只是一个带有大缓冲区的write / writev系统调用。

NoSQL存储可重新订购的元素列表

2 个答案: