URL 缩短服务中的索引是如何完成的

Question

我正在学习设计系统。第一个用例是 URL 缩短服务。我读到我们可以在 RDBMS 中存储 short_url,long_url 对。由于根据要求，我们应该能够将 short_url 映射到 long_url（以便可以将其发送到调用客户端）以及从 long_url 映射到 short_url（这样现有映射的 long_url 就不会再次缩短）。我的问题是这些 mappings/look-ups 如何在 RDBMS 中有效地完成。直接的答案是维护 short_url 上的索引以及 long_url 上的索引。我想探索它的细节，比如一般情况下在 RDBMS 中完成的两种情况下的索引技术。

Answer 1

根据我从你的描述中收集到的信息，你实际上并没有“映射”任何东西，你只需要存储一个 URL 及其简短的等价物。

所以除非有任何其他信息，否则我会倾向于

create table URLs (
Id int identity(1,1),
  LongURL varchar(200),
  ShortURL varchar(20),
  CreateDate datetime default (getdate())
)

create unique clustered index IdxShortURL on URLs (ShortURL)
create nonclustered index IdxLongURL on URLs (LongURL)

主要是在给定短 url 的情况下，您将查找长 url，因此这是索引唯一且聚集的，数据库可以直接查找它并 return 完整URL

您可以使用 LongURL 上的非聚集索引来检查 URL 是否已经存在。

编辑

扩展索引策略 - 这实际上取决于预期的使用情况。通常在监控查询执行计划后会出现正确的索引策略。

是的，两者都是相似的字符列，但是 - 这是我的假设 - 长 URL 将主要使用短 URL 比相反情况更频繁地查找，即，我有短 URL，我需要查找长 URL - 在这种情况下，短 URL 是 table 的 'Id' 的同义词，它是您访问其他信息的密钥。

通过将短 URL 指定为唯一和集群，table 中的数据按短 URL 物理排序，并且当使用短查找行时URL，等效的 long URL 作为索引的叶级别的一部分立即可用，并且单个查找操作可以检索它。

相反 - 同样是我的假设 - 你不想添加 URL 如果它已经存在并且检查 URL 的存在将通过寻找长 URL，所以这个列上的单独索引就足够了；即使您需要检索短 URL 作为此查找的一部分，因为 URL 是唯一的，它只是一个单一的书签查找，非常快速和高效。

YMMV 但希望这符合您的意图。

URL 缩短服务中的索引是如何完成的

How indexing is done in URL shortening service

architecture

indexing

database-design

url-shortener

system-design