@
wxf666 sqlite 这属于单节点玩具 db ,对于并发性 web 服务,是跟不上用的。
并发访问,就成了两种情况,1. 串行排队,2. 程序内实现类似于 db 的 buffer cache
至于 duckdb ,这东西底层是列结构存储,读取需要解压,不适合并发访问,也不适合频繁写入。
duckdb ,和 sqlite 一样也是进程级,对于并发性 web 服务,也是一样的毛病。
#39 做的成本估算,有些细节可以调整。
OSS 和服务器的流量成本均应采纳 CDN 价格,不过按经验上看,CDN 回源也要再算,比较麻烦,流量成本占比低时没啥必要。
最优方案还是 OSS + CDN 存放 zstd 压缩后的文件。zstd 压缩使用小样本预训练词典,词典随客户端下发。
至于传输,zstd 压缩后,不要再计算 gzip 之类的量。
还有,算流量别算那么精确,oss 对于小文件有对齐,2kb 塞进去也会按 4k 计算(标准存储),而且访问 OSS 是 http 协议,头部塞了一大堆东西,几 kb 的文件算不准的。
至于整本存储,lzma 依然不是优化方案,还是首选 zstd ,新代的压缩算法几乎是全方面碾压老代。
这东西参数很多,把 level 开高压缩比不错,解压速度也可以。
当然,若是私有云自建,这方面有个优秀的方案,HBase + HDFS 。
#77 提到,sqlite 100g 1.3 亿数据,1w 随机写事务,这种测试没用,这数值是 WAL 的数值,而且是无事务写。
顺便再补个,我们做大规模爬虫类任务,是 crawl 爬后存文件丢进 DFS ,再有独立中间件提取再入库。至于入什么库就看情况了,多数是 kafka 。
再有服务消费 kafka 进行分拣、清洗、预先处理,按业务分类入业务库。
所以,什么并发写之类的都不存在。
#77 还有一个,支持多少并发写,占用资源问题。
对于 db ,mysql 也好 pg 也好,并发写并不是大批量导入的最优解,大规模数据导入是靠 batch ,而不是并行。
以我们的经验,mysql 导入 100w 行,字段 50 ,行均大小 5k 左右,单并发写速到 1w/s 不难。
至于题主,大概率是个新入行没做过项目的年轻人,脑子里想的都是不切实际的笑话,甚至还想搞 redis 缓存,也不知道缓给谁看的