[ListMistress]

GUIDs are HUGE and have a significant impact on performance. Go read Kimberly Tripp's blog post referenced in the article. She does the math for you.

In almost all the cases that I see GUIDs, they were totally unnecessary for the design. Even the developer who designed them could not give a reason why they needed to be GUIDs. A row unique across the entire universe? Really?

I'm not saying there are no cases...just that in most cases they negatively impact performance with little business or logic gain for that price. All design decisions come down to cost, benefit and risk.

[jaylevitt]

How do modern distributed OLTP systems deal with generating unique sequence numbers? Back in the day, this was a big problem, and I always thought that GUIDs would someday be a solution (though at the time, any string was too big/slow to be a primary key). Having one key-issuing server was a SPF; sharding the key ranges by server made it difficult to add new servers.

[emmelaich]

You can have the main key issuing server issue blocks to distributed key issuing servers. The keys are not necessarily increasing with respect to row creation time nor are they gapless but it's good enough for many purposes. It's also still a SPoF but not a single point of contention bad enough to affect performance significantly.

[jaylevitt]

Interesting.. how do you deal with ID collisions after rollover? That was our big problem, even with 8-byte IDs - the ID allocator had to know the Global Truth. Dealing with collisions as "exception, try the next one" was too expensive, though with faster hardware that may be moot.

[emmelaich]

Yes, rollover is an interesting problem. With the app and scale that we're operating at that will not happen within the next few thousand centuries though. I'm actually describing how I might go about doing it, and what I /think/ Oracle RAC does.

I'm not actually certain as to the implementation.