V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  RedisMasterNode  ›  全部回复第 16 页 / 共 29 页
回复总数  573
1 ... 12  13  14  15  16  17  18  19  20  21 ... 29  
2022-10-12 15:37:16 +08:00
回复了 RedisMasterNode 创建的主题 数据库 按秒进行分库分表是个好的选择吗?
@soupu626 没理解,早上和晚上分表都要 % 分表数量的呀

例如有 100 个表,第 1 秒的话,1 % 100 = 1 ,所以落在第一个表,第 101 秒 101 % 100 = 1 ,也落在第 1 个表。

这个具体怎么样会受到时间影响呢
@joesonw 可以 那这也是其中一个有用的 point
2022-10-12 14:30:21 +08:00
回复了 RedisMasterNode 创建的主题 数据库 按秒进行分库分表是个好的选择吗?
@seth19960929 是个合理的办法,但是这些东西不受业务研发管控,DBA 说不允许用,就是不允许了,只能自己想办法。
@minamike 这个 m2 造型的话确实视觉上来看是会厚一些,我感觉还是 M1 的设计符合我对薄的审美 hhh ,这个 0.41 很喜欢。然后我长期用 16 寸的 MBP ,这个厚重的设计已经腻了,薄一些的看起来更精致些。不过讨论审美是没有意义的,归根结底还是想看看 m2 有什么样更强的购买理由,看看有没有漏掉的一些提升点值得去考虑
2022-10-12 12:39:26 +08:00
回复了 RedisMasterNode 创建的主题 数据库 按秒进行分库分表是个好的选择吗?
@soupu626 这个已经不能改了,背景里应该补充一下是要把原来没分库分表的数据拆到分库分表里面。

而且按时间分的话为何会不均匀呢,因为每秒的请求量应该都是相对均匀的呀,你说的这个时间粒度听起来好像比较宽了,不是按秒的
@minamike 可能主要还是审美上的倾向吧,这个说法我之前也看过,但是就只是个人来说不喜欢 m2 厚重的外观
@linuslv 我感觉就算一样价格我也倾向 M1 ,M1 的外形纤细好多,薄呀,M2 太厚了,如果要接受 M2 的外形我可以买 Macbook Pro 。如果 Macbook Pro 有 M1 的外形我肯定买
@fds 谢谢链接,有用。

我仔细看了一些 difference 部分,下面这些是 M2 的差异:
- 13.6-inch Liquid Retina display (2560 by 1664 pixels) (没太大用)
- 500 nits brightness (用不上)
- Apple ‌M2‌ chip with up to 10-core GPU (不确定)
- ProRes encode and decode engine for hardware-accelerated ProRes and ProRes RAW video (用不上)
- 100GB/s memory bandwidth (可能编译或者修图有帮助?)
- 8GB, 16GB, and 24GB unified memory configurations (用不上,已经确认买 16G )
- 1080p ‌FaceTime‌ HD camera (好像不错)
- Four-speaker sound system (聊胜于无)
- 3.5mm headphone jack with advanced support for high-impedance headphones (用不上)
- 52.6-watt-hour lithium-polymer battery (没太大差别)
- 30W USB-C Power Adapter (with 8-core GPU model) or 35W Dual USB-C Port Compact Power Adapter (with 10-core GPU model)(没用)
- Supports fast charging with 67W USB-C Power Adapter (没用)
- Available in Starlight and Midnight (没用)

感觉还是 M1 适合我,升级的好处不算肉眼可见,便宜不便宜都好说,主要是值不值得,看起来对我来说应该是属于不值得的了。

PS 文章最后的总结也很好,推荐有需要的同学看看 hhh
2022-10-11 17:42:13 +08:00
回复了 richchang 创建的主题 宽带症候群 移动的宽带和电信比,究竟差距有多少?
@sickoo 咱广东好像上行只有 30M ,实用也够用,但是好像没办法付费提上行😭
实测自己打游戏的时候也没多少延迟,深圳电信打 LOL 延迟一般都在 20ms 以内(艾欧尼亚,服务器离得近);去年换成了移动,延迟一般都 50ms 以内,其实不在乎这点差距,也很稳定。
2022-10-11 17:39:41 +08:00
回复了 richchang 创建的主题 宽带症候群 移动的宽带和电信比,究竟差距有多少?
@superchijinpeng 国庆去苏州旅游看到移动有 3000M 还是 5000M 的宽带,属实?😂感觉好爽
2022-09-21 09:43:39 +08:00
回复了 RedisMasterNode 创建的主题 问与答 工作中的项目,业务重写并开源合法吗?
@isno @binux @greatbody @gps949 @FYFX
好嘞好嘞谢谢解答
2022-09-07 23:42:00 +08:00
回复了 flyer103 创建的主题 酷工作 [字节跳动-火山引擎][上海/杭州/成都] 容器服务团队社招
礼貌问下这样的岗位欢迎没真正做过 K8s 的同学试试吗?写了几年 Go ,但是没 K8s 经验,社招里面实话实说换个方向没那么容易 :P
2022-08-07 16:46:13 +08:00
回复了 gowk 创建的主题 Go 编程语言 用 Go 写 Web 后端合适吗?
@lizuoqiang 不可能,基本都是需要一套脚手架+代码生成工具+ bla bla bla ,纯 CRUD 自己要做的事情可少了。可能不比成熟的语言快,例如 php 、python 、java ,但是开发效率肯定不慢....
2022-08-02 08:49:15 +08:00
回复了 ClownFish 创建的主题 程序员 Go 微服务开发框架 DMicro 的设计思路
挑个小毛病图一 EventBug
@111111111111 输入是原始 SQL 文本,输出是改写后 SQL 文本,我们设想的是经过 parser 解析之后改写的这个中间件,不是 Django ORM 这类上层应用。不管上层是什么应用,Django ORM 也好,SQLAlchemy 也好,它看到的应该都是原始的 SQL ,也就是不察觉到分表的存在,真正执行的是被中间件层改写过的 SQL 。

所以主楼的问题是,这样的中间件有没有现成的,对不同语法覆盖比较全面的(也就是非玩具的意思)
1 ... 12  13  14  15  16  17  18  19  20  21 ... 29  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2887 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 32ms · UTC 12:33 · PVG 20:33 · LAX 05:33 · JFK 08:33
Developed with CodeLauncher
♥ Do have faith in what you're doing.