我正在建立一个大型数据库,它将根据传入的数据生成统计报告。
该系统的大部分操作如下:
- 每天早上将上传大约 400k-500k 行 - 大约 30 列,主要是 varchar(5-30) 和 datetime。它在平面文件形式时大约为 60MB,但在添加了合适的索引后在数据库中急剧增长。
- 将从当天的数据生成各种统计数据。
- 将生成并存储来自这些统计数据的报告。
- 当前数据集将被复制到分区历史表中。
- 在一天中,最终用户可以查询当前数据集(被复制,而不是移动),以获取不太可能包括常量但字段之间关系的信息。
- 用户可以从历史表中请求专门的搜索,但查询将由 DBA 制作。
- 在第二天的上传之前,当前数据表被截断。
这基本上是我们现有系统的第 2 版。
现在,我们正在使用 MySQL 5.0 MyISAM 表(Innodb 仅在空间使用上就被扼杀了)并且在 #6 和 #4 上遭受了很大的痛苦。#4 目前不是分区表,因为 5.0 不支持它。为了避免将记录插入历史记录所花费的大量时间(数小时和数小时),我们每天都将写入一个未索引的 history_queue 表,然后在我们最慢的时间的周末将队列写入历史表。问题是一周内生成的任何历史查询都可能晚几天。我们无法减少历史表上的索引,否则它的查询将变得不可用。
对于下一个版本,我们肯定会至少迁移到 MySQL 5.1(如果我们继续使用 MySQL),但强烈考虑使用 PostgreSQL。我知道辩论已经进行到死,但我想知道是否有人对这种情况有任何建议。大多数研究都围绕网站使用展开。索引确实是我们使用 MySQL 的主要优势,似乎 PostgreSQL 可以通过部分索引和基于函数的索引来帮助我们。
我已经阅读了数十篇关于两者之间差异的文章,但大多数都是旧的。PostgreSQL 长期以来一直被贴上“更高级但更慢”的标签 - 将 MySQL 5.1 与 PostgreSQL 8.3 进行比较还是普遍情况还是现在更平衡?
商业数据库(Oracle 和 MS SQL)根本不是一种选择——尽管我希望 Oracle 是。
对我们来说 MyISAM 与 Innodb 的注意事项:我们正在运行 Innodb,对我们来说,我们发现它慢得多,比如慢 3-4 倍。但是,我们对 MySQL 也较新,坦率地说,我不确定我们是否为 Innodb 适当调整了 db。
我们在正常运行时间非常长的环境中运行 - 电池备份、故障转移网络连接、备用发电机、完全冗余系统等。因此,MyISAM 的完整性问题被权衡并被认为是可以接受的。
关于 5.1:我听说过 5.1 的稳定性问题。一般来说,我认为任何最近(过去 12 个月内)的软件都不是坚如磐石的稳定。考虑到重新设计项目的机会,5.1 中的更新功能集实在是太多了,不容错过。
关于 PostgreSQL 陷阱:没有任何 where 子句的 COUNT(*) 对我们来说是非常罕见的情况。我不认为这是一个问题。COPY FROM 不如 LOAD DATA INFILE 灵活,但中间加载表可以解决这个问题。我最担心的是缺少 INSERT IGNORE。我们在构建一些处理表时经常使用它,这样我们就可以避免将多条记录放入两次,然后不得不在最后做一个巨大的 GROUP BY 来删除一些重复。我认为它的使用频率很低,以至于缺乏它是可以容忍的。