komari 的节点如果很多的话建议数据库换为 PostgreSQL，提升明显

已经迁移到了 PostgreSQL，你可以让 ai 帮你迁移，很快很方便

deepseek v4 pro 分析结果，ai 含量 100%

komari 源码中 SQLite 的局限

1、单连接写入

// metricstore.go:141-145

// SQLite 串行化写入：固定单写连接以避免 "database is locked" 竞争

opts = append(opts,

    metric.WithMaxOpenConns(1),   // ← 只有一个写连接

    metric.WithMaxIdleConns(1),

    metric.WithSQLiteReadPool(4), // 额外读池缓解读阻塞

)



    

  

所有写入——包括多个 agent 同时上报、compaction、数据清理——都必须排队经过这一个连接。

2、聚合查询回退

func sqlAggValueExpr(driver Driver, agg Aggregation) (string, bool) {

    switch agg {

    case AggStdDev:

        switch driver {

        case DriverMySQL, DriverPostgreSQL:

            return "STDDEV_POP(value)", true  // ← MySQL/PG 可下推 SQL

        default:

            return "", false  // ← SQLite 不支持，回退到内存计算！

        }

    default:

        if frac, ok := percentileFractionString(agg); ok {

            if driver == DriverPostgreSQL {

                // ← 仅 PostgreSQL 支持百分位下推！

                return fmt.Sprintf("percentile_cont(%s) WITHIN GROUP (ORDER BY value)", frac), true

            }

            return "", false  // ← SQLite/MySQL 都不支持，回退内存！

        }

    }

}



    

  

• SQLite：必须把所有原始数据点从磁盘读到内存，在 Go 中完成计算


• PostgreSQL：只需一个 SQL 查询，数据库引擎原生完成计算，只返回最终结果

对于保留 90 天、每分钟一个采样点的场景，单个指标就有 ~130,000 行。如果有 10 个 agent、20 个指标，那就是 2600 万行。SQLite 做一次 P95 查询可能要拉几十万行数据到内存，而 PostgreSQL 只返回一个数字。

3、写入锁竞争

// dbcore.go:386-402

// SQLite 同一时刻只允许一个写者；限制连接数可避免连接池层面的写写竞争。

// 负载历史每分钟会执行包含读和写的事务，若连接池允许多个连接，容易与

// ping 结果等短写入撞锁并导致整批负载记录回滚。

sqlDB.SetMaxOpenConns(1)



    

  

多个 agent 同时上报数据时，SQLite 下它们只能串行写入。busy_timeout=5000(5秒) 是一个缓冲区，但高频写入下仍可能触发 SQLITE_BUSY。

4、Compaction 阻塞写入

// dialect_rollup.go:59

func (sqliteDialect) compactTxOptions() *sql.TxOptions { return nil }



    

  

SQLite compaction 事务使用默认隔离级别，由于只有单连接，compaction 期间所有 metric 写入都被阻塞。

而 PostgreSQL 用 SERIALIZABLE 隔离级别 + 重试机制：

// dialect_rollup.go:81-83

func (postgresDialect) compactTxOptions() *sql.TxOptions {

    return &sql.TxOptions{Isolation: sql.LevelSerializable}

}



    

  

写入不会被阻塞，只在真正冲突时才触发重试。

SQLite 的优化措施（源码中做了什么来缓解）

Komari 对 SQLite 做了大量优化，说明开发者清楚其局限：

这些优化让 SQLite 在中小规模下表现可接受，但不能改变其单写者架构本质。

PostgreSQL 在 Metric 场景下的具体优势

PostgreSQL 显著优于 SQLite 的核心原因：

1. 
   

   聚合查询性能可能差 10-100 倍：当查询涉及百分位或标准差时，SQLite 必须把所有原始点拉到应用层内存计算，而 PostgreSQL 只需要一个 SQL 查询。这是源码中最明确的性能分水岭 (dialect.go:399-444)。

   
   


2. 
   

   高并发写入不会互相阻塞：SQLite 的 MaxOpenConns=1 在 agent 数量增长时会成为瓶颈。

   
   


3. 
   

   Compaction 不阻塞写入：SQLite 的 compaction 事务（清理过期数据+构建 rollup）会占用唯一的写连接，期间新数据无法写入。

   
   

一句话总结：对于小规模部署，Komari 对 SQLite 的优化已经足够好；但当 agent 数量和查询复杂度增长时，PostgreSQL 的 SQL 聚合下推能力（尤其是百分位查询）和真正的并发写入支持，使其在 metric 场景下确实比 SQLite 好很多——这个差异是架构性的，不是微调参数能弥补的