求助十亿级数据库解决方案，是否有比 PostgreSQL 更好的选择？

[hxz0803]

现有几十台测试机，每天一共生成两百万行的测试数据，每一行包含了测试时间、几个设置项与200-300 个测试结果。测试结果几乎都为 20 位浮点数。
需求
1.在特定的设置项下，求出每台机每小时各种测试数据的平均值
2.查询特定设置项与测试时间下的测试结果

其他要求：
1.测试结果可能会有增减，意味着可能要在生产中新增列，可以不减列。
2.一台测试机会同时测几颗 IC （机台有好几个栏位可以同时测试），意味着会有几行数据时间完全相同的情况
3.如果解决方案需要行的唯一性，那这个唯一性需要机台+测试时间+栏位来确定。
4.暂时没钱上分布式
5.暂时不会上云

现在的实现思路：
1.上 PostgreSQL，测试时间按每日水平分表，用的是内置分区表（之后考虑用 pg_pathman ）
2.BRIN 索引各设置项与测试时间
3.建一个平均值表，每小时把上个小时各项测试数据的平均值加进去

问下还有没有更好的解决方案？

感谢各位的建议，由于考虑到运维难度、操作系统支持（ windows 支持可能是必不可少的）与在公司内推广的可行性，最后选定 TimescaleDB

[lolizeppelin]

时序的数据？ 装 pg 的 timescaledb 插件啊

不用自己弄分区和 BRIN 索引了

[lolizeppelin]

思路都是找时序型数据库
PG 正好有时序插件, 比专门的时序数据库差一点,但是功能上是标准的 sql

[StarkWhite]

TiDB 吧，听说是专为海量数据的 OLTP 和 OLAP 而生的
https://pingcap.com/

[EmdeBoas]

不适合 TiDB，考虑时序数据库（ TDengine 最近好像挺火=-=没实际用过）或者专门的 AP 引擎都行

[liprais]

tidb 的 olap 跟没有也差不了多少

[opengps]

没用过 PG，不敢多说话，我按照关系型数据库回复下，看看能不能找到什么突破办法

需求
1.在特定的设置项下，求出每台机每小时各种测试数据的平均值
--每天 1-200 万这个数量级还行，适合每天一个单表
2.查询特定设置项与测试时间下的测试结果
--不知道具体业务答不上来

其他要求：
1.测试结果可能会有增减，意味着可能要在生产中新增列，可以不减列。
---每天一张表的量不算多，插入时候不至于太明显影响性能
2.一台测试机会同时测几颗 IC （机台有好几个栏位可以同时测试），意味着会有几行数据时间完全相同的情况
--类似于无主键的设计，但是要用时间列聚集索引，这里我也先想到了时序数据库
3.如果解决方案需要行的唯一性，那这个唯一性需要机台+测试时间+栏位来确定。
--行唯一性建议用唯一联合索引
4.暂时没钱上分布式
--首先你这个算集群不算分布式，分布式是不同任务的多个组件。集群是相同职能的多台机器
--然后你的量有点大，注意用多块硬盘，增加硬盘数量分散 io，具体依赖 raid 还是手动分硬盘存储看自己情况
5.暂时不会上云
--看得出来是内部测试终端类设别使用，选型时候从来都是建议越靠近用户越好，不上云并不是坏事，注意做好备份

[sadfQED2]

这个问题，我咋感觉看过几次了？我记忆错乱了吗

[lixia625]

上分布式 和 有没有钱 有必然关系吗

[snappyone]

@lixia625 分布式需要多台机器，有的公司机器抠门的要死

[est]

量级到千亿就可以考虑 clickhouse 了。而且我寻思 求出每台机每小时各种测试数据的平均值 这个是不是可以自己去做累加。。

[lixia625]

@snappyone 现在满大街的虚拟化，分布式和多台机器没啥必然关系，算力才是关键

[optional]

如果查询只是几个 aggregate 的话 pipelinedb

[wlw0327]

pipelineDB+1

[lolizeppelin]

楼上真是搞笑, 虚拟化用傻了？
一台机虚拟出 10 台是算例翻倍了还是 IO 翻倍了

没钱没机器还上分布式,你当做实验啊？
直接物理机都不够用, 还套一层虚拟化？

[AngelCriss]

上次不是有人推荐 citus 吗？

[orc]

没细看你的需求，不过 clickhouse 可以了解一下。

[snappyone]

@lixia625 虚拟化的机器就不要钱了？分布式存储 nosql 这种动不动就几十几百个节点的，没钱怎么玩

[CodeCore]

对啊，为啥不用 citus

[test0x01]

说个你不敢用但肯定行的—— MonetDB