大表设计与优化讨论下...贡献全部分,虽然很少~

Foliole 2018-03-08 09:01:10
加精
有一个大表,有几百G,还会不断地增大,主要用来查询。
目前我想到的只有两个方法:
1.逻辑表分区。
2.分表。

第一种方法,在不断增大期间还是会有撑不住的时候;
第二种方法,查询的时候很容易跨几个表,跨几个表会不会影响查询?

各位大婶还有没有别的方案?
以上两种方法也一起讨论下可好?
...全文
4891 36 打赏 收藏 转发到动态 举报
写回复
用AI写文章
36 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
可以根据地区、时间等做分表,如按省份分表,按时间天,月,年等分表,通过这两个方向切割,应该会小很多了,
Foliole 2018-03-14
  • 打赏
  • 举报
回复
感谢各位的分享。
江南彼岸 2018-03-12
  • 打赏
  • 举报
回复
及时归档数据。不能归档,分区吧
疯狂的疯 2018-03-10
  • 打赏
  • 举报
回复
。。。路过,学习、
Foliole 2018-03-09
  • 打赏
  • 举报
回复
各位大佬所言极是!!!
ameiyuan0122 2018-03-09
  • 打赏
  • 举报
回复
我也来看看,以后可能有这需求呢
AcHerat 2018-03-09
  • 打赏
  • 举报
回复
我觉得现在不是你分不分表的问题,而是要将实际的数据和业务结合起来分析,综合上边大佬们给出的意见,再进行活动和历史的区分,分表和分库的区分,分存储和分服务器的区分。毕竟数据是围绕业务产生,又被使用者检索的,如果单独的去分析几百个G的大表怎么区分,解决不了根本,也没有最优的方案。 就像20楼所说,有银子什么都不是事,而且也如大版16楼所说,不一定非要用sql server去处理这么大的数据量,可以结合现有的数据处理技术(hadoop、spark等)
zjcxc 2018-03-09
  • 打赏
  • 举报
回复
引用 20 楼 goldenhawking 的回复:
速度慢不是因为几百G,而是因为行数多。根本原因是即使有索引,在如此多的数据量下,单服务器的索引本身访问已经很耗时了。 建议: 1、首先商议并固化查询条件。这个和具体产品有关系。比如,按照时间、账户、类别之类的关键字查询。 2、用每次客户都会指定的那些字段进行组合生成分区规则,用于单台服务器上的分区。 3、如果有独立子数据集合(如大的地理区域之类,访问A城市的数据,就很少会访问B,如同城的消费之类的情况),就太好了,直接怼服务器。 4、买几块固态SSD建立盘阵,索引就放在SSD上。毕竟,只要有银子,那都不是事。
BI 的多维数据模型
weixin_41800531 2018-03-09
  • 打赏
  • 举报
回复
十年一梦(炒股的经历)续发了,麻烦下一个我发的资源需要几个c币我要下个软件
cattpon 2018-03-09
  • 打赏
  • 举报
回复
感谢楼主分享~
Foliole 2018-03-09
  • 打赏
  • 举报
回复
引用 23 楼 weixin_41800531 的回复:
更别说分到多台服务器来分散查询了
哥,你的全文呢?
weixin_41800531 2018-03-09
  • 打赏
  • 举报
回复
更别说分到多台服务器来分散查询了
nettman 2018-03-09
  • 打赏
  • 举报
回复
感谢楼主分享,关注,学习
qq_41814037 2018-03-09
  • 打赏
  • 举报
回复
Foliole 2018-03-09
  • 打赏
  • 举报
回复
引用 30 楼 kangqiang521 的回复:
至于查询效率,不管分区还是分表,如果你始终要从所有表中去找出数据,那么怎么分帮助也不大(除非分散到各服务器,然后程序上分别查询之后合并) 另外,如果你的查询只涉及部分的分区(或分表),但如果均未从你的查询写法或条件上预判出涉及的分区或分表,那就也意味着要查所有数据去找满足条件的了,这种情况分区和分表也没意义
你是复制黏贴赚积分么?还是说认同这个观点?
kangqiang521 2018-03-09
  • 打赏
  • 举报
回复
至于查询效率,不管分区还是分表,如果你始终要从所有表中去找出数据,那么怎么分帮助也不大(除非分散到各服务器,然后程序上分别查询之后合并) 另外,如果你的查询只涉及部分的分区(或分表),但如果均未从你的查询写法或条件上预判出涉及的分区或分表,那就也意味着要查所有数据去找满足条件的了,这种情况分区和分表也没意义
  • 打赏
  • 举报
回复
历史数据分段 存储
吉普赛的歌 2018-03-08
  • 打赏
  • 举报
回复
引用 7 楼 xiaoye1202 的回复:
查询是实时的业务,要增加用户体验,主要是要求响应时间要及时。
我在 #3 中的建议是非常中肯的。 另外针对响应要及时, 靠目前的情况是没办法的了, 必须要增加报表处理。 对于历史性不再修改的信息, 通过报表先处理出来, 用户要查历史信息则直接查报表的结果表。 你去银行查几年前的信息, 是不是也得交费? 其实一样的道理, 陈年信息, 都是必须付出代价的。
發糞塗牆 2018-03-08
  • 打赏
  • 举报
回复
贴主请详细说明,否则回答也是粗糙的。
引用 5 楼 z10843087 的回复:
@發糞塗牆 很久没有上论坛了啊
我一直在写博客
Foliole 2018-03-08
  • 打赏
  • 举报
回复
引用 4 楼 z10843087 的回复:
总共数据有多少行?另外相关的查询也可以发来看看 关于方案1 ,在不断增大期间还是会有撑不住的时候的问题。 可以建立一个归档表,定期把不用的数据(比如三年以前的数据)放到归档表里面。 关于方案2,如果你分表之后还是需要把所有数据查询出来的话,那么性能的提升也不会很明显。这种情况,你可以选择读写分离架构。报表允许执行时间长一点,但是不会 影响OLTP的业务
行数现在过亿,历史的数据也有需要查询的时候。 查询是实时的业务,要增加用户体验,主要是要求响应时间要及时。
加载更多回复(16)

27,579

社区成员

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

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