3

假设我想在 RethinkDB 中建模构建一些小部件。构建过程开始，获取一个唯一的 ID，开始工作一段时间，然后在完成后将数据写入数据库中给定的 ID 下。有许多类型的小部件，并且 ID 在所有小部件中应该是唯一的。

如果我在 Postgres 中执行此操作，我可能会有一个主widget表，每个小部件类型（widget_x、widget_y等）都有一个表继承自该主表。ID 将是主widget表上的 SERIAL 类型。当构建过程开始时，我会插入一些数据，获取我的唯一 ID，开始工作，然后在构建完成后更新表格。我可能不会在整个过程中使用事务，因为构建可能需要很长时间。

在 RethinkDB 中如何做到这一点？我真的需要 ID 是一个递增的整数，所以我不能使用默认的 UUID 键。我希望每个小部件类型都在它自己的表中。

如果我在每个小部件构建开始之前执行此查询：

r.table("counters")
    .get("some-uuid-key")
    .update({ widget_counter: r.row("widget_counter").add(1) }, {return_vals: true})

这会像我希望的那样工作，给我数据库范围的唯一 ID，而没有任何 ID 冲突的可能性吗？

谢谢...

4

2 回答 2

2

您所拥有的将起作用，并且与我认为的该问题的规范解决方案一样接近。在集群环境中，全局唯一的升序 ID 或多或少是不可能的，这就是为什么我们默认没有将它们作为选项的原因。你在这里所拥有的东西是有效的，因为每个请求都必须通过一台机器来获取它的 id（"counters"表的主机。这有一个缺点，如果那台机器死了，每个需要获取 id 的查询都将开始失败。

于 2014-01-09T17:36:10.397 回答
1

在数据库中拥有一个计数器表可以保证以更好的 HA（高可用性）为代价的顺序。

如果您不需要绝对增量数字，只喜欢公开公开的记录的短整数，您还可以设置一组票务服务器..每个服务器给出每个第 N 个数字。一开始您将获得冗余和较低的数字，但您无法保证顺序，并且随着时间的推移可能会有很大的偏差。我想到了这样一个系统，每个客户端也可以传递它获得的最后一个 id ......这样如果漂移大于 X，它可以向前跳过以控制漂移。

如果您有未公开的 ID（例如在查询字符串上，甚至在那时），我发现 UUID 几乎是作为大多数类型数据库记录的键的最佳支持选项。

于 2015-11-14T23:50:30.053 回答