UUID 主键和 Memcached
由于现在数据被如此频繁地缓存，并且只有在有新数据时才访问数据库（然后该数据被缓存，哈哈），使用 Int 主键与 UUID 主键甚至存在真正的性能差异。
例如，假设我正在构建 NetFlix。新电影被添加到数据库中，电影列表以及相关数据被放入缓存中。
用户搜索一部电影（搜索服务器处理此操作），然后找到一个列表，单击它并从缓存中检索数据。
在整个过程中，数据库从未被读取。
你有什么想法？
With Data being cached so often now and the database is only being accessed when there is new data (and then that data is cached lol) is there even a real performance difference for using Int primary keys vs UUID primary keys.
For example, lets assume im building NetFlix. A new movie gets added to the database, and the movie listing along with associated data is put into a cache.
The user search's for a movie (a search server handles this), then finds a listing, clicks on it and the data is retrieved from the cache.
In this entire process the database is never read.
What are your thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我是一个类似于 Netflix 的主要网站的架构师，你大部分都是正确的，几乎所有非事务性数据都被缓存，因此令人厌恶的优化数据库并不总是有回报。我们所有的电影标题都通过重复任务预先加载到内存缓存中，因此对于系统的库部分，数据库永远不会被实际客户访问。
尽管如此，我们在设计数据库结构和查询时并没有懈怠，因为我们希望预加载器尽可能快速高效地运行。
I am the architect a major site similar to Netflix and you are for the most part correct, almost all non-transactional data is cached so optimizing databases ad nauseum does not always pay off. All of our movie titles are pre-loaded into memcached by a recurring task, so for the library portion of the system, the database is never hit by an actual customer.
Still, we don't slouch when designing the database structure and queries because we want the preloader to run as fast and efficiently as possible.
我赞成使用 UUID（实际上是 GuidComb）作为 Primary钥匙。诚然，它确实使指标有些膨胀，但随着 64 位 RDBMS 无处不在，内存也相当便宜，我认为优点远远超过缺点。我最喜欢的是不必等到你插入才知道你的 PK 是什么。
I favor using UUID (GuidCombs actually) for Primary Keys. True it does bloat the indicies some but with 64bit RDBMS everywhere and memory being pretty cheap, I consider the advantages to far outweigh the drawbacks. Not having to wait until you insert to know what your PK will be is my favorite.
我支持克里斯的回答，但我也想指出，如果尝试一次将大量密钥加载到内存中，那么您将使用大量内存。
比较：
6ba7b810-9dad-11d1-80b4-00c04fd430c8 - 37 个字节，如果 \0 终止
则为 38 个字节，而 64 位整数只有 8 个字节。并且可能可以存储在单个寄存器中。
将此提升到一个新的水平。
假设您想将 100,000 个 id 加载到 RAM 中。
这将是 800,000 字节（64 位整数），或 3,800,000 字节！
更新：2010 年 10 月 8 日。
此外，验证 UUID 字符串有点困难，您必须使用正则表达式。
然而，验证整数很简单。 intval() php 或 .to_i ruby，以及 int() for perl。
这可以提高其他人向您发送可疑数据（网络机器人）的安全性
I support Chris's answer, but I also want to point out that if attempt to load a LOT of keys into memory at once, then you will use a lot of ram.
Compare:
6ba7b810-9dad-11d1-80b4-00c04fd430c8 - 37 bytes, or 38 if \0 terminated
Where as a 64 bit integer is only 8 bytes. And possibly can be stored in a single register.
To take this to the next level.
Lets say you want to load 100,000 ids into ram.
That is going to be 800,000 bytes (64 bit ints), or 3,800,000 bytes!
Update: Oct 8th, 2010.
Also, validating a UUID string is a little more difficult, you must use a regex.
However, validating an integer is simple. intval() php, or .to_i ruby, and int() for perl.
This improves security with respect to other people sending you suspect data (web bots)