数据库设计-大数据量即使计算

LONGZHEZHILONG 2012-11-30 05:49:41
微博的用户现在号称有3亿多,在这多用户的前提之下,依然能快速检索到相关的记录。像这种这么存储这么多记录的大型的数据表,该怎么设计呢?
...全文
190 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
-晴天 2012-12-03
  • 打赏
  • 举报
回复
引用 11 楼 LONGZHEZHILONG 的回复:
引用 10 楼 DBA_Huangzj 的回复: 核心思想当然就是减少单表的数据,减少访问数据的开销。设计这个东西不好说,不过可以考虑减少行数,增加列数(也就是适当冗余数据)。 甚至有一种变态一点的思想,一个省份一个库。 如果抛开设计的讨论,单单就是数据计算的逻辑,怎么样可以让计算快一点呢?
太笼统了. 索引,查询的语句,预编辑,是否用临时表,缓存的大小......什么都会影响到性能.
LONGZHEZHILONG 2012-12-03
  • 打赏
  • 举报
回复
引用 10 楼 DBA_Huangzj 的回复:
核心思想当然就是减少单表的数据,减少访问数据的开销。设计这个东西不好说,不过可以考虑减少行数,增加列数(也就是适当冗余数据)。 甚至有一种变态一点的思想,一个省份一个库。
如果抛开设计的讨论,单单就是数据计算的逻辑,怎么样可以让计算快一点呢?
發糞塗牆 2012-12-03
  • 打赏
  • 举报
回复
优化索引,适当冗余
發糞塗牆 2012-11-30
  • 打赏
  • 举报
回复
核心思想当然就是减少单表的数据,减少访问数据的开销。设计这个东西不好说,不过可以考虑减少行数,增加列数(也就是适当冗余数据)。 甚至有一种变态一点的思想,一个省份一个库。
SQL77 2012-11-30
  • 打赏
  • 举报
回复
搜索引擎.......
LONGZHEZHILONG 2012-11-30
  • 打赏
  • 举报
回复
引用 6 楼 DBA_Huangzj 的回复:
这就有点麻烦,很多处理大数据量的功能都要求企业版或者标准版。那就用分开实体表的方法来处理。按省份来分实体表,然后根据数据的注册信息把数据分到这些表里面
版主还有其他方法不?
LONGZHEZHILONG 2012-11-30
  • 打赏
  • 举报
回复
引用 5 楼 Beirut 的回复:
淘宝不是公布了自己的一些解决方案,你去找找看看。 基础数据肯定还是要存关系型库里面的。
淘宝的好像是MYSQL 的, 我们的是SQL SERVER的
發糞塗牆 2012-11-30
  • 打赏
  • 举报
回复
这就有点麻烦,很多处理大数据量的功能都要求企业版或者标准版。那就用分开实体表的方法来处理。按省份来分实体表,然后根据数据的注册信息把数据分到这些表里面
黄_瓜 2012-11-30
  • 打赏
  • 举报
回复
淘宝不是公布了自己的一些解决方案,你去找找看看。 基础数据肯定还是要存关系型库里面的。
LONGZHEZHILONG 2012-11-30
  • 打赏
  • 举报
回复
引用 3 楼 DBA_Huangzj 的回复:
嗯,这样分摊数据表的数据大小
但是要企业版啊,我们小企业买不起企业版数据库啊
發糞塗牆 2012-11-30
  • 打赏
  • 举报
回复
嗯,这样分摊数据表的数据大小
LONGZHEZHILONG 2012-11-30
  • 打赏
  • 举报
回复
引用 1 楼 DBA_Huangzj 的回复:
传统的关系数据模型对此有点吃力,需要做狠毒哦东西,如果能接受可以换nosql。如果不能,那么硬件首先要跟得上。然后做分区(比如按省份分区)。索引、写法要合理。设计的时候可以适当冗余数据,减少表连接。
你是说用分区表的方法吗?
發糞塗牆 2012-11-30
  • 打赏
  • 举报
回复
传统的关系数据模型对此有点吃力,需要做狠毒哦东西,如果能接受可以换nosql。如果不能,那么硬件首先要跟得上。然后做分区(比如按省份分区)。索引、写法要合理。设计的时候可以适当冗余数据,减少表连接。

27,579

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 应用实例
社区管理员
  • 应用实例社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧