V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  stgmsa  ›  全部回复第 1 页 / 共 2 页
回复总数  21
1  2  
前两天国际漫游的时候 出口就是这个…… 能上 google 不能看 youtube 视频……
2022-02-08 13:32:14 +08:00
回复了 usingkk 创建的主题 问与答 程序员该 run 去新加坡吗
@usingkk 目前人在加麻大,华人公司也很卷,西人公司能好点。赚的不如坡县。 物价不便宜,房子更贵,来的办法基本上就是上学,或者配偶工签,或者 LMIA(钱💰)
我觉得有点虚…… status lite 一直后台活动……100%

我是美区账号……
虽然没做 infra,但做 基础服务。
真的是天天客服啊。。。文档是有的,代码示例是有的。。
有的业务对接是真的顺利 ( 30 分钟 人家就说 搞定了谢谢)
有的业务是真的 文明用语 啊。。。( 3 天了最后还得让他把代码给我 调通改完了发回去)。。。
@hankai17 apache 那个缓存么? 没用过 ……
另外 也不是推荐跟我们一样 用 cassandra 。
ceph glusterfs 普通的 fs,seaweed 的实现方案产品, 甚至 mongo,mysql 分个库 分个表
都能实现你的需求。
主要是 …… 这些东西 哪个你们最熟 出问题了能玩的转
@yuyuko 上面提到的 ceph glusterfs,mongo,hdfs hbase 公司各个业务线都有使用的场景。
但是…… 不建议从 0 开始就上。

举个例子,openstack 的虚机数据 和 io 都落在了 ceph 集群上,ceph 吃的裸盘,裸盘上面有 cache tier (好像也是 600G 的 dcs3500 3510 sata ssd,没办法,公司买了太多 消化不完),曾经出现过很多次 因为集群里 某块盘挂了 导致 整个虚拟机集群 io hang 住的情况(基础运维能力太渣的话,技术方案再怎么牛逼也不好用)

mongo 早些年间(大概是 2015 年?)出现过业务写的太疯狂 导致一个 mongo 吃掉了一整台物理机的资源 影响其他用户的(现在这种情况应该是没有了)

如果你们的支撑团队牛逼,我想他们会给你一个合理的方案的(比如你们的基础运维团队,在了解到你想用 fs 来搞的时候 会告诉你 XFS 还是 ext4,inode 要不要搞小一点,是走 lvm 还是直接干 ),你的 dba 团队也会根据你的 场景来告诉你 是走 hdfs 还是 走 mongo 就能搞定,还是吃个螃蟹,memorykey + optane 的解决方案。

多问问他们,他们可能是你这个系统后续 要持续打交道的人。。(他们也不想半夜接到你电话爬起来开电脑不是)
@yuyuko 上面提到的 key 信息入 ES 就是为迁移数据做准备的。
另外作为公共服务,优化存储成本是比较坑爹的事情,业务不像你想的那么配合 那么好推动(当然存储成本甩到业务线这个事就能好办很多)

前端机我接手之前是 160 台,通过替换缓存+k8s 署了一部分 pod 来抗量,干到 40 台 。
然而存储一般不会轻易去优化。一来周期会很长,二来沟通人力成本很高。一般存储上架就是一步到位顶 3 年的量的。

不过从运维角度来讲,如果你采用了不合规的硬件(也包括软件,网络 blablabla ),导致业务受影响了。这个锅可不是一般人能背得起的。轻则开除,重一点 你的直属领导 甚至总监级一起背锅滚蛋。
不让你赔偿损失就不错了(参考下广告展示多少图,你图床高峰期宕机 1 个小时试试?)

之前就有同事因为这个被开过(他还没过试用期呢)。优化成本固然没有错。我也是资瓷的。但是一定不要无底线的优化 (你需要清楚的知道自己到底在做什么,而不是一味地追求好数据 好绩效 而玩火)
@yuyuko 什么 ? SMR ? 你确定 ? 打算用消费级的硬盘吗 ?
是你 还是 你们运维 和采购 拍 奶子做的决定?
不管是谁只要出问题不是你背锅就行。

如果在国内公司写代码,连硬盘选型采购 都要一个程序员推动的话,还是劝尽早解脱(如果你在 Facebook 这种公司做 SWE,当我没说)。
我们现在有成本优化方案。不过是通过不断迁移在用数据,淘汰老数据下架来完成的。目前就在做。

不过说实话,千万级别的图片
100000000(按 1E 算) * 100 ( 100k 一张) / 1000 (到这是 MB ) / 1000 (到这是 GB ) / 1000 (到这是 TB ) = 10 TB...

存储大概就是 2-4 台 1U 的小机机 ?
@yuyuko 没有,meta 和 blob 一起存的。如果一定要问有优化么?那就是 后来上传的图片 key 和 meta 都在 ES 里存了一份。
规模
存储 22* 8T * 400 台 * 2 机房
前端机 40 台 E5-2630v2 +128G,(其实从负载看 20 台就足够了)
缓存 4 * DC S3510 600 G * 12 台
负责千亿级图床源站的路过,每天源站流量大约 30 亿图片请求。存储是 cassandra,前面挡了一层 12TB 的 nginx file cache 。
但其实 hbase,甚至文件系统 都可以。
你要求的量级,可选更是多。

主要还是要看你有多大访问量(性能),存多久(存储扩展),有没有运维需求和 sla 要求(数据和服务可靠性)。
2020-03-26 18:53:06 +08:00
回复了 kenvix 创建的主题 宽带症候群 github.io 大规模中间人?
山东电信 山东联通均中招。
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2940 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 27ms · UTC 14:12 · PVG 22:12 · LAX 07:12 · JFK 10:12
Developed with CodeLauncher
♥ Do have faith in what you're doing.