是)我有的：
>简单的服务器,一个xeon,8个逻辑核心,16 gb ram,mdadm raid1,2x 7200rpm驱动器.
> Postgresql
>许多数据可供使用.每天最多导入3000万行.
>时间复杂的查询可以执行长达一个小时
表的简化模式,将是非常大的：
id| integer | not null default nextval('table_id_seq'::regclass)
url_id | integer | not null
domain_id | integer | not null
position | integer | not null
上面的架构的问题是我没有关于如何对其进行分区的确切答案.
将使用所有期间的数据(没有查询将具有日期过滤器).
我想过在“domain_id”字段上进行分区,但问题是很难预测每个分区会有多少行.
我的主要问题是：
如果我不使用分区修剪而且我不打算删除旧数据,那么分区数据是否有意义？
什么是利弊？
如果我不进行分区,如何降低我的导入速度？
另一个与规范化有关的问题：
url应该导出到另一个表吗？
正常化的优点
> Table将包含平均大小为20-30字节的行.
>加入“url_id”应该比“url”字段快得多
非规范化的优点
>可以更快,更快地导入数据,因为我不必在每次插入之前查找“url”表.
任何人都可以给我任何建议吗？谢谢！
解决方法
如果您要在大多数查询中具有选择条件,允许计划程序在大多数时间内跳过对大多数分区的访问,或者您希望定期清除分配给分区的所有行,则分区最有用,或者都. (删除一个表是删除大量行的一种非常快捷的方法！)我听说人们达到了一个阈值,在这个阈值中,分区有助于保持索引更浅,从而提高性能;但实际上回到第一点,因为你有效地将索引树的第一级移动到另一个地方 – 它仍然必须发生.
从表面上看,听起来不像分区会有所帮助.
另一方面,标准化可能会比预期更好地提高性能;通过将所有这些行保持更窄,您可以在每个页面中获得更多行,从而减少整体磁盘访问.我会做适当的第3次正常形式规范化,并且仅基于证据表明它会有所帮助.如果在仍有第二个数据副本的磁盘空间时发现性能问题,请尝试创建非规范化表并查看性能与规范化版本的比较.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
