V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐学习书目
Learn Python the Hard Way
Python Sites
PyPI - Python Package Index
http://diveintopython.org/toc/index.html
Pocoo
值得关注的项目
PyPy
Celery
Jinja2
Read the Docs
gevent
pyenv
virtualenv
Stackless Python
Beautiful Soup
结巴中文分词
Green Unicorn
Sentry
Shovel
Pyflakes
pytest
Python 编程
pep8 Checker
Styles
PEP 8
Google Python Style Guide
Code Style from The Hitchhiker's Guide
jinxueliu
V2EX  ›  Python

Python 使用原生 SQL 或者 SQLAlchemy, 查询效率上差别大吗? SQLAlchemy 的优势?

  •  
  •   jinxueliu · 2016-06-16 09:44:14 +08:00 · 11869 次点击
    这是一个创建于 3084 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  2016-06-16 16:57:05 +08:00
    假设有一台数据库服务器, 然后我有几台分布式的计算服务器,
    计算服务器需要从数据库服务器上查询大量的数据,然后再进行本地计算

    现在我有几个问题
    1 如何加速查询时间
    2 如何加速网络传输时间(计算服务器和数据库服务器不在一个网段)
    3 第 2 个问题是否可以通过在计算服务器建立备库来解决(变成本地查询)
    19 条回复    2016-06-17 23:25:38 +08:00
    est
        1
    est  
       2016-06-16 09:55:08 +08:00
    就是手机贴膜和不贴膜的区别。

    效率还是看你的姿势水平是否高。
    jjx
        2
    jjx  
       2016-06-16 09:55:24 +08:00   ❤️ 4
    sqlalchemy 有两个层级 orm 和 sql expression, 使用 sql expression 同原生 sql 差距不大, orm 由于需要介入 session 管理, 差距随数据量增加而增大

    sqlalchemy 优势一是 orm 的优势, 这不用说, 其次是 sql expression 能让你用 python 的方式去思考, 写 sql, 从而写出易于维护的查询, 比方说原先几百行上千行的 sql , 如果用原生 sql 肯定是难以维护(基本上我们这些所谓企业软件从业者, 对这类 sql 基本都是不想再看第二遍), 但用 sql expression 方式去写, 这感觉, 你得自己去体会, sql expression 基本上能达成所有原生 sql 的所有功能(其他的 orm 一般都会有不支持某有原生 sql 语句或函数)
    bobuick
        3
    bobuick  
       2016-06-16 10:42:46 +08:00
    写简单的, sqlalchemy 不一定比你手写效率好。
    写大量的, 复杂的。 也不一定比你手写效率好(基于你已经非常了解各种联合查询, sql 优化)。 但是大量的情况下, sqlalchemy 至少会保证比较稳定的效率, 可能某一句有些优化空间, 需要人为跟着 debug 。
    相反的,大量的情况下,人类去干, 就非常没保障了, 先不说不同的人水平不同,即时同一个人,也不稳定
    seki
        4
    seki  
       2016-06-16 10:47:20 +08:00
    如果是根据用户输入拼接的 sql 也有可能被注入攻击
    mathgl
        5
    mathgl  
       2016-06-16 10:53:45 +08:00
    @jjx sqlalchemy 和 twisted 感觉一起用有些问题。
    clino
        6
    clino  
       2016-06-16 10:55:18 +08:00
    我记得用 sqlalchemy 不拼 sql 语句的姿势可以防 sql 注入的
    lixiaohan
        7
    lixiaohan  
       2016-06-16 11:02:03 +08:00   ❤️ 1
    跟一楼想法差不多, 效率高低看你水平高低, 其实你打印一下 sqlalchemy , 也是执行 sql, 优势是显而易见的, 你觉得代码里面写很多 sql 好 还是 写 orm 好呢? 哪个好维护? 你愿意写哪个? 但是用 orm 的前提是你的 sql 要足够好
    jjx
        8
    jjx  
       2016-06-16 11:55:41 +08:00
    @mathgl

    sqlalchemy 放入另外一个工作进程, 然后用 txzmq 之类的去请求就行

    sqlalchemy +postgresql +gevent 搭配的很好
    mathgl
        9
    mathgl  
       2016-06-16 13:20:16 +08:00
    @jjx 这种用法几年前就有人提过,我还以为现在有更直接的办法了。
    zhuangzhuang1988
        10
    zhuangzhuang1988  
       2016-06-16 13:21:08 +08:00
    wmttom
        11
    wmttom  
       2016-06-16 13:36:43 +08:00   ❤️ 1
    即使拥有手写高效率 SQL 能力,也推荐用 sqlalchemy 的 core ,只用连接池和 SQL 的组装,不会损失多少性能。
    并且 SQL 组装变为 Python 函数之后,可以更好的分层分装,抽象复用。
    从维护的角度讲,一份代码中最好不要出现多种 DSL 。
    nimdanoob
        12
    nimdanoob  
       2016-06-16 15:27:19 +08:00
    主要是不想写 sql ,对大部分企业应用来说,提高的效率会高于性能带来的影响
    jjx
        13
    jjx  
       2016-06-16 15:57:51 +08:00
    @mathgl

    没, 所以我大部分基本都转 gevent 了 :)
    jinxueliu
        14
    jinxueliu  
    OP
       2016-06-16 16:47:23 +08:00
    @wmttom DSL 指的是什么
    king110
        15
    king110  
       2016-06-16 16:55:21 +08:00
    查询效率感觉差不多吧,这个得看具体的业务规模了。
    mathgl
        16
    mathgl  
       2016-06-16 17:12:19 +08:00
    @jjx 有没有在 windows 下用过 gevent?
    jjx
        17
    jjx  
       2016-06-16 17:52:24 +08:00   ❤️ 1
    @mathgl

    一个企业应用在 windows 下跑过 3 年, gevent+postgresql+nginx+bottle, 最多 70~80 个用户访问, 没出问题, 不过现在不自虐了, 就是没有问题, windows 运维也麻烦
    mathgl
        18
    mathgl  
       2016-06-16 18:56:01 +08:00
    @jjx gevent 有个 libev 的依赖,而那个东西是不是完全支持 windows 查不到什么结果。所以我一直认为 gevent 在 win 下不是什么 production ready 的。
    mathgl
        19
    mathgl  
       2016-06-17 23:25:38 +08:00
    @jjx http://edsuom.com/sAsync/sasync.html 无意中发现了这个东西,似乎可以解决共用的问题。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3397 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 11:58 · PVG 19:58 · LAX 03:58 · JFK 06:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.