富有挑战性的问题,建立超大数据库的问题.

[haiwangstar]

现在要设计一个记录数非常大的数据库表,表的结构非常简单,但记录数会非常大,可能会有几十亿条,但表的字段只包括几个数字列,再有一个列用来保存图片,我现在准备采用BFILE类型来把图片路径保存在表中,另外表会根据某个列数据进行分区.

在设计这样的大表还应该注意哪些问题..欢迎大家赐教.

凡提出较好意见的,可以另行开贴再加分.

[i_love_pc]

几十亿条
========
的确有点多

[kkk_visual]

帮顶一下。

[renjun24]

up

[huylghost]

几十亿条, level ，x，y，图片，
google earth 是不是就是这么做的?

[haiwangstar]

楼上的朋友,没错.就是做EARTH MAP

[lin_style]

这样子的话。
扩充什么就不要考虑了。
设计个最适合查询的。

[whalefish2001]

索引是必要的，不过，索引会占用很大空间。

[wuluhua2003]

学习了

[haiwangstar]

flyycyu(fly) 这位朋友,非常感谢您的意见!!

我过去从来没有搞过这么大的数据库系统,所以我上面所讲述的一切都只是纸上谈兵.但我的思路,设想几乎同你都是一致的.关于是否用BFILE的问题,这个也是一个不大关乎全局的小问题.

我只所以特意问会不会有IO不均衡问题,是因为我的同事认为我们这样的方案是不行的,IO会不均衡(他认为还有很多问题).而我认为是绝对不会出现这种情况的,因为ORACLE在设计中他不可能不考虑这样显而易见的问题,我也查了资料,在ORACLE集群中,网络负荷也是存在ORACLE负荷均衡的.

看来这样的方案才是经实践检验过的可行的.

[haiwangstar]

另外还有一个问题,就是flyycyu(fly) 这位朋友 你们是使用SAN存储设备的吗,光纤网络? 这套系统是不是非常昂贵? 即使不是,我想也一定是共享统一存储器吧.

[haiwangstar]

我们系统对数据的装入也是有要求的.

朋友这句话是怎么讲.能说一下吗

[asker100]

这种情况就不要用数据库了，直接的文件存储+优化的索引，要看穿数据库这种东西

[gameboy999]

同意楼上，地图数据自己的特点，不一定需要通用的数据库

[flyycyu]

目前正做完这么一个系统,和你的类似,数据大概是是每个表9亿左右,但是有6,7个表都是这么大数据量,一个表的字段大概有50,60个,主要都是float.
不知道你的数据是怎么进入的,我们系统对数据的装入也是有要求的.
第一,个就是分表操作,在以前用infomix之类的系统的开发都采用,我在做我们系统的时候第一个方案设计出来的就是分表,当然带来的问题是维护问题,系统中上万个表,基本上图形控制台是打不开,所以最好的方式是分表+分区,oracle专家也是这么建议的!
第二,簇索引我没有怎么用过,但是如果你经常3个组合查,就建复合索引,或者在类别上建建BITMAP索引,对x,y建复合索引,另外,我觉得呢,如果按我们现在开发系统的经验来说,你应该把类别做为分表,这样在类别上就不存在建立索引问题,而对x,y,按某种方式在表内进行分区

[flyycyu]

另外,如果可能的话,用BFILE,还 不如系统放在文件系统上,而数据库只做连接,当然这个看你,用jdbc插入当然会比直接拷贝文件系统慢.不过可能管理上带来方便性.另外io均衡问题你不用考虑,在建立数据库时候,这个表,或者是数据文件直接写文件系统的话,你把表空间或者文件系统挂在裸设备上,而不要用本地文件系统,系统会自动给你处理均衡问题的!

[flyycyu]

对，san,光纤网络，客户有钱，而且事情又重要。
装入数据的要求是我们数据是批量装入的，一年集中在1，2个时间点，平时就是查询，而装入数据时候，系统上会有几十个并发解析10万-30万之间的数据包。
至于BFILE问题，我只是建议，也可能是自己学艺不精，因为我的数据文件一般在10m以上，所以在上亿后，存库老是出些莫名其妙的问题，所以最后干脆就存外部文件，至少在过程上，你少了一道由web服务器把数据包发包到数据库服务器的过程。
还有io均衡这些问题，我觉得一是自己调很难，加大难度和时间，也未必出来后最优，还不如利用硬件设备，还有像10g里面的ASM。我们的数据量像上面所说，在ibm 570,8cpu,32g内存下，并发解析数据包到40，50都没问题，时间在50秒以内都能完成10万数据装入，而查询这些就更不用说了，压力测试上800都没问题，当然这是非集群环境，当然你的具体业务还是由你分析，这些只是建议

[flyycyu]

再说下io均衡问题，我只是说下实际部署中碰到的问题，因为这个只有具体问题具体分析，一个是磁盘的io,因为在设计TABLESPACE时候，你已经有意识的根据业务划分到不同的磁盘块上面了，我当时在测试上碰到的问题就是对回滚段的资源占用也很大，后来回滚的表空间分到5个磁盘上去了，性能马上就好了上来。
另外一个是网络io,我看你提的是网络io,而不是磁盘io，不清楚你的这个网络io指得是客户请求到web服务器，还是web服务器到数据库服务器！因为我们业务的关系，oracle没有架集群，当然也是还用不到那功能，所以没有参考意见，至于web请求这块，我觉得解决这个方案应该很多吧？比如我们，最后是按照业务模块来划分的多台web服务器.当然我们系统特定和你的可能有一定程度类似，就是大部分时间主要是查询。

[huylghost]

进来学习一下

[hrui99]

skystar99047(天星
分区数目可以考虑增大。
每个区的表空间可以考虑放在不同的物理空间上。
分区索引是必须的。如果增删改频率较低，查询较多，可以考虑位图索引。
如果图片保存在表中，需要考虑将该字段的存储放在另一单独的物理空间上。

同意上面描述。补充SELECT 描述考虑加入HINTS 描述
--并行处理
如：select /*+ parallel(tab,处理器个数） */

[runer]

不错