@laminux29 大佬说的是，问题描述确实有些矛盾，其实也是想请教一下在这个场景下，大家会用的一些低成本高收益的方案。

@xautll 似乎 clickhouse 适合于离线分析 ，不适合高并发下 kv 查询。

@btnokami 目前是集群 回头试试 key 分片。

@ppyybb 感谢，目前用的就是 ssdb 集群。

@vus520
感谢，pika 其实挺好的，但是到 v3 后已经去掉 double master 支持了，
要自行引入 codis，不然还得带 docker，运维成本并不低
之前用 pika 当文件存储服务，存了 1.5T 文件后，
访问量不高，但 I/O 直接吃满，性能上不去，就不敢用了...

@fuis
感谢，TIDB 门槛有点高，个人开发者吃不消.

无脑推 上古卷轴

@muxiaoke 甭试了 这家国人开的 网络去年硬盘挂了给补偿 2 月，以为会好点…结果依旧常年炸的不要不要的 这个故事告诉我们不要贪小便宜 早点申请退款洗洗睡吧 #来自年付当扔了的用户

@uer 老哥这个细腻到点了，小弟真心受用！之前确实钢铁直男去考虑问题…我好好再去屡屡。再次感谢老哥点拨 🙏

最后回复一下：

1. 南方（至少我们这）提车都会挑日子（习俗），虽然我也不太信这个，但是只有长辈懂，所以征求长辈的意见。这和妈宝扯不上半毛钱关系哈。

2. 征求亲妈意见是老婆先提出来的，我觉得这也是老婆对婆婆的尊重，并没有什么不妥。

各位意见我都虚心学习和借鉴，帖子到此打住，感谢各位的关心。

感谢楼上楼下的 v 友的建议。

统一回复一下：

1. 亲妈的说闲话的顾忌还是怕被亲戚借钱、借车之类的关系不好处理，这点在人情事故确实上很难处理，我也明白。因为工作原因，确实和家人沟通得比较少，下单前没和家人讨论也确实不应该。回头好好沟通一下。

2. 个人的经历不具参考性，比较难复制就不在这里给大家乱带路了，一个人从产品+设计+运营坚持一个项目十几年，之前一直负支出，这几年开始尝试变现。要总结就是：坚持自己的兴趣和信仰，现实一定不会亏待你的。

3. 关于 50w 的代步车在这边确实有些过。但是我和老婆都很喜欢那款车，其他各种其实都有试过很多，一是自己已经有七座 suv 了主要考虑轿车，二是想后续 8-10 年不用换车了，干脆一步到位。

综合以上，目前还是非常确定要坚持买。

真没人在 ns 上玩「上古卷轴·天际」？我龙裔不佛！

有个东西叫索引表

json 别编码试试：json_encode($data,320)

试试 Xavier
https://github.com/mdbs99/xavier

1. 关所有 log/binlog
2. batch insert
3. 多进 /线程
4. tmp 目录指 /dev/shm 目录
5. 上 ssd

插入速度取决于你的硬盘读写速度。
4e 问题不大

给个地址 让 v 友爬到你怀疑人生

电影检索核心其实还是降维的问题。

电影先降维到每一秒为截图，剔除掉相似度大的截图，存大盘鸡或 oss，然后转 simhash 之类的存检索库，求相似度应该能粗略解决一些需求。

假如一本电影 2 小时，截图 7200 张，滤重后假设 5000 张？算检索 100w 部电影最终也就降维到 50 亿张图片的 simhash 检索而已。

当然，图片特征识别应该是在检索降维中比较重要的一些细节等等，个人小团队要想做好这个引擎，应该有很长的路要走。

@AaronLiu00

🙏以及感谢各位，虽然和我想的差一点

不过已经按思路手撸了一个前后端版本，准备小范围实践下

之前已经有前人开源过图片生成

https://github.com/jklmnn/imagejs/

按说明处理过后，发现 chrome 安全检查已经屏蔽非 javascript header 执行 js 了，so 只能放弃…

P.S. 图片加 php / asp 代码早已经是皆知的事情了哈，那个不存在绕过文件头的问题，和我这个还不太一样

P.S. 图片压缩部分，我确认了一下，浏览器上 png 压缩率不是很高，一般图床也不会对 png 做特别处理，只要 png 数据不是特别多的情况下，效果应该还能接受，不过也要全面测试