推荐学习书目
› 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
This topic created in 3792 days ago, the information mentioned may be changed or developed.
Supplement 1 · Jun 16, 2016
假设有一台数据库服务器， 然后我有几台分布式的计算服务器，
计算服务器需要从数据库服务器上查询大量的数据，然后再进行本地计算
现在我有几个问题
1 如何加速查询时间
2 如何加速网络传输时间（计算服务器和数据库服务器不在一个网段）
3 第 2 个问题是否可以通过在计算服务器建立备库来解决（变成本地查询）
计算服务器需要从数据库服务器上查询大量的数据，然后再进行本地计算
现在我有几个问题
1 如何加速查询时间
2 如何加速网络传输时间（计算服务器和数据库服务器不在一个网段）
3 第 2 个问题是否可以通过在计算服务器建立备库来解决（变成本地查询）
19 replies • 2016-06-17 23:25:38 +08:00
 |
estJun 16, 2016
1
就是手机贴膜和不贴膜的区别。
效率还是看你的姿势水平是否高。 |
 |
2
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 语句或函数) |
4 |
bobuickJun 16, 2016
3
写简单的， sqlalchemy 不一定比你手写效率好。
写大量的， 复杂的。 也不一定比你手写效率好(基于你已经非常了解各种联合查询， sql 优化)。 但是大量的情况下， sqlalchemy 至少会保证比较稳定的效率， 可能某一句有些优化空间， 需要人为跟着 debug 。 相反的，大量的情况下，人类去干， 就非常没保障了， 先不说不同的人水平不同，即时同一个人，也不稳定 |
 |
sekiJun 16, 2016
4
如果是根据用户输入拼接的 sql 也有可能被注入攻击
|
 |
clinoJun 16, 2016
6
我记得用 sqlalchemy 不拼 sql 语句的姿势可以防 sql 注入的
|
 |
7
跟一楼想法差不多, 效率高低看你水平高低, 其实你打印一下 sqlalchemy , 也是执行 sql, 优势是显而易见的, 你觉得代码里面写很多 sql 好 还是 写 orm 好呢? 哪个好维护? 你愿意写哪个? 但是用 orm 的前提是你的 sql 要足够好
|
|
jjxJun 16, 2016
8
|
 |
zhuangzhuang1988Jun 16, 2016
10
|
 |
11
即使拥有手写高效率 SQL 能力，也推荐用 sqlalchemy 的 core ，只用连接池和 SQL 的组装，不会损失多少性能。
并且 SQL 组装变为 Python 函数之后，可以更好的分层分装，抽象复用。 从维护的角度讲，一份代码中最好不要出现多种 DSL 。 |
 |
nimdanoobJun 16, 2016
12
主要是不想写 sql ，对大部分企业应用来说，提高的效率会高于性能带来的影响
|
 |
king110Jun 16, 2016
15
查询效率感觉差不多吧，这个得看具体的业务规模了。
|
|
17
@mathgl
一个企业应用在 windows 下跑过 3 年, gevent+postgresql+nginx+bottle, 最多 70~80 个用户访问, 没出问题, 不过现在不自虐了, 就是没有问题, windows 运维也麻烦 |
 |
mathglJun 16, 2016
18
@jjx gevent 有个 libev 的依赖，而那个东西是不是完全支持 windows 查不到什么结果。所以我一直认为 gevent 在 win 下不是什么 production ready 的。
|
|
mathglJun 17, 2016
19
@jjx http://edsuom.com/sAsync/sasync.html 无意中发现了这个东西，似乎可以解决共用的问题。
|
Select Language