大家见过最恐怖的数据库表多大，增幅如何，这里我们只说关系数据库。。。
本帖最后由 雪候鸟 于 2013-10-29 23:59 编辑我最近的工作主要是查询性能优化，有一个价目表，单表每天平均插入两2千万条记录。这是我见过最大增幅的表{:7_433:} 。大家有没有更恐怖的。。。
***************************
估计是我上下文没有交代清楚。我补充一下，没有性能问题，也不需要什么性能方案，就是觉得这个需求不常见。 2千万条记录 有一天的时间来插入，一天24小时，一小时3600秒。可以先插入，等到达IO瓶颈后，开始队列它，然后一段一段的插入，完全不是问题。 mandriva 发表于 2013-10-29 21:21
2千万条记录 有一天的时间来插入，一天24小时，一小时3600秒。可以先插入，等到达IO瓶颈后，开始队列它，然 ...
还没有什么性能问题。你们那里也有这个数据量插入量 吗 雪候鸟 发表于 2013-10-29 21:34
还没有什么性能问题。你们那里也有这个数据量插入量 吗
我们这里没有，我只是就 big data processing 阐述一般的解决方案，能处理最大数据吞吐的是非关系数据库的数据中心，比如说谷歌的 chunk server 服务器群，即使是一台服务器处理需求和响应的能力有限，通过若干chunk server 的合力造成的规模也是相当灿烂的。 mandriva 发表于 2013-10-29 21:44
我们这里没有，我只是就 big data processing 阐述一般的解决方案，能处理最大数据吞吐的是非关系数据库 ...
我们公司非IT公司，所以没数据中心的概念。数据量还big不起来。你专门搞big data的吗 你这个问的我很是莫名其妙啊，我的专业是MB，以前有过这些方面的工作经历。其余就回答不了你了，呵呵。 mandriva 发表于 2013-10-29 22:23
你这个问的我很是莫名其妙啊，我的专业是MB，以前有过这些方面的工作经历。其余就回答不了你了，呵呵。
有意思，遇到了一个MB参与我的贴子。 雪候鸟 发表于 2013-10-29 22:25
有意思，遇到了一个MB参与我的贴子。
多观察，你遇到是一个通才 Partitioning option…. 怎么优化还是问问你们那个ocm吧。。。 本帖最后由 雪候鸟 于 2013-10-29 23:43 编辑
woo2333 发表于 2013-10-29 23:18
怎么优化还是问问你们那个ocm吧。。。
谁也用不着问，ocm是偏dba, 不见的sql优化有多精通。就是数据增量有点大，这样的需求不是很常见，没有性能问题。 本帖最后由 雪候鸟 于 2013-10-30 00:15 编辑
woo2333 发表于 2013-10-29 23:16
Partitioning option….
分区不是银弹, 不是所有情况都使用。分区列不出现在查询里，partition pruning也用不上，反而拖累性能。当然我说的是oracle, 如果你说的是其他数据库例如db2又另说了。分区的概念就不一样了 本帖最后由 雪候鸟 于 2013-10-29 23:53 编辑
乐水鸣佩环 发表于 2013-10-29 22:54
多观察，你遇到是一个通才
是不是通才不知道，关键是我继续问人家就不说了，还觉得我莫名其妙。我又不认识他，怎知他学习MB的。2千万每天对oracle来说也不是什么大问题，根本不用每天分段插入，5分钟插如几百万轻轻松松，关键是这个需求不常见。 mandriva 发表于 2013-10-29 22:23
你这个问的我很是莫名其妙啊，我的专业是MB，以前有过这些方面的工作经历。其余就回答不了你了，呵呵。
我不认识你，怎么知道你是MB. 为什么我莫名奇妙呢? 前面你句句big data, 我自然感兴趣你是否是专门从事big data的，于情于理我不觉得我问题有多奇妙。 雪候鸟 发表于 2013-10-29 23:43
分区不是银弹, 不是所有情况都使用。分区列不出现在查询里，partition pruning也用不上，反而拖累性能 ...
Partition有物理表自身的限制, 还会和一些其他的数据库特性起冲突, 比如说Index in RAM和Index covering. Sharding可以解决这个问题, 但是需要代码层面的修改. mandriva 发表于 2013-10-29 21:21
2千万条记录 有一天的时间来插入，一天24小时，一小时3600秒。可以先插入，等到达IO瓶颈后，开始队列它，然 ...
这不是个时间累加的过程, 特别是如果插入是在传统数据库上的话, 随着单表数据量的增长, 索引的创建和维护开销都是极大的, 一天2千万条插入, 如果再加上同时需要其他使用导致的读写, 是个需要花功夫的事情, 不是"完全不是问题".
横向的比较例子, 根据2011年的数据(希望没记错), Twitter每天的新数据量大概是1亿4千万, Facebook like每天的新增量是10亿, 相比而言, 2千万也是不小的量级了.
雪候鸟 发表于 2013-10-29 23:45
是不是通才不知道，关键是我继续问人家就不说了，还觉得我莫名其妙。我又不认识他，怎知他学习MB的。2 ...
你这个, 没用任何分表分区或者其他的优化就这样一直跑着一天加2千万条的操作了? 目前还没有性能问题?
这个Oracle的性能也太强了吧, 你的应用跑了多久了, 现在单表里面有多少数据了?
我觉得任何一个主流数据库几分钟内插入几百万应该都不是问题, 特别当插入是从SQL而不是应用层来的时候. 但是, 当数据量持续累加后, 我觉得肯定会遇到问题的吧... 特别是你这个表还得兼顾相应其他CRUD的操作...
本帖最后由 雪候鸟 于 2013-11-1 00:15 编辑
never_say_never 发表于 2013-10-31 23:16
你这个, 没用任何分表分区或者其他的优化就这样一直跑着一天加2千万条的操作了? 目前还没有性能问题?
这 ...
:-)，老弟问道点子上了. (看你ID很新，姑称老弟了) 。因为这个表是个价格建议表, 所以使用网络爬虫全世界的抓一些价格回来，然后做为我们公司对客户议价的基础，所以每天插入量很大。数据倒是从应用层过来的，是batch分批插入的，所以性能不是问题。因为是个价格参考表，数据“老化”的很快，最多保存一个月了, 常用的也就是最后3天的数据，所以索引和数据的热块多数都在内存。每天也批量删除3次，表的整体记录维持在10亿以內，硬件还算不错能挺得住。当然频繁的插入，造成统计数据不准，optimizer选择的执行计划偏差大的情况还是有的。这个表上的几个不稳低sql的执行计划都让我固定了，所以查询性能问题不大。 本帖最后由 雪候鸟 于 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
你开始新工作了？
8月1号开始的 雪候鸟 发表于 2013-10-31 23:38
看老弟用词不是搞oracle出身的，你看家的是哪个数据库？sharding在oracle里不好做，尤其是已经跑了20多 ...
哈, 原来是这样, 不过单表10亿也很多了. 我经手过的, 最大的也就是单表1.5亿, 日常使用场景, 开源数据库, 用了Partition, 在PC Server上面跑, 而且估计在10亿的时候就会出现物理瓶颈了.
没太看懂关于Oracle垂直Sharding是什么意思, 嗯, 你是说垂直Partitioning? 我没有特定的数据库偏好, 都用过, 不过用Oracle是很久很久之前的事了, 那时水平还很低, 没意识到任何性能问题 ;-p
我也觉得这些大数据库厂商用于传统事务还可以, 对大规模数据而言, 成本太高了, 都是堆硬件, 竞争不过开源数据库, 更不用说现在的NoSQL数据库了.
never_say_never 发表于 2013-11-1 08:37
哈, 原来是这样, 不过单表10亿也很多了. 我经手过的, 最大的也就是单表1.5亿, 日常使用场景, 开源数据库, ...
你用的什么开源数据库? 集群了吗? 其实一般传统性企业数据量根本没有那么大，big不起来，还不用考虑nosql. 我倒是考虑入过业务继续增长，可以用mysql配合oracle使用。客户查询信息或者简单事务的时候用mysql, 开始下订单的时候再从应用层把链接转义到oracle上。
页:
[1]