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
yhf
V2EX  ›  Python

想做一个网页版的秘密,求建议。

  •  
  •   yhf · 2014-05-20 15:28:44 +08:00 via iPad · 3497 次点击
    这是一个创建于 3842 天前的主题,其中的信息可能已经有所发展或是发生改变。
    想做一个网页版的秘密,准备用Django。用户方面是准备用人人的OAuth,但现在有一些问题,我比较菜鸟,还请各位大牛点拨。

    1. 假设我有100位好友,我的这100位好友也各有100位好友。那我在生成时间轴的时候想要获得朋友圈(包括好友和好友的好友)的状态,首先得遍历我的100位好友,然后又遍历他们各自的100位好友,这样就得10000次左右,这得花多少时间?

    2. 我用一张表存放所有用户的帖子。我要选出所有属于我朋友圈用户的帖子,等价的sql语句大致是select * from posts where user in(...我朋友圈的1w个用户...),这得花多少时间?

    3. 假设我朋友圈这10000名左右的用户各有一条帖子。然后我要按照某种算法将这10000条帖子排序,我只想取前20条排在时间轴上,排序所花的时间感觉又是一个很大的开销。

    4. 我第一次刷新,服务器经过上述步骤给我返回了前20条帖子。我过10分钟再刷新,服务器再从头算一遍?我每次刷新都重新算一遍,给我返回当前排在前20的?

    想到以上几点,我就有种蛋蛋的忧伤。。我菜鸟一个,没有这种略复杂的网站制做经验,还请大牛们指教。。
    17 条回复    2014-05-20 17:14:16 +08:00
    towser
        1
    towser  
       2014-05-20 15:45:19 +08:00
    1、只需要谁登录后就获取谁的最新动态,调用人人的API即可,不需要实时获取所有用户的动态;
    2/3/4、数据库设计问题,用好索引,10000名用户还不足以形成性能瓶颈。
    yhf
        2
    yhf  
    OP
       2014-05-20 15:53:34 +08:00 via iPad
    @towser 谢谢!

    1. 我想要获得100个好友的各自的好友,就需要向人人请求调用API100次,这样是不是有点慢?不知道能否把好友圈的用户存在自己数据库?如果存储在自己数据库,好友圈的改动怎么判断?

    2/3/4. 为了前20的帖子而排序10000条帖子是否值得。。。我在想能不能把上一次刷新已经获得的帖子存在客户端。。。
    ShiningRay
        3
    ShiningRay  
       2014-05-20 15:58:20 +08:00
    以前做过,后来被有关部门关停了
    ShiningRay
        4
    ShiningRay  
       2014-05-20 16:19:09 +08:00
    你可以直接下代码 https://github.com/qiushibaike/moumentei rails写的
    casparchen
        5
    casparchen  
       2014-05-20 16:21:15 +08:00
    graph database
    你的效率问题便迎刃而解了
    yhf
        6
    yhf  
    OP
       2014-05-20 16:31:47 +08:00 via iPad
    @ShiningRay 谢谢 我看看
    yhf
        7
    yhf  
    OP
       2014-05-20 16:32:11 +08:00 via iPad
    @casparchen 谢谢 我去学习一下
    wangtao
        8
    wangtao  
       2014-05-20 16:43:05 +08:00
    codingpp
        9
    codingpp  
       2014-05-20 16:44:30 +08:00
    每次访问调用API100次,这个是不可取的,应该写个作业把好友信息同步下来

    使用传统关系型数据库存储这个人和人之间的关系不适合,可以尝试图数据库
    这样你就会根据某个UID很快获得和这个UID相关的UID

    获得这些UID以后,就是获得按时间排序的帖子的问题。如果不想拿到数据以后再排序,那么所用到的索引必须是排好序的。

    转换成sql语句就是select xx from tiezi where uid in (uid1, uid2, uid3) order by time desc limit 20

    不过这样的话也会有问题,随着用户量增大,这个sql就越来越慢了。。。暂时没有想到好方法
    paloalto
        10
    paloalto  
       2014-05-20 16:47:49 +08:00
    好吧,我又无耻地来帖一下这个网站 http://www.perber.com
    代码 https://github.com/naoyeye/Perber
    yhf
        11
    yhf  
    OP
       2014-05-20 16:50:09 +08:00 via iPad
    @codingpp 把信息同步下来可是过一天用户又添加了几个好友怎么办?不请求调用api怎么知道好友信息有没有改变?

    额,我只有SAE,穷学生一个买不起VPS,所以用非关系型数据库部署的时候可能比较麻烦。哎,真蛋疼。。。
    ShiningRay
        12
    ShiningRay  
       2014-05-20 16:52:35 +08:00
    @wangtao 浓浓的山寨气息扑面而来
    ericls
        13
    ericls  
       2014-05-20 17:00:20 +08:00
    是什么?
    糗事百科的精简版本?
    codingpp
        14
    codingpp  
       2014-05-20 17:06:42 +08:00
    @yhf
    写一个作业定时访问api接口,然后更新本地数据库

    只用关系型数据库那就这样吧。。
    uid Friend_ids

    select friend_ids from table where uid = xx
    for friend_id in friend_ids:
    select friend_ids from table where uid = friend_id

    如果想快的话,把关系放在内存中,数据库有更新时触发更新内存中的关系
    yhf
        15
    yhf  
    OP
       2014-05-20 17:06:54 +08:00 via iPad
    @ericls 可以看一下最近很火的一个APP:秘密。现在好像改名无秘了。
    yhf
        16
    yhf  
    OP
       2014-05-20 17:08:58 +08:00 via iPad
    @codingpp 嗯嗯,谢谢!
    RIcter
        17
    RIcter  
       2014-05-20 17:14:16 +08:00
    @ShiningRay 记得你们原来做过秘密...我记得秘密是你们先做的啊=A=
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3381 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 100ms · UTC 11:52 · PVG 19:52 · LAX 03:52 · JFK 06:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.