现在的程序员都不会开事务了吗

begin;
select * from tbl for update skip locked limit 1;
# 处理逻辑
update from tbl where xxx=xxx set processed=1;
commit;

加了微信，clickhouse 有一定经验（其他数据库可能也有），可以无偿回答一些不是很费时间的问题，就当交流

那估计搞个 m1 的 mac mini ，12w 干活都够了

clickhouse 里面可以再加一个物化视图，用 ReplacingMergeTree ，用设备 ID 去重时间戳做版本号，查询的时候再用 window 查询查每个 ID 时间戳最大的，这样就可以获得一个最新的数据，而且这个物化视图会异步的自动清理老数据，速度应该可以很快

@beginor 大模型有 f32 ？现在训练基本都拿的 bf16/f16 来的，哪来 f32 的？

我感觉很多人既不懂加密、又不懂安全、又没有逻辑，楼主还是很懂的

再开一个 session ，查 select * from pg_stat_activity ，看看查询卡住的具体原因

算了一下，一年应该不超过 4000 亿，这个情况用 clickhouse ，认真设计一下表结构尤其是编码方式，应该是可以满足的，而且 CH 可以设置把老数据自动丢到对象存储，降低成本

两张表，写完就切另一张表吧

为啥不用 innodb 呢？ innodb 应该是 mvcc ，读写可以不冲突

X Elite 当年吹的那么牛逼，原来单核也就 M2 还差点的水平，到现在还没开卖，真是笑死个人

@wxf666 你算的很对，表大概 20G 多一点，但是索引不是这么存的，你可以理解为反向索引存了 tag 和这个 tag 在哪些行中出现，这里面我怀疑是用 bitmap+压缩来实现的，有兴趣可以看下 pg 的 gin 相关的代码，所以实际上索引体积只有 9G 左右

@freewind 你这几千条标签递归查估计也就 1ms 之内的事情

@wxf666 这个索引占用 9G 左右，pg 的 GIN 是通用反向索引，并不是直接按照这样展开存的，原理类似 es 的反向索引

@freewind 可以这样，也可以像#7 说的一样，每次用递归 CTE 把所有子层级标签查出来作为条件，这样标签层级可以更新，存储容量也可以小点，你们标签少可以考虑用更小的 int 做标签，也能省

一般 ORM 都有 raw sql 的模式吧

实测来了，
创建测试表，并插入 1 亿条测试数据，每一条包含 50 个随机标签，每个标签有 4000 种可能
create table tags_test(id serial primary key,tags array[int]);
create function random_array() returns int[] as $$ select array_agg((4000*random())::int) from generate_series(1,50)) $$;
insert into tags_test(tags) select random_array() from generate_series(1,100000000);
创建 GIN 索引
//最好临时增加 maintenance_work_mem ，会加快索引构建
//set maintenance_work_mem to 1GB;
create index ON tags_test using gin(tags);
简单查个包含几个 tags 的数据
postgres=# select count(*) from tags_test where tags @>array[1,2,3,4];
count
-------
2
(1 row)

Time: 135.185 ms
postgres=# select count(*) from tags_test where tags @>array[1,2,3];
count
-------
190
(1 row)

Time: 123.327 ms
当然，实际情况下标签肯定不是随机分布的，可能会更快或者更慢，也可以试试用 jsonb 来存和查，结果应该差不多

nats jetstream 只有 6 大概没有其他全符合