"Mark Mielke" <mark@mark.mielke.cc> writes:
> - Increased keyspace. Even if keyspace allocation is performed, an int4 only
> has 32-bit of keyspace to allocate. The IPv4 address space is already over 85%
> allocated as an example of how this can happen. 128-bits has a LOT more
> keyspace than 32-bits or 64-bits.
The rest of your points are valid (though not particularly convincing to me
for most applications) but this example is bogus. The IPv4 address space is
congested because of the hierarchic nature of allocations. Not because there
is an actual shortage of IPv4 addresses themselves. There would be enough IPv4
for every ethernet device on the planet for decades to come if we could
allocate them individually -- but we can't.
That is, when allocating an organization 100 addresses if they want to be able
to treat them as a contiguous network they must be allocated 128 addresses.
And if they might ever grow to 129 they're better off just justifying 256
addresses today.
That's not an issue for a sequence generated primary key. Arguably it *is* a
problem for UUID which partitions up that 128-bits much the way the original
pre-CIDR IPv4 addressing scheme partitioned up the address. But 128-bits is so
much bigger it avoids running into the issue.
The flip side is that sequence generated keys have to deal with gaps if record
is deleted later. So the relevant question is not whether you plan to have 2
billion users at any single point in the future but rather whether you plan to
ever have had 2 billion users total over your history. I suspect large
networks like Yahoo or Google might be nearing or past that point now even
though they probably only have a few hundred million current users.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!