我有一个针对OLTP进行了大量优化的Postgresql(v8.3)数据库.
我需要以半实时的方式从中提取数据(有些人一定会问什么半实时的手段和答案是我可以合理的频繁,但我会务实,作为一个基准让我们说希望每15分钟),并将其输入数据仓库.
多少数据？在高峰时段,我们谈论的是每分钟大约80-100k行的冲击OLTP端,非高峰将大幅下降到15-20k.最频繁更新的行是〜64字节,但是有各种表等,所以数据是非常多样的,每行最多可以有4000个字节. OLTP活跃于24×5.5.
最佳解决方案
从我可以拼凑起来,最实际的解决方案如下：
>创建一个TRIGGER,将所有DML活动写入一个旋转的CSV日志文件
>执行所需的任何转换
>使用本机DW数据泵工具将转换的CSV有效地泵送到DW中
为什么这样做？
> TRIGGERS允许选择性表是针对性的,而不是系统范围的输出是可配置的(也就是CSV),并且写入和部署相对容易. SLONY使用类似的方法,开销是可以接受的
> CSV容易快速转换
>容易将CSV压缩到DW中
替代考虑….
>使用本地日志记录(http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html).这个问题是相对于我所需要的,看起来很冗长,有点棘手的解析和转换.然而,它可能会更快,因为我认为与TRIGGER相比,开销较少.当然,这将使管理系统更加容易,因为它是系统的,但是再次,我不需要一些表(一些用于持久存储的JMS消息,我不想记录)
>通过ETL工具(如Talend)直接查询数据,并将其抽入DW …问题是OLTP架构需要调整以支持这一点,并且具有许多负面的副作用
>使用被调整/黑客入侵的SLONY – SLONY做好日志记录并将更改迁移到从属设备,所以概念框架在那里,但是所提出的解决方案似乎更容易和更干净
>使用WAL
以前有人做过吗？想分享你的想法？
我不会使用日志记录工具,除非您无法实现上述解决方案;日志记录最有可能涉及锁定开销,以确保日志行顺序写入,并且当多个后端写入日志时不要重叠/覆盖(检查Postgres源).锁定开销可能不是灾难性的,但是如果您可以使用增量SELECT替代.此外,语句记录会淹没任何有用的WARNING或ERROR消息,并且解析本身不会是即时的.
除非您愿意解析WAL(包括事务状态跟踪,并且每次升级Postgres时都可以重写代码),否则我不一定会使用WAL,也就是说,除非您有额外的硬件可用,否则,可以将WALs运送到另一台机器进行提取(在第二台机器上,您可以无耻地使用触发器,甚至是语句记录),因为在主机上不会影响INSERT / UPDATE / DELETE性能.)请注意,性能方面(在主机上),除非可以将日志写入SAN,否则从运行增量SELECT开始,将WAL发送到不同的计算机,可以获得可比较的性能命中(主要是从文件系统高速缓存方面).
