mysql – 用于分析的数据库

我正在建立一个大型数据库,它将根据传入的数据生成统计报告.
该系统大部分将按如下方式运作：

>每天早上将上传大约400k-500k行 – 大约30列,主要是varchar(5-30)和日期时间.它以平面文件的形式大约60MB,但在DB中增加了适当的索引而急剧增长.
>将从当天的数据生成各种统计数据.
>将生成并存储来自这些统计数据的报告.
>当前数据集将被复制到分区历史记录表中.
>在一天中,最终用户可以查询当前数据集(已复制,未移动),以查找不太可能包含常量的信息,以及字段之间的关系.
>用户可以从历史记录表中请求专门的搜索,但查询将由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调整了数据库.

我们正在一个具有非常高的正常运行时间的环境中运行 – 电池备份,故障转移网络连接,备用发电机,完全冗余系统等.因此,MyISAM的完整性问题被称重并被认为是可接受的.

关于5.1：
我听说5.1的稳定性问题.一般来说,我认为最近(在过去12个月内)任何软件都不是稳固的.由于有机会重新设计项目,因此5.1中更新的功能集太多而无法通过.

关于Postgresql陷阱：
没有任何where子句的COUNT(*)对我们来说是非常罕见的情况.我不认为这是一个问题.
copY FROM不如LOAD DATA INFILE灵活,但中间加载表将解决这个问题.
我最担心的是缺少INSERT IGnorE.我们经常在构建一些处理表时使用它,这样我们就可以避免将多个记录放入两次,然后在最后只需要删除一些重复的GROUP BY.我认为它的使用很少,因为缺乏它是不容忍的.

解决方法:

我的工作尝试了一个试验项目,从ERP设置中迁移历史数据.数据的大小很小,只有60Gbyte,覆盖超过2100万行,最大的表有1600万行.还有大约1500万行等待进入管道,但由于其他优先事项,飞行员已被搁置.该计划是使用Postgresql的“作业”工具来安排可以每天重新生成适用于分析的数据的查询.

在1600万大的记录表上运行简单的聚合,我注意到的第一件事是它对可用RAM的敏感程度.在一个点上增加RAM可以获得一年的聚合值,而无需依靠顺序表扫描.

如果你决定使用Postgresql,我强烈建议重新调整配置文件,因为它往往带有最保守的设置(因此它将在内存很少的系统上运行).调整需要一点点,也许几个小时,但是一旦你达到了可以接受响应的程度,只需设置并忘记它.

一旦你完成了服务器端的调优(这完全是关于内存的,那就太惊喜了！)你会把注意力转移到你的索引上.索引和查询计划也需要一点努力,但一旦设置,您将发现它是有效的.部分索引是隔离那些包含“边缘大小”数据的记录的一个很好的功能.如果您在类似数据的海洋中寻找异常,我强烈推荐此功能.

最后,使用表空间功能将数据重定位到快速驱动器阵列上.