我们有1500多个本地服务器，在那里我们使用PostgreSQL数据库来存储一些销售交易数据。每个本地服务器每天将添加大约200多条记录，因此每天大约有300000条记录(上午8点到晚上10点之间(。
我们需要将每笔交易存储至少18个月，这意味着数据可能达到167.000000条记录。
现在，我们有一个分析这些事务的请求，我们正在考虑开发一个集中的解决方案，这样我们就可以对它进行一些BI
最好的方法是什么？
在每个本地服务器中，我都会创建一个新的表，该表只包含对新创建的事务ID的引用。我每次都会使用这个额外的表来查找尚未同步的最新事务。一旦同步完成，我就会删除引用，等待新的引用出现。
然后，我在考虑开发一个具有自己的基础设施的REST API，该基础设施保存所有1500+DB实例的连接字符串，并且不时地检查每个实例的"；什么是新的"在DB中。，以集中保存数据。
从那里，我将开发一个用于报告的GUI。现在，我将在这个REST API(可能是Azure(上实现云计算，但不幸的是，我从未经历过搜索数百万条记录，所以这对我来说是一件新的事情。CosmosDB是存储此类数据的好解决方案吗？
还有其他的"；最佳方法"；为了这个？
PG的问题是，当您使用来自同一集群或不同集群的几个不同数据库时，查询执行的联接将涉及"；远程联接"；其不多于也不少于将整个表远程复制到临时表中以执行嵌套循环类型联接的副本。这是性能最差的情况。。。
就BI而言，PostGreSQL远不是最好的RDBMS。在我看来，它是性能最差的，仅高于SQL Lite！COUNT或SUM类型的聚合计算。。。是可以想象的最糟糕的表现。阅读：
PostGreSQL与Microsoft SQL Server的比较第2部分：COUNT性能此外，还缺乏某些技术，这些技术可以大大加快对大表和大量数据的开发：
- 无压缩
- 没有垂直索引(例如columnstore…(
- 否"；在存储器中"；表
- 胚胎平行性
- 性能受限分区
对于列库索引，您可以使用Fujitu版本的PG，但它需要花费很多。。。
所以我的建议是不要使用PG的戏剧功能。选择另一个RDBMS，如Terradata、Oracle或MS SQL Server(成本较低，性能优于Oracle(