V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lolizeppelin  ›  全部回复第 26 页 / 共 53 页
回复总数  1056
1 ... 22  23  24  25  26  27  28  29  30  31 ... 53  
2019-09-03 21:14:09 +08:00
回复了 nullboy 创建的主题 Linux 群晖这种小内存真的能挂 PT?
这伤个屁

最伤的应该是流媒体,播放的时候写缓存数据,大量的写,电影越大生成的缓存文件也越大
这部分不用内存盘,嘿嘿,保障写入量大大滴
群晖我不清楚,反正 jellfin 是这样的,估计群晖的流媒体也好不到哪去
2019-09-03 21:08:07 +08:00
回复了 Breadykid 创建的主题 MySQL 刚才,领导对我的 sql 提出了建议
2 和 3 的核心问题是一样的


查询过程无外乎


数据库 应用层
从硬盘读取数据——数据库解析数据——复制到网路层 ~~~~~~~~ 网络层复制到应用程序——应用程序解析


数据库开销
硬盘读取开销~解析开销~复制 /传输开销


应用层开销
解析开销~传输开销

这些省不了的开销,无非是放在哪里而已

用数据库解析, 数据库 cpu 消耗大,但是传输开销小
应用解析,数据库 cpu 小,应用服务器 cpu 开销大,传输开销大
但是数据量大起来以后,传输开销自然就不能忽视了

如果 group by/join 前的数据远远大于处理后,思考两点
1.应用层来 group/join,数据库计算量的虽然降低,但是好处是否会被大量传输抵消?
2.一定量级上数据库层的 group/join 的否效率是否远远好于应用层?
3.上述一定量级是如何判断?
4.数据库层的 group/join 是否能降低硬盘 IO ?
5.应用层 group/join 事务问题怎么解决


-------------------------------------------------------------------------------------
1.其他数据库要用函数索引,也需要索引函数对象,例如 index(int(column))
2.mysql 不能多核并行查询,这个是死穴,当然少量数据肯定比你自己做强多了
3.mysql 没有 hash join 和 merge join 稍微大的数据 join 起来肯定要死翘翘,但是少量数据又有索引肯定比应用层做好得多.
至于到底多少数据量算大这个嘛............
4.分表是下策,mysql 的表分区也是个残疾...上策嘛....换数据库!!

所以说!!早点换 PG,压根就不纠结这些问题...真要纠结这些问题的时候,就是你换大数据的时候!!
PG 一统江湖!
你读一下 zipfile 的源码就知道了

根本原因在于 zip 设计本身,每一个文件需要写在这个文件的前分配空间写一段校验信息,文件越多校验的块也越多,zip 的性能自然就差
加上 python 本来计算就慢,这种方式更放大了 python 的缺陷

文件数量多非常不适合用 zip,非要用 zip 不如调系统的解压工具解压
2019-09-02 14:49:00 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
@zhiwoda123
还没出啊 刚在 CJ 上展出过而已,你自己搜索 Y9000x
2019-09-02 14:39:04 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
Y9000X,还没出,配显卡坞. 我不信外星人散热能罩得住 I9+2080
2019-09-02 14:36:37 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
不值,散热跟不上的把

买联想那个新出的 I9 不带显卡, 然后雷电 3 外接显卡盒。
不都是扩展坞接多显示器么,还直接用笔记本键盘啊?
2019-09-02 14:16:46 +08:00
回复了 lolizeppelin 创建的主题 Python 求一个编译号的 Python 包 yappi 要 python3.6 的
发现 https://anaconda.org/可以下载
orz 真是救了老命了
楼上真是搞笑, 虚拟化用傻了?
一台机虚拟出 10 台是算例翻倍了还是 IO 翻倍了

没钱没机器还上分布式,你当做实验啊?
直接物理机都不够用, 还套一层虚拟化?
思路都是找时序型数据库
PG 正好有时序插件, 比专门的时序数据库差一点,但是功能上是标准的 sql
时序的数据? 装 pg 的 timescaledb 插件啊

不用自己弄分区和 BRIN 索引了
2019-08-29 13:34:46 +08:00
回复了 hujianxin 创建的主题 程序员 常用 Python 写命令行工具的朋友,你最常用的库是什么?
请使用 python 最牛逼的配置文件兼命令行库 oslo.config

openstack 出品,用过以后你再也不需要用其他命令行 /配置文件库了
没有,目前可以作为微服务参考的 python 项目只有 openstack
2019-08-07 18:27:08 +08:00
回复了 cz5424 创建的主题 Python 如何维护 socket 链接池
顺便,tcp 层维持链接不一定靠谱,最好在应用层心跳,基本上常用的服务器都有用于心跳检测的 PING 协议包
2019-08-07 18:23:53 +08:00
回复了 cz5424 创建的主题 Python 如何维护 socket 链接池
简单可以看看 python redis 的实现

rabbitmq 心跳抄 openstack 的 oslo_messaging,的做法自己处理下就行了

基本上就是
写个优先级锁(避免心跳抢占具体执行),每个 connection 都记录上次使用时间和心跳包时间,用于判断是否发心跳 /是否长期不用

一个线程 /协程专门用于心跳发送,顺便回收长时间不使用的 connection
2019-08-06 11:25:34 +08:00
回复了 kayseen 创建的主题 Python Python 封装通过的 celery 服务
请使用 oslo.messaging
看样子像是 linux 随机不够?
如果是的话, 有个命令能刷新这玩意的
2019-08-05 19:20:57 +08:00
回复了 StarkWhite 创建的主题 程序员 都 9102 年了,大家有没有用上 Facebook 出的 GraphQL ?
好像 openstack 里 fileds 的用法...
2019-08-02 00:09:49 +08:00
回复了 opentrade 创建的主题 Linux centos8 等得好辛苦
系统是拿来用的 扯什么不符合 linux 没任何意义

到底是 init 来做还是 systemd 来做对 大部分用户来说根本没区别,盯着 systemd 的缺点不看看 systemd 带来多少便利?

渣渣 lsb 还能特别舒服?不要搞笑了好么!

我用 systemd 以前也觉得 lsb 好啊,用了 systemd 以后不是感觉真香,是以前都吃的 TM 什么屎
2019-08-02 00:05:21 +08:00
回复了 opentrade 创建的主题 Linux centos8 等得好辛苦
@iwtbauh

bug 可以修, 很多系统服务合并到 systemd 里是趋势,systemd 吃掉的大部分服务对普通用户没什么影响
1 ... 22  23  24  25  26  27  28  29  30  31 ... 53  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4522 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 04:03 · PVG 12:03 · LAX 20:03 · JFK 23:03
Developed with CodeLauncher
♥ Do have faith in what you're doing.