片ids和密码Ids的优缺点

Question

分布式系统可以通过薄片或加密ids (例如，128位murmur3)生成唯一ids。

想知道每种方法的优缺点是什么。

Answer 1

我将假设128位I，类似于UUID。不过，让我们从基线开始

TL;DR：使用随机ids。如果并且只有当您有数据库性能问题时，请尝试flake If。

自动增量ids

自动增量id是当后端系统为每个新实体分配一个唯一的、密集的id时。这通常是由数据库完成的，但并不总是这样。

一个明显的优点是，id对于您的系统来说是唯一的，尽管128位可能过高。

第一个缺点是每次公开id时都会泄漏信息。您泄露了其他ids (攻击者很容易猜到要查找什么)。您还会泄露您的系统有多忙(您的竞争对手现在知道您在一段时间内创建了多少is，并且可以推断，比如财务信息)。

第二个缺点是后端不再具有可伸缩性。您被绑定到一些速度慢、可伸缩性较低的id生成器上，这将始终是大型系统中的一个瓶颈。

随机ids

随机ids是只生成128个随机字节的时候。v4 UUID 122位随机ids (例如2bbfb5ba-f5a2-11e7-8c3f-9a214cf093ae)。它们实际上也是独一无二的。

随机rid消除了自动增量rid的两个缺点:它们不泄漏任何信息，并且具有无限的可伸缩性。

当将ids存储在b-树(àla数据库)中时，缺点就出现了，因为它们将树访问的内存/磁盘页随机化。这可能是你的系统慢下来的一个来源。

对我来说，这仍然是理想的id方案，你应该有一个很好的理由离开它。(即分析器数据)。

片状ids

Flake ids是随机ids，但高k位是从时间戳的较低位中提取的。例如，您可以在一行中获得以下三个ids，其中最上面的位非常接近。

1. 2bbfb5baf5a211e78c3f9a214cf093ae
2. 2bbf9d4ec10c41049fb1671d6616b213
3. 2bc6bb66e5964fb59050fcf3beed51b1

虽然您可能会泄漏一些信息，但是如果您的k和时间戳粒度设计得很好的话，情况就不太好了。

但是，如果你设计这些ids，它们的帮助可能会很小，或者更新得太少--导致b-树依赖于顶部的随机位来否定有用性，或者太频繁地因为更新而破坏数据库。

注意:时间粒度是指时间戳的低比特变化的频率。根据您的数据吞吐量，您可能希望这是小时，十分钟，或分钟。这是个平衡。

如果您看到If没有语义(即永远不要从顶部位推断任何内容)，那么您可以在任何时候不间断地更改这些参数，甚至返回到纯随机的k = 0位置。

密码ids

我假设您的意思是I中包含一些加密的语义信息。也许像哈希德

不利因素很多：

• 对于不同的数据，您将有不同的长度ids，除非您有固定长度的协议。
• 您可能会尝试将越来越多的信息添加到ids中。
• 看起来是随机的，但不需要在前面添加片状的时间戳。
• it会被绑定到生成it的系统上。您可以开始要求系统解密id的版本，而不仅仅是询问它所指向的数据。
• 系统会消耗解密ids以提取数据的时间。
• 您添加了加密问题
  • 如果密匙被泄露了怎么办？(最好不要太敏感的数据在那里，客户的名字，或天堂禁止信用卡号码)
  • 协调键旋转。
  • 像哈希德这样的小身份证可能是野蛮的攻击。

​

正如您所看到的，我一般不喜欢语义in。有几个地方我使用它们，虽然我把它们称为令牌。它们不会作为密钥存储在数据库中(或者很可能不会存储在任何地方)。

例如，我对分页令牌使用加密:分页API的加密{last-id / context}。我更喜欢这样做，而不是让客户端传递上一页的最后一个元素，因为我们对用户隐藏数据库上下文。它对每个人来说都更简单，加密只不过是混淆(没有敏感信息)。