大家见过最恐怖的数据库表多大，增幅如何，这里我们只说关系数据库。。。

雪候鸟 · 发表于 2013-10-29 23:41

本帖最后由雪候鸟于 2013-10-29 23:43 编辑

woo2333 发表于 2013-10-29 23:18
怎么优化还是问问你们那个ocm吧。。。

谁也用不着问，ocm是偏dba, 不见的sql优化有多精通。就是数据增量有点大，这样的需求不是很常见，没有性能问题。

雪候鸟 · 发表于 2013-10-29 23:43

本帖最后由雪候鸟于 2013-10-30 00:15 编辑

woo2333 发表于 2013-10-29 23:16
Partitioning option….

分区不是银弹, 不是所有情况都使用。分区列不出现在查询里，partition pruning也用不上，反而拖累性能。当然我说的是oracle, 如果你说的是其他数据库例如db2又另说了。分区的概念就不一样了

雪候鸟 · 发表于 2013-10-29 23:45

本帖最后由雪候鸟于 2013-10-29 23:53 编辑

乐水鸣佩环发表于 2013-10-29 22:54
多观察，你遇到是一个通才

是不是通才不知道，关键是我继续问人家就不说了，还觉得我莫名其妙。我又不认识他，怎知他学习MB的。2千万每天对oracle来说也不是什么大问题，根本不用每天分段插入，5分钟插如几百万轻轻松松，关键是这个需求不常见。

雪候鸟 · 发表于 2013-10-30 00:01

mandriva 发表于 2013-10-29 22:23
你这个问的我很是莫名其妙啊，我的专业是MB，以前有过这些方面的工作经历。其余就回答不了你了，呵呵。

我不认识你，怎么知道你是MB. 为什么我莫名奇妙呢? 前面你句句big data, 我自然感兴趣你是否是专门从事big data的，于情于理我不觉得我问题有多奇妙。

never_say_never · 发表于 2013-10-31 22:57

雪候鸟发表于 2013-10-29 23:43
分区不是银弹, 不是所有情况都使用。分区列不出现在查询里，partition pruning也用不上，反而拖累性能 ...

Partition有物理表自身的限制,　还会和一些其他的数据库特性起冲突,　比如说Index in RAM和Index covering.　Sharding可以解决这个问题,　但是需要代码层面的修改.　

never_say_never · 发表于 2013-10-31 23:05

mandriva 发表于 2013-10-29 21:21
2千万条记录有一天的时间来插入，一天24小时，一小时3600秒。可以先插入，等到达IO瓶颈后，开始队列它，然 ...

这不是个时间累加的过程,　特别是如果插入是在传统数据库上的话,　随着单表数据量的增长,　索引的创建和维护开销都是极大的,　一天2千万条插入,　如果再加上同时需要其他使用导致的读写,　是个需要花功夫的事情,　不是"完全不是问题".

横向的比较例子,　根据2011年的数据(希望没记错), Twitter每天的新数据量大概是1亿4千万, Facebook like每天的新增量是10亿, 相比而言, 2千万也是不小的量级了.

never_say_never · 发表于 2013-10-31 23:16

雪候鸟发表于 2013-10-29 23:45
是不是通才不知道，关键是我继续问人家就不说了，还觉得我莫名其妙。我又不认识他，怎知他学习MB的。2 ...

你这个, 没用任何分表分区或者其他的优化就这样一直跑着一天加2千万条的操作了? 目前还没有性能问题?
这个Oracle的性能也太强了吧, 你的应用跑了多久了, 现在单表里面有多少数据了?

我觉得任何一个主流数据库几分钟内插入几百万应该都不是问题, 特别当插入是从SQL而不是应用层来的时候. 但是, 当数据量持续累加后, 我觉得肯定会遇到问题的吧... 特别是你这个表还得兼顾相应其他CRUD的操作...

雪候鸟 · 发表于 2013-10-31 23:29

本帖最后由雪候鸟于 2013-11-1 00:15 编辑

never_say_never 发表于 2013-10-31 23:16
你这个, 没用任何分表分区或者其他的优化就这样一直跑着一天加2千万条的操作了? 目前还没有性能问题?
这 ...

:-)，老弟问道点子上了. (看你ID很新，姑称老弟了) 。因为这个表是个价格建议表, 所以使用网络爬虫全世界的抓一些价格回来，然后做为我们公司对客户议价的基础，所以每天插入量很大。数据倒是从应用层过来的，是batch分批插入的，所以性能不是问题。因为是个价格参考表，数据“老化”的很快，最多保存一个月了, 常用的也就是最后3天的数据，所以索引和数据的热块多数都在内存。每天也批量删除3次，表的整体记录维持在10亿以內，硬件还算不错能挺得住。当然频繁的插入，造成统计数据不准，optimizer选择的执行计划偏差大的情况还是有的。这个表上的几个不稳低sql的执行计划都让我固定了，所以查询性能问题不大。

雪候鸟 · 发表于 2013-10-31 23:38

本帖最后由雪候鸟于 2013-11-1 00:41 编辑

never_say_never 发表于 2013-10-31 22:57
Partition有物理表自身的限制,　还会和一些其他的数据库特性起冲突,　比如说Index in RAM和Index coverin ...

看老弟用词不是搞oracle出身的，你看家的是哪个数据库？sharding在oracle里不好做，尤其是已经跑了20多年的应用了。数据库里将近一万个表，关系错综复杂做垂直sharding不是不可能，分了以后到时候网络压力更大例如跨库的join。做水平sharding，oracle天生sharing everything特性造成在这方面是个短板。所以oracle不适合very large的关系数据库。关系数据库里db2, mysql倒是可以这做，可以share nothing。oracle我觉得整体来说，更适合高并发业务密集的应用，不适合数据密集的。你说呢?

orionsnow · 发表于 2013-11-1 00:57

你开始新工作了？

账号		自动登录	找回密码
密码			注册

萍聚头条

[其它] 大家见过最恐怖的数据库表多大，增幅如何，这里我们只说关系数据库。。。