在网络场环境中生成 UUid

发布于 2024-08-18 08:45:27 字数 544 浏览 3 评论 0原文

我计划使用顺序 guid 作为主键/uuids,详见下面的帖子

与标准 Guid 相比,Sequential Guid 的性能改进是什么?

我想知道在网络场中的多个 Web 服务器上生成这些 guid 是否存在任何问题环境。我怀疑冲突的可能性极低,但事实上,网络服务器/时间戳的 MAC 地址会 毫无疑问,参与生成这些指南会让我犹豫不决。我想知道在高流量网站中是否存在排序混乱的可能性,并且可能会失去使用顺序指南的好处。

请让我知道您的经验是什么。

就其价值而言,我的环境是 ASP.NET 3.5、使用 Oracle 11g 的 IIS 7。 顺便问一下,Oracle 中的 guid 应该使用什么数据类型?我知道 Sql Server 有“uniqueidentifier”

谢谢你的建议 -维努

I am planning on using sequential guids as primary keys/uuids as detailed in the post below

What are the performance improvement of Sequential Guid over standard Guid?

I am wondering if there are any gotchas as far as generating these guids across multiple web servers in a web farm environment. I suspect the chances of collision are impossibly low but the fact that the mac address of the web server/timestamp would
doubtless be involved in generating these guids gives me pause. I wonder if the possibility exists in a high traffic website the ordering would be messed up and the benefit of using sequential guids might be lost.

Please let me know what your experience is.

For what it is worth, my environment is ASP.NET 3.5, IIS 7 using Oracle 11g.
Incidentally, what is the data type I should use for guids in Oracle? I know that Sql Server has "uniqueidentifier"

Thanks for your advice
-Venu

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

一指流沙 2024-08-25 08:45:27

因为我是您所指的帖子的创建者,所以我可以回答它。

我们在具有 2 到 8 个应用程序服务器的网络场中使用帖子中显示的 C# 代码(没有修改其中一个回复中详细说明的排序,我认为这可以进一步提高性能),并且从未遇到过并发问题,我相信Windows核心DLL中实现的SequentialGuid函数已经负责在不同的机器上创建不同的guid。

在数据库操作中,不同的机器插入不同的 Guid 意味着网络场中的每个不同的应用程序服务器将写入驻留在数据库的特定区域的数据(即应用程序服务器将写入以 12345 开头的 guid 和另一种的 guid 以 62373 开头),因此索引的更新仍然有效,因为页面拆分不会经常发生(或从不发生)。

因此,根据我的经验,如果您使用我在原始消息中概述的相同策略来生成指南,并且如果您在网络场环境中工作,如果您使用正确的方法来生成指南,则不会发生任何特定问题。

我会以任何方式避免从代码创建 Guid 以及以集中方式创建 Guid。

关于数据类型,我们使用 char(36),因为我们喜欢浪费大量空间!开玩笑吧,我们决定使用冗长的方式来写入数据,因为以清晰的格式保存数据可以大大简化维护工作,但是您可以使用 Oracle GUID 或简单的 RAW(16) 数据类型(它们基本上是相同的)并为每行预留 20 个字节。为了更轻松地浏览和编辑数据,您可以为客户提供一些函数来编码和解码原始 guid 数据,以便看到 guid 的文本表示形式。

Because I was the creator of the post you're referring to I can answer to it.

We're using the C# code shown in the post (without the modification of ordering detailed in one of the reply, that I feel could improve performance another little bit) in web farms with from 2 to 8 application servers and never had problems of concurrency, I believe that the SequentialGuid function implemented in the Windows core DLLs already takes care of creating different guid on different machines.

In database operation having different machines inserting different Guids means that each different application server in the web farm will write data that will reside on specific regions of the database (i.e. an application server will write guid starting with 12345 and the other one with guid starting with 62373) and so the update of indexes still works efficiently because page splits do not happens very frequently (or never).

So, from my experience, no specific problem happens if you use the same strategy to generate Guids that I outlined in my original message also if you're working in web farm enviviroment if you use the proper method to generate the Guids.

I would avoid in any way to create Guid from code and also to create Guid in a central manner.

Regarding data type we used char(36) because we like to waste a lot of space! Joke aside we decided to use a long and verbose way to write data because having data in a clear format ease a lot the maintenance, but you can use Oracle GUID or simply a RAW(16) data type (they're basically the same) and spare 20 bytes of for each row. To make browsing and editing of data easier you can provide your customer a couple of function to code and decode raw guid data so that the textual representation of the guid is seen.

琉璃繁缕 2024-08-25 08:45:27

Oracle 指南

Guid for Oracle

残龙傲雪 2024-08-25 08:45:27

您可能想看看 NHibernate 的 Guid Comb 生成器是如何工作的。我从来没有听说过碰撞。

You might want to take a look at how NHibernate's Guid Comb generator works. I have never heard of a collision.

葬心 2024-08-25 08:45:27

为了确保您拥有唯一的 GUID,只有 1 个服务器可以是所述 GUID 的创建者。

如果没记错的话,Oracle 不支持创建 MS 的“Guid for OLE”,但您应该能够利用它生成高度相似的内容: RAWTOHEX(SYS_GUID())

或者,您可以在单个服务器上驻留一个单独的应用程序仅负责生成 GUID(例如,调用位于特定服务器的 Web 服务,其唯一目的是生成并返回 GUID。

最后,GUID 是顺序的。即使您生成一个紧随其后,它们不会以与整数完全相同的方式递增(即最后一个数字不会在一个步骤中从 CD 中取出)。

To ensure that you have unique GUIDs only 1 server can be the creator of said GUIDs.

If memory serves, Oracle doesn't support the creation of MS's "Guid for OLE" but you should be able to generate something highly similar utilizing this: RAWTOHEX(SYS_GUID())

Alternatively, you could have a separate application residing on a single server that is solely responsible for generating GUIDs (for example, call a web service located at a specific server, whose sole purpose is to generate and return GUIDs.

Finally, GUIDS are not sequential. Even if you generate one right after another, they won't increment in the exact same fashion as an integer (i.e. that last digit won't go from C-D in one step). Sequencing requires integers or some other numeric data type.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文