我有一个红色群集,我用于一些分析应用程序.我有要添加到clicks
表中的传入数据.假设我每秒要存储约10个新的"点击次数".如果可能,我希望我的数据尽快在红移中可用.
根据我的理解,由于柱状存储,插入性能很差,因此您必须按批次插入.我的工作流程是将点击数存储在redis中,每分钟,我都会将redis中的~600次点击作为批量插入红色.
我必须将一批点击插入到redshift中:
Multi-row insert strategy
:我使用常规insert
查询插入多行.这里有多行插入文档
S3 Copy strategy
:我将s3中的行复制为clicks_1408736038.csv
.然后我运行一个COPY
将其加载到clicks
表中.COPY文档在这里
我做了一些测试(这是在clicks
已有200万行的表上完成的):
| multi-row insert stragegy | S3 Copy strategy | |---------------------------+---------------------------+ | insert query | upload to s3 | COPY query | -------------+---------------------------+--------------+------------+ 1 record | 0.25s | 0.20s | 0.50s | 1k records | 0.30s | 0.20s | 0.50s | 10k records | 1.90s | 1.29s | 0.70s | 100k records | 9.10s | 7.70s | 1.50s |
正如您所看到的,就性能而言,首先在s3中复制数据看起来我什么也得不到.的upload
+ copy
时间等于insert
时间.
问题:
每种方法有哪些优点和缺点?什么是最佳做法?我错过了什么吗?
并提出问题:是否可以COPY
通过清单自动从s3 红移到数据?我的意思是一旦将新.csv
文件添加到s3中就立即复制数据?文件在这里和这里.或者我是否必须自己创建一个后台工作程序来触发COPY命令?
我的快速分析:
在关于一致性的文档中,没有提到通过多行插入来加载数据.看起来首选的方式是COPY
从s3开始使用唯一的对象键(每个.csv
在s3上都有自己唯一的名称)...
S3 Copy strategy
:
PROS:看起来像是文档中的好习惯.
缺点:更多工作(我必须管理存储桶和清单以及触发COPY
命令的cron ......)
Multi-row insert strategy
PROS:减少工作量.我可以insert
从我的应用程序代码中调用查询
缺点:看起来不像是导入数据的标准方式.我错过了什么吗?
Guy.. 41
Redshift是一个分析数据库,它经过优化,可以查询数百万条记录.它还经过优化,允许您使用COPY命令快速将这些记录摄取到Redshift中.
COPY命令的设计是将多个文件并行加载到集群的多个节点中.例如,如果您有一个5个小节点(dw2.xl)群集,如果您的数据是多个文件数(例如20个),则可以将数据复制速度提高10倍.文件数和每个文件中的记录数之间存在平衡,因为每个文件都有一些小的开销.
这应该引导您在COPY的频率之间取得平衡,例如每5或15分钟而不是每30秒,以及事件文件的大小和数量.
另一点需要考虑的是你拥有的两种类型的Redshift节点,SSD类型(dw2.xl和dw2.8xl)和磁性节点(dx1.xl和dw1.8xl).SSD在摄取方面也更快.由于您正在寻找非常新的数据,您可能更喜欢使用SSD,这通常是低于500GB压缩数据的低成本.如果随着时间的推移,您拥有超过500GB的压缩数据,您可以考虑运行2个不同的集群,一个用于SSD上的"热"数据,上周或下个月的数据,另一个用于磁盘上的"冷"数据你的历史数据.
最后,您并不需要将数据上传到S3,这是摄取时间的主要部分.您可以使用SSH COPY选项直接从服务器复制数据.请在此处查看有关它的更多信息:http://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-remote-hosts.html
如果您能够将Redis队列拆分为多个服务器或至少具有不同日志文件的多个队列,则可以获得每秒非常好的记录提取速度.
您可能需要考虑的另一种允许近实时分析的模式是使用Amazon Kinesis(流媒体服务).它允许以秒为延迟对数据进行分析,同时准备数据以更优化的方式复制到Redshift中.