KRT*_*Tac 9 sql database postgresql database-design
我正在计划一个数据库来存储大量文本.(博客文章,新闻文章等)数据库需要有标题,内容(最多50k字符),日期,链接和语言字段.在一个链接上不能发生相同的内容.旧内容(例如,早于30天)将被删除.
现在,问题是主键.我可以设置一个自动递增(SERIAL类型)字段并将其用作主键.但是,这似乎是愚蠢的,浪费了光盘空间,因为该领域不会用于任何目的,而是成为主键.(并且该字段最终可能会耗尽？或者总是存在其他性能问题:插入的每个新行的内容都需要检查重复项.因此,我提出的主键的另一个解决方案是计算内容+链接值的sha256哈希,然后将其放入新的"哈希"列并将其用作主键.一石二鸟.当然,问题是哈希冲突.这是一个很大的威胁吗？
我对PostgreSQL没有任何经验,对DBMS的经验也很少,所以在创建一个具有高速公路蜗牛性能特征的数据库之前,我会很感激第二意见(可怕的比较).
如果您对大型数据库有任何经验,请在这里帮助我.在我的情况下,将64个字符的字符串设置为主键字段是个好主意吗？(因为我的印象是通常这是避免的)
刚刚对一个相当中等大小的数据库(200GB +)进行了这个精确的测试,bigserial获得了相当大的优势.生成速度更快,加入速度更快,代码更少,占用空间更小.由于postgres存储它的方式,与普通int相比,bigint可以忽略不计.在您不必担心溢出bigint之前,您的内容将耗尽存储空间.完成计算的哈希与bigint - 代理bigint一路.
我会选择使用代理键，即。不属于应用程序业务数据的密钥。当您处理每条记录最多 50 KB 的文本时，额外的 64 位整数所需的额外空间可以忽略不计。一旦您开始将此键用作其他表中的外键，您实际上将使用更少的空间。
如果哈希所基于的数据发生变化，那么使用存储在记录中的数据的哈希作为主键是非常糟糕的候选者。然后，您也将更改主键，如果您有其他表与此表的关系，则会导致整个位置的更新。
附言。之前已经在这里提出过类似的问题并得到了回答。
这是关于该主题的另一篇精彩文章： http://www.agiledata.org/essays/keys.html
| 归档时间： |
|
| 查看次数： |
9977 次 |
| 最近记录： |