@qdvictory pickle 很慢啊，而且丧失可读性

如果内存比较宝贵的话，建议减小 key 的长度，且不要使用太多 key。
例如 v2ex:member（hash），id 作为 field name，值可以用 JSON 或其他编码方式。
Redis 有个坑就是取出来的数据类型都是字符串，所以想区分 1 和 '1'、'' 和 None 的时候会很囧。而 JSON 可以保留类型信息。
这里有些经验： http://www.keakon.net/tag/Redis

我是自己写的 ORM。
不过有很多情况是不能采用通用的解决方案的，因为达不到最高的效率。
实体数据可以直接用 ORM 来处理，索引、关系、缓存等必须根据使用情况来设计。

@mawenjian 知乎在同时使用又拍和七牛，万一哪家挂了，可以轻松迁移。

错误日志别分词了，搜个 __init__.py、C++ 咋办

@jeeson 我啥都没做。17 日 15:20 ~ 20 日 16:54 是乱码，其余正常。

@jeeson 这 2 天 iOS 版一直是乱码，重装也没用。

那是 emacs 设置 encoding 的风格。
http://www.python.org/dev/peps/pep-0263/

这表你反正都得全读出来，为什么不直接一次读出来，再在应用里处理？循环查询数据库会被骂死的…

你的需求有问题吧

如果是这样的：
id name
1 a
2 a1
3 a12

你要怎么改名？

有种 V2EX 都是屌丝的感觉。

用 Python 吧，不纠结：
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance

@fansgentle 去了 3 个月了=。=

1. 尽量别依赖数据库来实现数据的关联关系。
知乎内部的 MySQL 使用准则中，就禁止使用 JOIN、GROUP BY、子查询和外键。
说实话，这等于使用非关系型数据库了。

2. 查询主要靠缓存和索引。
但千万别乱加缓存和索引，它们和表的结构、业务逻辑、使用频率之间有且只有一个最优解。
你只能靠经验和测试来寻找，而且越到后期，这些就越难改动。

做到这 2 点还有瓶颈的话，基本也是价值不菲司了，也不会缺有经验的 DBA 了。
这时的瓶颈主要在写了，就通过分离读写、分库、使用 SSD 的方式来满足吧。这部分我也不熟。

@akira 原文有提到，发给一个进程即可，例如 supervisor。
知乎是通过 Redis 来接收和处理日志，并将其 publish 出去，使订阅者可以实时监测感兴趣的日志。

mysql -u 用户名 -p密码 < sql文件路径
其他不懂的请 Google……

还是用 logging 吧……
http://www.keakon.net/2013/02/21/%E5%85%B3%E4%BA%8Elogging%E7%9A%84%E4%B8%80%E4%BA%9B%E7%90%90%E4%BA%8B

被攻击了，几个工程师在机房待了一天=。=