Redshift作为替换或添加

Jon*_*bel 1 php postgresql amazon-web-services amazon-redshift

一位同事用PHP框架构建了一个Web应用程序,我们可以在其中配置一些API调用到其他系统.它们在夜间运行,将新数据导入Postgres数据库.由于Postgres是一个OLTP数据库而不是用于分析,我开始阅读有关Redshift的内容.但我无法弄清楚这一切是如何融合在一起的.

哦,对于分析,我们会看看可以在Redshift中使用DirectQuery的PowerBI.但正如我所看到的那样,Postgres没有这样的东西.

所以对于我的问题,我将把所有内容分成四个部分:

  • 应用程序(登录,配置api调用的界面)
  • 应用程序的用户数据(用户,api调用的模式)
  • 数据(来自api的答案,供以后分析)
  • Datawarehouse(存储分析数据)
Solution | Application | Userdata   | Data          |  Datawarehouse
-------- | ----------- | ---------- | ------------- |  ----------------
Now      |  PHP        |  Postgres  | Postgres      |  
1.       |  PHP        |  Postgres  | Postgres      |  Redshift
2.       |  PHP        |  Postgres  |               |  Redshift
3.       |  PHP        |  Redshift  |               |  Redshift 

所以问题是:"正确"的解决方案是什么?我可以使用我们拥有的基础设施,只需添加Redshift.但后来我的存储成本增加了一倍.我可以将应用程序数据存储在较小的数据库中,并将API中的数据直接存储到Redshift中,或者使用Redshift作为唯一的数据库.

Yus*_*san 6

这两个系统都有不同的后端,并用于某些非常特定的目的.虽然它们在处理少量数据时可以互换使用,但是当涉及批量读/写时会发生巨大变化.

在这里我假设当你说你正在使用Postgres时,你的大概是一个Row方向.

对于写入批量数据,首选行DB是首选,因为如果您的操作涉及查询多行(这是分析目的的典型要求),则使用列DB时会占用写入密集度.最佳组合始终将事务数据存储在面向行的数据库上,将分析所需的一些表迁移到列式数据库并在那里运行分析查询.这可能听起来很荒谬和昂贵,但如果他们不想与交易数据或分析数据妥协,这就是一些公司的执行情况.

如果您的公司是涉及重(金融)交易的基于产品的公司,并且您也捕获user_persona,则分别在面向行和列的架构中拆分它们.

行DB是写密集型的.当应用程序生成批量事务写入语句时,必须将它写在表上而没有任何延迟.我敢肯定,你也将拥有多个master_slave配置,因此数据也必须同时复制到从属设备,实时也是如此.

现在必须要了解分析数据与交易数据非常不同.交易数据不是很多 - 让我们说它会在订单表中创建一个行,并且会为每个下达的订单映射user_id一些基本数据order_details; 但是每次用户登陆应用程序时,都会生成分析数据 - 屏幕上的点击模式,发送通知的详细信息等; 体积庞大,不能以与存储交易数据相同的方式存储.

柱状方向(如在Amazon RS中)是读取密集型的 - 分析数据的典型要求,因为将为给定的user_set检索大量行 - 所有发送的通知的详细信息,或用户浏览/单击的所有屏幕.柱状DB是根据这些要求量身定制的.

柱状DB中的批量写入速度很慢; 但由于它现在主要处理分析数据 - 没有实时数据并不重要.分析需要时间和数据,直到current_date-1或延迟n数小时,总是可以参考绘制用户角色.

对于拥有大量数据集的大型公司,需要进行权衡.我希望你现在对如何解决它有一个微弱的想法.