现在想要完成社交APP开发，对于存储来说，面临的选择的确很多，但我还是选择自己最为熟悉的MySQL。根据之前的经验，像是用户表这种会保持不动，但是有些表，比如feed index我在一开始就做了sharding的处理。另外很重要的东西就是数据访问层的实现了，虽然有些东西，比如读写分离的支持，现在不会用到，但是我觉着要支持，最起码要考虑这种情况将来会发生，到时候不至于太苦逼的到处重写代码，另外对于sharding，要做到跟访问通常的表类似的轻松，最后要带点儿ORM功能。

     做的第一件事情就是写这个数据访问工具，业务就是增删改查么，没有这家伙还怎么活！？用python两三百行代码对web.py的数据访问模块做下包装就搞出这么一个东西来， 最终可实现读写分离和对sharding的支持。当然在用的过程中发现问题不少，有些查询不能很好的满足需求啊等等，完善中。

     因为这个项目属于80/20那种课余爱好，资源较少，最开始也不想大推，只是给周围的小伙伴们先玩玩，程序员怪叔叔搏妹子一笑什么的，能有两三台机器就很不错了，所以对于传说中的分布式缓存，想想还是算了，多数东西还是直接读库，但是还是搭了个Redis，做啥用？主要是三件事情：1、保存token 2、记录用户在线状态 3、防刷业务 “你输入的太快了，请休息一下继续”之类的。但是所有数据的获取还是走的存储层，到时候如果要加缓存，可以直接在存储层去加，而不必去侵犯上层业务逻辑。

     做社交对图片的质量要求是很高的，多数都是会在后台专门拿出机器搭image magic等切图服务，但对于初创的社交app，搞这种东西挺耗费资源的