我们有一个云系统,每个客户都有自己的虚拟网络。目前,我们有分配给DB上每个客户的网络子网列表。
它们与这些存储在网络表中……
我猜最好的设计是每个IP只有一行。如果您使用的是IP-v4,那么最多可能有40亿个可能性 - 而您的公司并不拥有大部分IP-v4。这表明如下:
| network | ip | reserved_by | reserved_date
有了 不可用 在保留新地址时,ips对您的环境非常有帮助。这尤其正确,因为您可能有不连续的范围 - 如果不是现在,那么随着您变得更加成功并且必须获得更多IP地址。
您还可以使用触发器或存储过程来维护表,如您所述,以使两者保持同步。
这种解决方案对于IPv-6可能是不可行的,至少不是在最精细的粒度级别。
我会推荐您在问题中建议的设计,但为了获得更好的性能,您可能希望以稍微不同的方式存储IP。每个部分可以用零填充左边,然后整个IP可以转换为BIGINT(使用IPv4)。这将允许使用大于和小于比较来有效使用索引,并且可以实现找到未使用的IP的“麻烦”过程,以找到在该范围中已经使用的第一个连续IP集合中的最大值,然后递增一。拥有一个可以转换为IP的整数表示形式的函数会很有帮助。
要与IPv6兼容,您将无法转换为BIGINT,因此您可以将其保留为VARCHAR(或拆分为多个整数)。此时,将IP递增1将变得不那么简单,但仍然可行。
无论哪种方式,策略都是填充IP的各个部分,以便您可以使用索引使流程尽可能高效。