具有一个 ID 列、排序索引、具有重复主键的 Postgresql 表

Question

我想使用 PostgreSQL 表作为文档的一种工作队列。每个文档都有一个 ID，并存储在另一个带有许多附加列的普通表中。但是这个问题是关于为工作队列创建表的。

我想为这个队列创建一个没有 OID 的表，只有一列：文档的 ID 为整数。如果此工作队列表中存在文档的 ID，则表示具有该 ID 的文档是脏的，必须进行一些处理。 额外的表应避免 VACUUM 和死元组问题以及如果主文档表中的每个文档条目上只有一个脏位就会出现的事务死锁。

我系统的许多部分会将文档标记为脏，因此会将要处理的 ID 插入到该表中。这些插入将用于一个事务中的多个 ID。我不想使用任何类型的嵌套事务，并且似乎没有任何类型的 INSERT IF NOT EXISTS 命令。我宁愿在表中有重复的 ID。因此，该表中唯一的列必须可以重复。

处理工作队列的进程将删除所有进程 ID，因此会处理重复项。 （顺便说一句：下一步还有另一个队列，所以关于竞争条件，这个想法应该是干净的并且没有问题）

但我也希望按顺序处理文档：始终应首先处理 ID 较小的文档。

因此，我希望在 ID 列（工作队列表中的唯一列）上有一个帮助 LIMIT 和 ORDER BY 的索引。 理想情况下，我只有一列，这应该是主键。但是主键不能有重复，所以我好像做不到。

没有索引，ORDER BY 和 LIMIT 会很慢。

我可以在该列上添加一个普通的二级索引。但我担心 PostgreSQL 会在磁盘上添加第二个文件（PostgreSQL 会为每个额外的索引执行此操作）并为该表使用双倍的磁盘操作。

最好的做法是什么？ 添加一个带有随机内容（如 OID）的虚拟列，以使主键不会抱怨重复？我必须在我的队列表中浪费那个空间吗？

或者添加第二个索引是无害的，它会成为直接在主元组btree中的主索引吗？

---

我应该删除上面的所有内容并保留以下内容吗？最初的问题让人分心，并且包含太多不相关的信息。

我想在 PostgreSQL 中创建一个具有以下属性的表：

• 一列有一个整数
• 允许重复
• 列上的高效 ORDER BY+LIMIT
• INSERT 不应对该表或任何类型的唯一索引执行任何查询。 INSERT 应该只找到该表的主文件/主 btree 的最佳页面，并将行插入到其他行之间，按 ID 排序。
• INSERT 将成批发生，并且不能失败，除非磁盘已满等。
• 此表不应有额外的 btree 文件，因此没有二级索引
• 行不应占用太多空间，例如没有 OID

我想不出能解决所有这些问题的解决方案。

我唯一的解决方案是在最后一个要点上妥协：添加一个涵盖整数的 PRIMARY KEY 以及一个虚拟列，如 OID、时间戳或序列。

另一种解决方案是使用假设的 INSERT IF NOT EXISTS，或者嵌套事务或带有 WHERE 的特殊 INSERT。所有这些解决方案都会在插入时添加对 btree 的查询。 它们也可能导致死锁。

（也在这里发布：https://dba.stackexchange.com/q/45126/7788）

Answer 1

你说

我系统的许多部分会将文档标记为脏，因此 将要处理的 ID 插入到该表中。因此必须重复 可能。

和

具有相同 ID 的 5 行与具有相同 ID 的 1 或 10 行含义相同 相同的 ID：它们意味着具有该 ID 的文档是脏的。

你不需要重复。如果此表的唯一目的是识别脏文档，则包含文档 ID 号的单行就足够了。没有令人信服的理由允许重复。

如果您需要跟踪哪个进程插入了该行，或者在插入行时对行进行排序，则每个 ID 号只有一行是不够，但单列不足以 首先。所以我确信主键约束或唯一约束对你来说很好。

其他进程必须忽略重复键错误，但这很简单。无论如何，这些进程都必须捕获错误——除了重复键之外，还有很多事情会阻止插入语句成功。

---

允许重复的实现。 . .

create table dirty_documents (
  document_id integer not null
);

create index on dirty_documents (document_id);

在该表中插入 100k ID 号以进行测试。这必然需要更新索引。 （Duh。）包括一堆重复。

insert into dirty_documents 
select generate_series(1,100000);

insert into dirty_documents
select generate_series(1, 100);

insert into dirty_documents
select generate_series(1, 50);

insert into dirty_documents
select generate_series(88000, 93245);

insert into dirty_documents
select generate_series(83000, 87245);

在我的桌面上用了不到一秒钟，这没什么特别的，它正在运行三个不同的数据库服务器、两个 Web 服务器，并播放一张 Rammstein CD。

选择第一个脏文档ID号进行清理。

select min(document_id) 
from dirty_documents; 

document_id
--
1

只用了 0.136 毫秒。现在让我们删除文档 ID 为 1 的每一行。

delete from dirty_documents
where document_id = 1; 

耗时 0.272 毫秒。

让我们重新开始。

drop table dirty_documents;
create table dirty_documents (
  document_id integer primary key
);

insert into dirty_documents 
select generate_series(1,100000); 

耗时 500 毫秒。让我们再次找到第一个。

select min(document_id) 
from dirty_documents; 

耗时 0.054 毫秒。这大约是使用允许重复的表所用时间的一半。

delete from dirty_documents
where document_id = 1;

还花了 0.054 毫秒。这比另一张桌子快大约 50 倍。

让我们重新开始，尝试一个未索引的表。

drop table dirty_documents;
create table dirty_documents (
  document_id integer not null
);

insert into dirty_documents 
select generate_series(1,100000);

insert into dirty_documents
select generate_series(1, 100);

insert into dirty_documents
select generate_series(1, 50);

insert into dirty_documents
select generate_series(88000, 93245);

insert into dirty_documents
select generate_series(83000, 87245);

获取第一个文档。

select min(document_id) 
from dirty_documents; 

耗时 32.5 毫秒。删除那些文件。 . .

delete from dirty_documents
where document_id = 1;

耗时 12 毫秒。

所有这些都花了我 12 分钟。 （我使用了秒表。）如果您想了解性能如何，请构建表格并编写测试。

Answer 2

字里行间，我认为您正在尝试实施工作排队系统。

停下来。现在。

工作排队很困难。关系 DBMS 中的工作排队非常困难。人们提出的大多数“聪明”解决方案最终都会在他们没有意识到的情况下序列化锁上的工作，或者他们在并发操作中存在令人讨厌的错误。

使用现有的消息/任务排队系统。 ZeroMQ、RabbitMQ、PGQ 等等等等等等。有很多可供选择，它们具有（a）工作和（b）高效的显着优势。您很可能需要运行外部辅助进程或服务器，但关系数据库模型的局限性往往使这成为必要。

您似乎设想的方案，尽我所能猜测，听起来它在故障处理、插入/删除竞争等方面会遇到无可救药的并发问题。真的，不要 /em> 尝试自己设计，尤其是当您对潜在的并发性和性能问题没有真正掌握时。