24-04-16 杂谈 安逸的日子还能做多久以及什么才是最好的存储方案

微信的文章推送方式改了，更多是走流量机制，没法像以前一样恰保底推送流量了。得多多思考起一个有意思的标题

大家好啊，这里是空桑。有段时间没有正经更新公众号内容了，这里也做一个阶段性的总结吧

目前有诸多头疼的事情，也是比较的头疼吧

首先是目前工作有些变动，目前公司成立了一个 AI 的部门，估计是要承接传统的视觉模型，然后蹭一下 AI 大模型的热度。但是领导也不看好这个方向，老实说和国际一流、国内一流比起来也没有优势，纯粹吹比玩意。当然这个也和我这种小兵没有什么关系，我更多的是作为一个从后端对内服务的转到前端对外服务，关注更多的是蹭热点、将项目经历转化为自己的履历

从一个工作压力小，而且氛围不错、认识的人也多的环境转换到工作强度更大（其实也还好，毕竟是国企）、整体更加混乱的新环境去，也让我一时之间很难以接受。但是这也就是一个简单的内部转岗，不想做了过一两年跑路到其他环境也比较抢手，在后端这种安逸的环境待久了我发现过了三年感觉甚至没什么进步

很难说这个决策是好是坏，在后端的人脉还可以，一辈子这么按部就班的走下去，也差不多能混上一个部门的小经理、管个十来人，或者是我更乐意当的资深技术专家。有时我总是在想，人生走过三分之一了，一直是随波逐流的放荡下去，这么做下去也没什么意思。不如趁着目前试错成本比较低，去尝试更多的机会

好了，还是不谈这些阴暗而没意思的东西了。来讲点更实际的吧，最近都折腾了那些新玩意，开发了什么

老实说查询程序目前开发的进度还是比较缓慢的，整一个新技术环境的搭建拉出一根简单的线，而是把一团乱麻给编织成刺绣

由于目前家庭内部服务器还是在逐步的更新，希望能打通家庭内部多台服务器，国内的公有云服务器以及其他备用杂项服务器的网络和能力调用，避免出现需要在多点部署多个服务并且暴露关键指标和系统给公网的问题。同样的，由于不再是对现有技术的小修小补，那么很多技术栈的重新考虑又成了问题

答应朋友的查询程序调用资源的定期更新：这个由两方面组成，一方面是小程序依赖的诸如奖章、武器分类等数据可以从手动更新改为自动更新。另一方面是原本定期更新的 R 星新闻和预定要对接 tunable 是不是也能搞起来呢

但是定期更新能力是由内网的代码和 CICD 服务器 Gitea 提供的。Gitea 的定期部署能力和维护又依赖于内部的组网方案和定期更新方案，内部又存在生成的这些数据文件该抽象分离和归档到那些仓库，如何部署的问题

组网虽然部署起来困难，但是相对好解决，无非就是划分几个专用的子网区域再组成虚拟专用网。但是 Gitea 和内网的查询服务能力的可用性又受限于自己依赖生成的 CICD 镜像和内网更新镜像带来的网络不可用问题，解决起来非常的紊乱。然后内网更新镜像又得根据依赖关系和重要程序来决定是否自动更新，总不能重要的数据库服务天天更新

可能还是需要按照基础能力的构建、复用的基础功能的梳理和具体应用容器的选取来把平台构建好。但是这又不知道得搞到猴年马月去了

然后还有个比较重要的问题，那就是查询数据到底存到哪里。我希望内网的数据库能够统一技术方案，同类型的数据库选一种就够了。目前的查询程序 500W 条数据（大头是 250W）是把网页打包压缩后塞到了 mysql 里，单表占用 60G 的同时还卡的一笔

这样子就必须租用腾讯云 4C8G 然后 180G SSD 盘的云服务器，还有差不多一年就到期了，当时的购买价格是 3000 元，续费价格会更高！我的期望是当实际数据量达到 1000W 级别的时候能够塞到不同的 2C4G 50G SSD 盘的云服务器中，不然维持费用太高了

这就需要选择一个合适的技术方案了，现有的mysql肯定是没有前途了。那么是把mysql换成列压缩引擎（相同的网页列压缩的效率高得多）或者是兼容的TiDB、TDSQL呢？还是元数据还是存到mysql，但是网页数据丢进Mongodb/Minio这样的其他类型的后端存储？又或者是使用风头正劲号称能处理一切的PostgreSQL呢？在我的一些高压场景（数亿条推送消息和3KW级别查询结果）下谁的表现比较好呢？这又是个问题

时间！时间！总是让人感觉不够，但是每天回家总是提不起劲，这种感觉犹如深陷泥潭又难以言说。但千里之行始于足下，最近看到一句话觉得绝妙，为者常成，行者常至