不看代码的话 知道 HashJoin 是 O1, 不是 m*n 性能屌爆就是了,缺点是 hashtable 空间不能太大

MergeJoin 也是常见的 join

各种 join 算法都不是很难实现的东西,mysql 这玩意只有一种算法是因为它没有统计数据去支持选哪种方式

没有银弹..有银弹大家还选个啥

跟不上 pg 自身更新节奏的都得死 2333

因为都会被 pg 干死....

还在 ulimit -n 呀

python 的线程是真线程
因为 gil 不能多核而已
python 多场线程与其他语言的多线程基本一样
是否加锁 具体粒度要看对应虚拟机源码

想看大型的就不要把关注点放在 web 框架上...

来来来 openstack 走起

没有目的读是很难读的

...不熟悉 python 还不装 ide... 你开心就好

搜索 location 优先级啊

=规则优先级最高


还满足不了你的话 上 openresty 咯

@inoizyz
就是就是 哈哈哈哈

话说...好像这些都是从 erlang 里出来的？

@richzhu

记这个不如好好把一个协程库的代码读透,比如 python 的 eventlet
读透了搞清楚模型模型了就自然理解了....啥语言都一个样,记下来真没用....

线程
一个线程跑满,就吃饱一个 cpu
N 个线程跑满对应 N 个 cpu,只要与 cpu 数量相同多线程就能吃饱 cpu
但是实际代码里会阻塞,一阻塞会自动让出 cpu, 所以在阻塞写法里,程序的线程超过 cpu 数量能提高性能
但是过多的线程数带来的上下文切换回拖慢整体


协程
通过寄存器保存代码片段,遇到阻塞（一般是 io,或者自定义的协程锁)，会切换到其他代码片段
所有代码片段的入口存放一个不停排序的队列
一个循环（相当于一个线程）不停的排序这个队列,并弹出最前面的数据获取到代码片段并执行
一般只有一个主线程,由于代码片段的切换由程序自己决定,没有系统级上下文切换,性能好,缺点是单线程


所以性能最好的方式是结合多线程与协程,但是非语言级很难用一个库来实现支持多线程的协程

目前除了 go, dart （也就是 google 的 flutter 所用语言）也有多线程协程支持


我瞎鸡巴说的...我没写过 go 哈哈哈哈哈哈

我用到 openstack 的 oovo
我想支持多个数据库（拆分日志库,业务数据库）
具体就不细说了


现在的是改造
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/db/api.py
的 event.listens_for 部分

因为他的代码里不需要支持多个数据库,所以_emit_on_pending 是个单独的

因为我有多个库, 所以需要通过不同的 declarative base （不同数据库的表继承不同的 declarative base ）反馈返回不同的_emit_on_pending

如果用 session 来区分,下面这种没 session 的监听就不好处理
@event.listens_for(model_base.BASEV2, "attribute_instrument", propagate=True)

所以我需要 db object 里获取到对应的 declarative base,但是不是很想通过 mro

好像用 obj.__class__.metadata is not BASEV2.metadata: 这种方式也行

我想从一个 db object 的属性里找到他的 declarative base 对象
从而分辨这个 db object 是哪个数据库连接的

应该可用 obj.__class__.__mro__[1] is DBBASE 来确定这个 db object 的 declarative base
但是我不太想用 mro.....因为不是那么熟

搞不定 最后只能用 metadata 来判断

if obj.__class__.metadata is not DBBASE.metadata:
return

是进程肯定不干净

没有区别, posix_spawn 就是 fork+exec,以前没有 posix_spawn 系统调用而已

搞清楚了原理,自然知道如何避免 celery 有可能带来的负面影响

multiprocessing 本来就是就是单次脚本中让你快速多进程跑代码的库,自己里面生线程还有管道 /socket 通信,里面不说多复杂但进程肯定干净,混合到复杂代码里基础不牢问题都不知道出哪,本来就不适合用到服务中。
特别是 multiprocessing 进程池中可复用的进程除非你能确定进程不被污染,否则跑起来就是自己找坑。

所以我早说了, 对于不熟悉 linux 编程也不想读 multiprocessing 源码的同学, 稍微复杂一点的代码都不要使用 multiprocessing。

无论什么扩展,最后都是要 fork

搞清楚多进程知识以后, 是不是 celery 都没关系,知道什么时候退出,什么时候回收就是

哪有那么麻烦, 只要你处理好异常,os._exit 的时候我管你是 celery 还是 flask 还是 dj

你的快速方法明显是不对的

学习的时候遇到深度问题如果超过能力或者没有必要的确需要跳过,但是非常基础的问题习惯性跳过是不行的

多进程问题是非常基础也常用的知识,只要你用到多进程就会遇到相关问题,这次绕圈解决了下次一样有问题解决不了
老老实实把坑填了用的时间比这次绕圈解决长一点,但是你淌过去了以后就解决起其他多进程问题就有底了

python 残疾的多线程是必须多进程的,不搞懂以后坑的是自己