日志场景： LevelDB 和 SQLite 哪个更合适？

[imes]

程序日志，日均 300-500 条，不定期（约每周两次）会爆发到 1500 条。需要做到日志持久化，持续时间至少一年，也就是约 15 万条。（不用 txt/log 是因为有时候需要进行统计、计算等）

• 默认采用 LevelDB ，毕竟是查少写多的场景，再加上长久依赖和习惯，旧项目一直没改动，延续了下来。
• 最近开新项目，我一想，存日志不应该上 SQLite 吗？总有需要表格化、关系化查找的时候。用 SQLite 直接读数据库就好了，用 LevelDB 外面还得再套一层。

现在举棋不定，用 LevelDB 可以直接套娃，但是最后统计和计算的时候，还是会苦了自己；用 SQLite 要重写很多东西，但是会方便后期使用。觉得两个都好，两个都想要，可是成年人知道，两个都要，身体受不了。

[lsk569937453]

SqLite 是运行在客户端的轻量数据库，并没有指明是存储日志的。所以你的程序是跑在客户端的吗？

如果程序是跑在服务器上的，1 年就存十几万条日志，那可以有很多方案啊，mysql/mongodb/postgreSQL 。

[imes]

@lsk569937453 1# 跑在服务器上的，所以我才觉得这个场景应该是用 SQLite 而不是 LevelDB

[liprais]

才 15 万条，写 txt awk 计算完事

[cat]

@imes 跑在服务器上的 为什么会觉得应该用 SQLite …

[1423]

原始日志写 kafka, 后期爱怎么处理怎么处理

[bctdg]

统计计算具体是什么类型呀？ leveldb 太底层了，不太建议。Prometheus 怎么说，后续接计算或报警都很方便

[imes]

@cat 4#
@bctdg 6#
有自增 ID 、用户身份、运行时间、触发事务，以及返回的数据，反正杂七杂八一大堆，所以下意识觉得应该搞个数据库来储存。

[815979670]

感觉 sqlite 合适一些，公司有类似的日志需求，使用 sqlite 存储，因为是批量写入，并且只有管理端查询，目前没有遇到性能上的问题。

我们的用法是一个月一个 sqlite 文件，单文件数据量 在一千万到两千万左右，文件体积大概 1.2 到 1.5 G 的样子。

使用体验还是不错的，查询层面，标准的 sql 语句都可以直接用，没有学习成本。如果出了问题 需要进一步分析，直接把 sqlite.db 文件 下载到本地，随便一个数据库客户端都能进行管理操作。

注意：我上面提到的只是我们项目上的使用体验，没有考虑到 op 的技术栈迁移成本，仅供参考。

[8355]

300-500 条。。。。
txt 到底那里不好了，vim 一次打不开吗

[8355]

cat 一屏上下滚动都够看的了。。

[patrickyoung]

Clickhouse

[Itoktsnhc]

随便找个常见的文件格式存一下 然后用 clickhouse-local, duckdb 这类工具做统计分析就行，

[imes]

@815979670 8# 我感觉 SQLite 应该是综合成本最低的，LevelDB 迁移到 SQLite 问题不大，操作也是 SQL 的那套标准，上手比较快。就是得倒腾旧数据到新平台上。

[jiangwei2222]

日均 300-500 条，txt 难道不是最优解吗。拿 sqlite ，leveldb 存日志，你不怕被同事喷死？

txt 存日志，每天一个新文件，查询的时候 cat/tail +grep+awk 就完事了。

[icyalala]

txt 就够了
但是为什么有人会觉得 sqlite 只是给客户端用的呢

[Chad0000]

有很多日志中间件支持查询。

[IDAEngine]

Sqlite 现在都可以分布式存储，扩容比较简单，直接 Sqlite 不很好

[815979670]

@imes 如果感觉迁移成本不大的话，选 sqlite 是个不错的选择，楼里好多人说文本文件写日志更合适，可能是日志仅面向于开发吧，我们需要显示在管理后台里，用 sqlite 查询更方便。

性能方面，如果实时性要求不高，可以把日志写入缓冲区，然后一次性落盘，性能客观。

我写过一篇博文，可以提供参考： https://www.dbkuaizi.com/archives/154.html

[julyclyde]

我可以理解“总有需要表哥化、关系化查找的时候”但是为什么就“应该上 sqlite”了呢？
这俩好像缺乏因果关系啊