数据库选型疑问：StarRocks主键表能否当作OLTP数据库表使用？

[鹏鹏在北京]

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】现在我有一个业务场景，根据估算，数据的极值大概就是121万的数据需要跟另外几千的数据形成一个笛卡尔积的大表。约单表40亿以上的量，按天分区，需要使用到主键表。
1：按照业务需求，其实应该放在OLTP类型的数据库中，比如mysql，tidb等等。
2：当前业务系统，如果完全使用关系型数据库，会跟其他业务系统混合部署，大批量数据初始化的时候会影响其他系统稳定性，所以不得已需要拆出独立数据库
3：mysql和TIDB ，单表40亿，用起来都不太现实，分表要上千张，分区的话，做某些查询又会很不方便，性能也跟不上，内存也吃不消。而且分区维护管理很复杂。

因为只有这么一张表特别大，而且必须长期留存，每年大概都是这个量，需要6年及以上。现在想请问一下，使用StarRocks的主键表做这种业务数据的存储+简单的单表 in / not in / group by / distinct / count 等sql。
是否合适？
主键表能不能当作OLTP类型的库表来使用？
有什么风险？

【背景】都是销售签合同的时候留的坑啊，客户抓到漏洞，数据量和要求直接翻了70倍！！

【业务影响】
【是否存算分离】
【StarRocks版本】例如：3.3.0

【联系方式】wp_space@163.com

[zhanghuaibei]

不能当oltp库使用，定位就是olap，sr要批量写入，更新删除也都要按照规范进行

[鹏鹏在北京]

按照业务场景，我一开始可能就会初始化这批数据。
如果我每次都是按照批量写入的方式，大概每次1000行左右。
并且，只有这一张表放到这个库里，其他的仍在mysql中，是否可行？

可以理解为，没有更新操作，只有 delete+insert 操作 。

主键表是否能保持跟 OLTP数据库一样的数据一致性？毕竟这玩意没有事务。

[zhanghuaibei]

写入是有事务的，你可以试试，看看这个批量能不能扛得住，频繁插入删除能不能扛得住

[鹏鹏在北京]

？！
所以，sr的主键表，写入，是有事务的？
那也就是说，主键表是可以保持数据一致性！

那不就简单了嘛。
40亿数据的初始化，我可以从业务上面调整，拉长周期，错峰执行。
之后每天的千万级数据变化，我也可以通过业务手段降低单日量级和频率。

靠谱了。啊，舒服了

既然写入是有事务的，如果全用主键表，为什么不能当作OLTP类型的数据库使用？
是因为，小量单行insert 的sql，频繁执行，会造成sr开销过大？

[zhanghuaibei]

是的，频繁执行，合并不过来，就比较麻烦，主要是这个问题

[鹏鹏在北京]

咱这个 频繁 的定义，官方有啥解释吗？
我计划一个定时任务，每晚定时往里面写，从凌晨三点到早晨8点之间，大概3300个左右的insert values
暂时就按照1fe 1be 来算吧。能行吗？

[jingdan]

两个写入间隔10s以上，insert into values生产不建议使用，1000个这样的sql相当于1000次写入，compaction来不及做，会导致后续的写入都失败

[jingdan]

按照3点到8点3300个写入的话，频率还行，写入的时候持续观察compaction进度吧，另外可以关注starrocks_be_max_tablet_rowset_num这个监控指标，这个表示的就是该be上当前最大的versioncount，超过1000对应的表写入就会报错too many tablet versions

[鹏鹏在北京]

只能用insert into values 。 因为客户还有实时和准实时的要求。
我也知道sr本身做这个事情不合适，如果我能把数据写入其他库，那我也不必纠结sr的这个问题了。
或者我可以考虑在TIDB里面，做一张1000个分区的大表？！

如果我生产环境部署sr
只有这么一个业务，也就这么一张大表
是不是理论上，控制写入间隔大于10秒就可以？

[test]

攒批去实现呢。实现一种准实时的效果，不一样要用insert into values的方式，先把数据攒到其他存储，如kafka之类的，然后通过实时链路去批量写入是不是也是一种方式呢

[test]

当然你这样也是可以的，只要不触发too many tablet versions，基本问题都不算大

[鹏鹏在北京]

大结局：
放弃starrocks ，继续使用TIDB。
单表，不分区，调整业务字段含义和作用，建立业务唯一索引。单表40亿数据

调整业务，
离线数据改用内部队列方式录入，拉长写入周期
每日定时数据，从业务角度拆分成按天递增，单日总量大概在千万左右，3节点单个并发测试批量写入不到1小时顺利搞定。
实时业务部分，应用程序内计算业务唯一索引，进行一次批量查询，耗时仅0.8秒。命中 Batch_Point_Get算子。

后面要考虑，过期数据怎么才能高效的定期删除？
TIDB不能根据数据内容，动态创建分区，真是一大败笔

[我要金坷垃]

不知道楼上使用的什么版本，以前sr我测试的时候确实频繁写入会有问题是因为主键表用copy on write方式，现在看3.3的文档是先写内存了，我现在集群是3.3.2，flink写入间隔1s压力不大，楼主可以测一下