@dtgxx 每个属性都可以加 skipindex

clickhouse,模糊匹配用 ngrambf_v1 索引, 性能和灵活性比 es 高太多了。https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree#available-types-of-indices

建议把 pg 的隔离等级文档看一下，就比较清楚了 http://www.postgres.cn/docs/12/transaction-iso.html

@chaleaochexist pg 下，序列化隔离等级，也不会锁表，依然是读写无冲突，但是会带来额外开销，降低性能。其他常用数据库不支持序列化隔离等级

用 k3s 吧，单二进制文件一行命令直接启动，而且是真的 k8s

@zhygkx ch 使用 ngram bloomfilter 做 skip index ，也可以一定程度满足全文索引的需求，效果也是很不错的

如果用的是 truncate ，那么有可能读到空表，因为 truncate 一般不支持事务。
如果使用的是 read uncommitted （ mysql 下是这样，pg 下不会），也可能是读到空表
其他情况不应该读到空表

go get 用 GOPROXY 不行嘛

试试 ponyorm

pg 支持原生的 upsert，insert into tbl values(xx,xx) on conflict(some_unique_key) do update set xxx=exclude.xxx;

@rapperx2 qq 吧，base64:MjUxNjUwMjky

@rapperx2 渐变语句要加上 oder by(车牌,时间),我怀疑你这边是直接按照日期排序了，这样找一辆车的数据也要扫全表，然后数据类型建议也再看一下车牌最好用个足够小的 int 作为，再建一张表用来存车牌和 ID 的映射，查询时使用 join，这样能显著减少查询的数据量（ 2300w 行就 2.17GB 太大了），数据结构越高效性能越高

@rapperx2 不正常，方便看一下表定义和查询嘛？

@rapperx2 对了，时间戳精度要求不高的话，可以用不需要用 DateTime64，可以 DateTime （精确到秒），经度维度可以用 UInt32 CODEC(DoubleDelta),方向不需要的话可以不存，这样估计还能小一倍，也能快一些。

@cqdx02 当然可以，group by 就可以，看上面的 Q6，使用对应的函数对时间进行处理就行

@rapperx2 我还真造了点数据来测试一下 clickhouse 。
表结构：
create table ts_test
(
ts DateTime64 CODEC(DoubleDelta),
car_id Int32,
lat Float32 CODEC(Gorilla),
log Float32 CODEC(Gorilla),
dir Float32 CODEC(Gorilla)
) engine MergeTree() order by (car_id, ts) partition by toDate(ts);
其中，方向 dir 平均 100s 随机刷新，速度 0-100 之间随机，ts 的间隔 1s±100ms 并加入随机抖动，20000 辆车，每辆车起始位置随机，然后模拟每辆车运动，生成 csv 数据导入 clickhouse 。共使用了 20 分钟导入了 983725233(9.8 亿)行数据，占用硬盘空间 9.45 GiB，大概每 1 亿行 1G 。
然后测试了一些简单的查询。
Q1: 查询某个车的完整轨迹: select * from ts_test where car_id=1;
行数和耗时：49187 rows in set. Elapsed: 0.041 sec.
Q2: 查询表总行数: select count(*) from ts_test;
行数和耗时：1 rows in set. Elapsed: 0.001 sec. （估计缓存了）
Q3: 查询每辆车的数据点数量: select car_id,count(*) from ts_test group by car_id;
行数和耗时：20000 rows in set. Elapsed: 0.129 sec.
Q4: 查询每辆车的活动范围（矩形）:select car_id,min(lat),max(lat),min(log),max(log) from ts_test group by car_id;
行数和耗时：20000 rows in set. Elapsed: 0.568 sec.
Q5: 查询一辆车的活动范围（矩形）:select min(lat),max(lat),min(log),max(log) from ts_test where car_id=100;
行数和耗时：1 rows in set. Elapsed: 0.003 sec.
Q6: 查询每小时的数据点（每小时约 7200w ）数量: select count(*),toYYYYMMDD(ts)+toHour(ts) as hour from ts_test group by hour;
行数和耗时：14 rows in set. Elapsed: 0.347 sec.

测试硬件：单机 AMD EPYC 7702P 64-Core Processor 64 核，256G 内存，SSD
希望对楼主有帮助

顺便，现在如果是少量数据的 update，clickhouse 可以使用 mutations 完美完成，如果量大的话，可以用 collaspemergetree 引擎，变相实现标记删除并且不影响查询结果

@yjhatfdu2 比 hive 或者 HBase+mr/spark 之类的的方案大概也就快几百倍把

这个场景，clickhouse 使用 mergetree 引擎，根据日期做分区，车辆 ID,timestamp 排序，clickhouse 对于 float 类型时序数据也有类似时序数据库的 Gorilla codec，有效压缩时序浮点数据。clickhouse 本身的话，支持分布式、高可用，支持 SQL （部分），可以用 http 接口直接访问，使用难度很低。性能的话，我们做过一些测试，单节点 64 核 epyc2+256G 内存，单表 15 亿行 20 多列的纽约出租车数据，单个全表级的 group by+sum 大概 200ms 左右，多个维度的 group by+多个聚合能在 700ms 内完成，基本上是现在分析库的上限了。https://clickhouse.tech/docs/en/getting-started/example-datasets/nyc-taxi/