- 论坛徽章:
- 0
|
简单想了一下思路，抛砖引玉一下：
1：可以自己设计数据结构也可以使用数据库，自己设计数据结构的话，我会先设计一个hash表，用户id的哈希值为表索引，每个槽后面跟一个平衡二叉树，二叉树节点为好友id。简单估算之后发现总存储量为1000w*(4+50*12)=5.6G，大于4G，或者采用64位操作系统，或者采用多个32位服务器(选3个，按大小hash一下就行)。只说64位单台服务器的(多台服务器仅多一层hash)，查找二维好友需要先找到用户的槽，对平衡树中的每个用户再找他的好友。由于找到槽需要O(1)的时间，平衡树中平均有50个节点，从平衡树中查找好友需要lg(50)的时间，故而查找时间为1+50*lg(50)=283；插入/删除的话比较简单了,都是O(1+lg(50))。
如果采用数据库设计的话，一种表，两个字段，用户id和好友id，根据我们的数据量1000w*50=5亿应该分表。假设用mysql的话，根据之前的经验，每个db下数据表保持在300以下，每个表数据量保持在100w以下速度比较平稳，分成103个表，每个表大概49w数据量。查询二维好友的话，也是先查出所有一维好友，然后对每个一维好友再查一遍好友，时间跟上面的类似。
2：方式为数据库+文件。数据库中存url，创建时间，网页文件目录名，而文件中存真实网页内容。考虑到会按时间批量获取网页，则将网页按(年/月/日)的日期目录存放，每个目录下文件量也不会太大。
3：两个关系表，用户和分类关系表，分类和文章关系表，两个关系表都做分表。
4：还是用数据库吧，三种表，歌曲表，url表，歌曲与url关系表，这三个表都可以hash。歌曲表按歌曲id哈希，url表按url的id哈希，歌曲与url关系表按歌曲id哈希，将URL_ID置为不可用时仅在url表中设置状态，而下次查询歌曲对应的url时检查一下url的可用状态，不可用则删除此条url记录和歌曲与url关系表中的对应记录。
怎么感觉这些题目都是考数据库设计呢？至于存储量大了，访问量大了怎么办，只能是分而治之了。^_^ |
|
免费注册
楼主: 侧面bt
发表于 2010-04-06 15:55
