深夜说一个最近的感想 其实也不算新，还是老生常谈的一个话题“做 infra 的人必须要去贴近业务，否则一切都是空中楼阁” 我介绍过很多次鄙司是 AIGC 头部玩家，主攻二次元赛道。 我们最近面临的一个问题是 Elasticsearch 带来的。 我们用户公开发布的 Artwork 和生成任务都是可以搜索的。 最近 Elasticsearch 频繁会出现部分 Data Node 被打满然后连锁搜索出现问题的情况。 那么我们需要去怎么样快速的解这个问题？ 在进一步讨论之前我们需要思考在这个场景下，搜索这个操作的本质是什么？ 我的看法是资产管理。在 AIGC 场景下，Prompt 毫无疑问是用户的核心资产，而对应的 Task 以及 Artwork 某种意义上算是资产的预览（or 属性） 那么有了这样一个推论后，我们便能清晰的知道，至少在目前的形态下，业务核心属性必然不能为了技术结果让步。 同时我们又有一个观察，我们用户公开发布的 Artwork 其的可见性和 Task 是不太一样的，Artwork 可公开检索，也会承担 SEO 的责任，而 Task 实际上仅用户可见。那么换句话讲，两者的数据的访问频率，资源需求都是不太一样的。 换句话说，我们对 ES 的 Index 存在了多租的需求。但是很遗憾，按照目前的 ES 的设计，是不具备多租的能力的。 虽然长远来说，优化查询会是一个必然的选项，但是在当下面对超高速发展的业务，拆分 Index 为不同的集群，按照 Index 不同的属性给不同的算力/磁盘，快速试错会成为我们的首选。 目前这项工作正在进行中，效果未知，但是整个思考博弈的过程其实是我前几年会很少考虑的。很多时候技术的最优解未必是业务的最优解。 最后的最后，再打一个广告。鄙司招人，ML Engineer，ML Data/Full Stack/Backend/Marketing 等职位虚位以待。如果你想一起做一些有趣的事情，欢迎 DM，帮你老板直达