一位同事已经构建了一个带有PHP框架的Web应用程序,我们可以在其中配置一些API调用到其他系统。它们在夜间运行,将新数据导入Postgres数据库。由于Postgres是一个OLTP数据库而不是用于分析,我开始阅读有关Redshift的内容。但我无法弄清楚这一切是如何融合在一起的。
哦,对于分析,我们会看看可以在Redshift中使用DirectQuery的PowerBI。但正如我所看到的那样,Postgres没有这样的东西。
因此,对于我的问题,我将把所有内容分成四部分:
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作为唯一的数据库。
答案 0 :(得分:6)
这两个系统都有不同的后端,并用于某些非常特定的目的。虽然它们在处理少量数据时可以互换使用,但是当涉及批量读/写时会发生巨大变化。
我假设当你说你正在使用Postgres时,你的可能是一个行方向。
对于写入批量数据,首选行数据库,因为它是写入密集型的,如果您的操作涉及查询多行(使用分析目的的典型要求),则使用列DB。最佳组合始终将事务数据存储在面向行的数据库上,将分析所需的一些表迁移到列式数据库并在那里运行分析查询。这可能听起来很荒谬和昂贵,但如果他们不想与交易数据或分析数据妥协,这就是一些公司的执行情况。
如果您的公司是涉及重(金融)交易的基于产品的公司,并且您也捕获了user_persona,请分别在面向行和列的架构中拆分它们。
行DB是写密集型的。当应用程序进行批量事务时 写语句,它必须写在表上没有任何滞后。我'米 当然,你也有多个master_slave配置 数据也必须复制到奴隶,而且也是如此 实时。
现在必须要了解分析数据与事务数据非常不同。交易数据并不是很多 - 让我们说它会在订单表中创建一行,并为每个订单放置user_id
和一些基本的order_details
;但是每次用户登陆应用程序时,都会生成分析数据 - 屏幕上的点击模式,发送通知的详细信息等;体积庞大,无法以与存储交易数据相同的方式存储。
柱状方向(如在Amazon RS中)是读取密集型的 - 这是分析的典型要求 数据,因为将为给定的数据检索大量行 user_set - 发送的所有通知或所有屏幕的详细信息 浏览/用户点击。柱状DB是量身定制的 这样的要求。
柱状DB中的批量写入速度很慢;但由于它现在主要处理分析数据 - 没有实时数据并不重要。分析需要时间和数据,直到current_date-1
或延迟n
小时才可以引用用户角色。
对于拥有大量数据集的大型公司,需要进行权衡。我希望你现在对如何解决它有一个微弱的想法。
答案 1 :(得分:1)
您的问题不清楚您打算如何使用数据库,但最好的建议是尝试使用"正常"一切都是数据库(在你的情况下,PostgreSQL)。
如果您发现您的分析花费太长时间并且数据库中有数百万或数十亿行,那么您可以考虑使用Amazon Redshift进行更快速的分析查询。如果您的查询是只读的,您还可以考虑使用Amazon Athena,它可以直接从存储在Amazon S3中的文件中读取数据。
答案 2 :(得分:0)
Postgres数据库在这种情况下的用途是什么?
我建议将API调用的输出直接写入S3并从那里将它们加载到Redshift中。
如果这些API响应是JSON(可能),您可能需要将它们展平为CSV以便加载到Redshift中。 Redshift的JSON加载非常有限。