程序日志，日均 300-500 条，不定期（约每周两次）会爆发到 1500 条。需要做到日志持久化，持续时间至少一年，也就是约 15 万条。（不用 txt/log 是因为有时候需要进行统计、计算等）
现在举棋不定，用 LevelDB 可以直接套娃，但是最后统计和计算的时候，还是会苦了自己；用 SQLite 要重写很多东西，但是会方便后期使用。觉得两个都好，两个都想要，可是成年人知道，两个都要，身体受不了。
 |
1
lsk569937453 Aug 16, 2023
SqLite 是运行在客户端的轻量数据库，并没有指明是存储日志的。所以你的程序是跑在客户端的吗？
如果程序是跑在服务器上的，1 年就存十几万条日志，那可以有很多方案啊，mysql/mongodb/postgreSQL 。 |
 |
2
cmos OP @lsk569937453 1# 跑在服务器上的，所以我才觉得这个场景应该是用 SQLite 而不是 LevelDB
|
 |
3
F281M6Dh8DXpD1g2 Aug 16, 2023
才 15 万条，写 txt awk 计算完事
|
 |
5
slowman Aug 16, 2023
原始日志写 kafka, 后期爱怎么处理怎么处理
|
 |
6
bctdg Aug 16, 2023
统计计算具体是什么类型呀？ leveldb 太底层了，不太建议。Prometheus 怎么说，后续接计算或报警都很方便
|
 |
8
815979670 Aug 16, 2023  1
感觉 sqlite 合适一些，公司有类似的日志需求，使用 sqlite 存储，因为是批量写入，并且只有管理端查询，目前没有遇到性能上的问题。
我们的用法是一个月一个 sqlite 文件，单文件数据量 在一千万到两千万左右，文件体积大概 1.2 到 1.5 G 的样子。 使用体验还是不错的，查询层面，标准的 sql 语句都可以直接用，没有学习成本。如果出了问题 需要进一步分析，直接把 sqlite.db 文件 下载到本地，随便一个数据库客户端都能进行管理操作。 注意：我上面提到的只是我们项目上的使用体验，没有考虑到 op 的技术栈迁移成本，仅供参考。 |
 |
9
8355 Aug 16, 2023
300-500 条。。。。
txt 到底那里不好了，vim 一次打不开吗 |
|
10
8355 Aug 16, 2023
cat 一屏上下滚动都够看的了。。
|
 |
11
patrickyoung Aug 16, 2023 via iPhone
Clickhouse
|
 |
12
Itoktsnhc Aug 16, 2023
随便找个常见的文件格式存一下 然后用 clickhouse-local, duckdb 这类工具做统计分析就行，
|
|
13
cmos OP @815979670 8# 我感觉 SQLite 应该是综合成本最低的，LevelDB 迁移到 SQLite 问题不大，操作也是 SQL 的那套标准，上手比较快。就是得倒腾旧数据到新平台上。
|
 |
14
AutumnVerse Aug 16, 2023 via Android
日均 300-500 条，txt 难道不是最优解吗。拿 sqlite ，leveldb 存日志，你不怕被同事喷死？
txt 存日志，每天一个新文件，查询的时候 cat/tail +grep+awk 就完事了。 |
 |
15
icyalala Aug 16, 2023
txt 就够了
但是为什么有人会觉得 sqlite 只是给客户端用的呢 |
|
16
ktqFDx9m2Bvfq3y4 Aug 16, 2023 via iPhone
有很多日志中间件支持查询。
|
 |
17
IDAEngine Aug 16, 2023
Sqlite 现在都可以分布式存储，扩容比较简单，直接 Sqlite 不很好
|
|
18
815979670 Aug 16, 2023 via Android
@imes 如果感觉迁移成本不大的话，选 sqlite 是个不错的选择，楼里好多人说文本文件写日志更合适，可能是日志仅面向于开发吧，我们需要显示在管理后台里，用 sqlite 查询更方便。
性能方面，如果实时性要求不高，可以把日志写入缓冲区，然后一次性落盘，性能客观。 我写过一篇博文，可以提供参考： https://www.dbkuaizi.com/archives/154.html |
 |
19
julyclyde Aug 17, 2023
我可以理解“总有需要表哥化、关系化查找的时候”但是为什么就“应该上 sqlite”了呢？
这俩好像缺乏因果关系啊 |
Select Language