关于大数据量的数据库设计问题

从全国的2万个网点汇总数据到中央数据库，每天数据总量大约100亿条左右，每调数据大约为2K。
数据库打算用oracle,要考虑到以后的报表和查询问题，数据库服务器如何设计，数据库如何设计，表如何设计，是要一个网点一个表设计比较好，还是每天一个表好？是否要用到RAC？请各位高手指点。

解决方案 »

  1.   


    用表分区啦！自己建立物理表，建立的时机怎么掌握？如果查询一个用户的半年流水账明细，程序还得拼接一大片一大片的sql 代码
    用一百多个表union all ，这个sql代码也太壮观了。
      

  2.   

    为什么要用oracle =、=
    不明白oracle在这里有什么优势~
    又贵又霸道的oracle为什么这么多人爱~
      

  3.   

    每天100亿，每条2K.。。这数据量够大
    重点先规划存储、容灾，再规划实现与设计
    如果有一个点设计不到位，后期将是灾难或大麻烦
    选ORACLE/DB2/SQL Server(至少2008版本以上)，都能完成需求，重点是正确设计和使用
    按每个网点还是天分表还是分区等也得按具体应用特点去设计，没法猜
      

  4.   

    用动态语句吧，每天建立一张表。这样虽然麻烦，但后期的维护等的效率都高。
    ==>
    如果用户查询半年或一年流水，那就要拼接sql语句了？
    用17楼的方法还行，
    个人没有具体处理这样大数据的经验，
    坐等大牛
      

  5.   


    不用oracle,你有什么别的建议吗？
      

  6.   

    从时间上计算：1000000万/2万=500000，每天每个网点50万数据,500000/12/3600=11.57，就算11吧，每个网点每秒钟产生11笔数据
    从空间上计算: 2K*100亿=20000000000K=20000000M=20000G=20T,每天20T数据
    这个数量级上应该不是数据库干的事情，这数据进了数据库就废了，你可以问问Google和Facebook,他们用的什么技术，Hadoop
      

  7.   

    -- 用Oracle 11.2.0.3 版本的 按天间隔分区 + 网点子分区加以解决
    -- Oracle 11.2.0.1 版本并行查询有问题，经常造成查询结果不正确。所以建议用Oracle 11.2.0.3 版本-- 类似建表示例如下：
     CREATE TABLE BIEE.DW_ADS_IMP_DAY_WQ
    (
    DATE_TIME GENERATED ALWAYS AS (TO_DATE(TO_CHAR("DATE_ID"),'YYYYMMDD')) VIRTUAL VISIBLE,
    DATE_ID NUMBER(8),
    SITE_ID number(1),
    CHANNEL_ID number(7),
    SUB_CHANNEL_ID number(7),
    PROVINCE_ID NUMBER(6),
    CITY_ID  number(6),
    TYPE_ID number(2),
    SLOT_ID number(4),
    CREATIVE_ID number,
    IMP number,
    CLICK number,
    IMPOVER number
    )
    PARTITION BY RANGE (date_time) INTERVAL(NUMTODSINTERVAL(1,'day'))
    STORE IN (adv_m01_tbs,adv_m02_tbs,adv_m03_tbs,adv_m04_tbs,adv_m05_tbs,adv_m06_tbs,adv_m07_tbs,adv_m08_tbs,adv_m09_tbs,adv_m10_tbs,adv_m11_tbs,adv_m12_tbs) 
    SUBPARTITION BY LIST (SLOT_ID)
      SUBPARTITION TEMPLATE
      ( 
      SUBPARTITION p_01 VALUES(-14,1,16,31,46,61,76,91,106,121,136,151,166,181,196,211,226,241,256,271,286,301,316,331,346,361,376,391,406,421,436,451,466,481,496,511,526,541,556,571,586,601,616,631,646,661,676,691,706,721,736,751,766,781,796,811,826,841,856,871,886,901,916,931,946,961,976,991,1006),
      SUBPARTITION p_02 VALUES(-13,2,17,32,47,62,77,92,107,122,137,152,167,182,197,212,227,242,257,272,287,302,317,332,347,362,377,392,407,422,437,452,467,482,497,512,527,542,557,572,587,602,617,632,647,662,677,692,707,722,737,752,767,782,797,812,827,842,857,872,887,902,917,932,947,962,977,992,1007),
      SUBPARTITION p_03 VALUES(-12,3,18,33,48,63,78,93,108,123,138,153,168,183,198,213,228,243,258,273,288,303,318,333,348,363,378,393,408,423,438,453,468,483,498,513,528,543,558,573,588,603,618,633,648,663,678,693,708,723,738,753,768,783,798,813,828,843,858,873,888,903,918,933,948,963,978,993,1008),
      SUBPARTITION p_04 VALUES(-11,4,19,34,49,64,79,94,109,124,139,154,169,184,199,214,229,244,259,274,289,304,319,334,349,364,379,394,409,424,439,454,469,484,499,514,529,544,559,574,589,604,619,634,649,664,679,694,709,724,739,754,769,784,799,814,829,844,859,874,889,904,919,934,949,964,979,994,1009),
      SUBPARTITION p_05 VALUES(-10,5,20,35,50,65,80,95,110,125,140,155,170,185,200,215,230,245,260,275,290,305,320,335,350,365,380,395,410,425,440,455,470,485,500,515,530,545,560,575,590,605,620,635,650,665,680,695,710,725,740,755,770,785,800,815,830,845,860,875,890,905,920,935,950,965,980,995,1010),
      SUBPARTITION p_06 VALUES(-9,6,21,36,51,66,81,96,111,126,141,156,171,186,201,216,231,246,261,276,291,306,321,336,351,366,381,396,411,426,441,456,471,486,501,516,531,546,561,576,591,606,621,636,651,666,681,696,711,726,741,756,771,786,801,816,831,846,861,876,891,906,921,936,951,966,981,996,1011),
      SUBPARTITION p_07 VALUES(-8,7,22,37,52,67,82,97,112,127,142,157,172,187,202,217,232,247,262,277,292,307,322,337,352,367,382,397,412,427,442,457,472,487,502,517,532,547,562,577,592,607,622,637,652,667,682,697,712,727,742,757,772,787,802,817,832,847,862,877,892,907,922,937,952,967,982,997,1012),
      SUBPARTITION p_08 VALUES(-7,8,23,38,53,68,83,98,113,128,143,158,173,188,203,218,233,248,263,278,293,308,323,338,353,368,383,398,413,428,443,458,473,488,503,518,533,548,563,578,593,608,623,638,653,668,683,698,713,728,743,758,773,788,803,818,833,848,863,878,893,908,923,938,953,968,983,998,1013),
      SUBPARTITION p_09 VALUES(-6,9,24,39,54,69,84,99,114,129,144,159,174,189,204,219,234,249,264,279,294,309,324,339,354,369,384,399,414,429,444,459,474,489,504,519,534,549,564,579,594,609,624,639,654,669,684,699,714,729,744,759,774,789,804,819,834,849,864,879,894,909,924,939,954,969,984,999,1014),
      SUBPARTITION p_10 VALUES(-5,10,25,40,55,70,85,100,115,130,145,160,175,190,205,220,235,250,265,280,295,310,325,340,355,370,385,400,415,430,445,460,475,490,505,520,535,550,565,580,595,610,625,640,655,670,685,700,715,730,745,760,775,790,805,820,835,850,865,880,895,910,925,940,955,970,985,1000,1015),
      SUBPARTITION p_11 VALUES(-4,11,26,41,56,71,86,101,116,131,146,161,176,191,206,221,236,251,266,281,296,311,326,341,356,371,386,401,416,431,446,461,476,491,506,521,536,551,566,581,596,611,626,641,656,671,686,701,716,731,746,761,776,791,806,821,836,851,866,881,896,911,926,941,956,971,986,1001,1016),
      SUBPARTITION p_12 VALUES(-3,12,27,42,57,72,87,102,117,132,147,162,177,192,207,222,237,252,267,282,297,312,327,342,357,372,387,402,417,432,447,462,477,492,507,522,537,552,567,582,597,612,627,642,657,672,687,702,717,732,747,762,777,792,807,822,837,852,867,882,897,912,927,942,957,972,987,1002,1017),
      SUBPARTITION p_13 VALUES(-2,13,28,43,58,73,88,103,118,133,148,163,178,193,208,223,238,253,268,283,298,313,328,343,358,373,388,403,418,433,448,463,478,493,508,523,538,553,568,583,598,613,628,643,658,673,688,703,718,733,748,763,778,793,808,823,838,853,868,883,898,913,928,943,958,973,988,1003,1018),
      SUBPARTITION p_14 VALUES(-1,14,29,44,59,74,89,104,119,134,149,164,179,194,209,224,239,254,269,284,299,314,329,344,359,374,389,404,419,434,449,464,479,494,509,524,539,554,569,584,599,614,629,644,659,674,689,704,719,734,749,764,779,794,809,824,839,854,869,884,899,914,929,944,959,974,989,1004,1019),
      SUBPARTITION p_15 VALUES(0,15,30,45,60,75,90,105,120,135,150,165,180,195,210,225,240,255,270,285,300,315,330,345,360,375,390,405,420,435,450,465,480,495,510,525,540,555,570,585,600,615,630,645,660,675,690,705,720,735,750,765,780,795,810,825,840,855,870,885,900,915,930,945,960,975,990,1005,1020)
      )
    (PARTITION P20120101_LS VALUES LESS THAN (TO_DATE('20120101','YYYYMMDD')) TABLESPACE adv_m10_tbs)
    compress;-- 上面date_time是虚拟字段，按这个虚拟字段分区，且按slot_id(广告位)list(当然也可以范围等)子分区。-- Oracle 11g 的间隔分区非常好用，建议多　熟悉一下！
      

  8.   

    -- 当然网点应该有个地区的吧，如果按网点所在地区子分区的话，每天生成的子分区可能会少很多，然后在“网点”字段上加个局部位图分区索引，当每天入库的时候可以将当天的位图分区索引置为“不可用”状态，入库完毕后，重新 rebuild当天的位图分区索引(记住：只是当天)
      

  9.   

    当然，这么大的量，至少得用2个节点的RAC，选取读取速度快的磁盘组作RAID（最多好组RAID）
    将这个表存放到多个表空间中，且不同的表空间应该放到不同的磁盘组，以减少争用，缓和IP瓶颈这是物理方面的设置问题了！
    最后可简单作一下预估：在最大并发的情况下，每小时能有多少数据的入库量。
      

  10.   

    这个说法 靠谱点。这可能多半不是数据库的事情了。多半在架构。我的想法：
    首先明确.数据什么特点？
      1.要求实时传输到总库吗？还是可以是异步？如果是实时的话，有突然数据暴增的情况吗？
      2.数据要求事务性吗？是0容忍错误，还是可以容忍一些不一致。
      3.有备，容灾要求吗？
      4.数据的访问大致会是个什么情况？并发大吗？回答上面的问题后
    其次首先要说的是。
     1.如果公司很有钱，领导也支持。那么建议买人家成熟的产品。从你问的方式来看基本可以确定你搞不定这个事情。而且也不是一个人能搞定的。 2.如果以行不通，那么自己搞得话 。这么大的数据自己去实现一套分布式系统太难。那么用市场上的数据库吧。
     如果有钱买oracle。没钱用mysql吧。采用分治的方法。把数据分到不同的库和机器上。因为数据的确太大。再要细说，得看业务需求，和数据的特点。
    ----羡慕楼主有机会做这么大数据的项目！
     
      

  11.   

    说个案例（某电网公司，貌似只有两个）：
    表分月份来建 如：tablename_YYYYMM, 然后再按网点所在地区分区。LZ公司还招人不？
      

  12.   

    就我的感觉，这数据，进了数据库，就是等于把数据库弄废了，
    你无法使用任何数据库基础平台的功能，比如事务，比如索引等等，
    google有bigTable方案，大的数据，怎么存储，我觉得应该按照他们的方式来。
    其实就是hadoop，以及其周边一系列的解决方案，简而言之就是noSql~
      

  13.   

    支持xming432提的问题，希望楼主能讲得再细些！
      

  14.   

    100亿/天 约为10万+/秒条记录，再*2k/条字节。这么多的数据，一台db服务器能吞下吗? 要是我做，得3-5台服务器，把各下级分片划分给某一台服务器灾备的话 这么大的数据量，用磁带吧。市场上有成熟的解决方案。至于查询，恕小弟能力有限了
      

  15.   

    如果楼主是BOC总行的，可以私信我一下，有点别的思路
      

  16.   

    从分布式上计算：每个站点每天的数据量1000000万/2万=500000*2K=1000000K=1000M=1G
    1，刻盘，每个站天每周刻一次盘，2张光盘最多1小时可以搞定，但是2万个站点4万张光盘你这总站需要雇佣多少人力来保证1周内全部入总库。就算15分钟搞定一张光盘，需要4*0.25小时=1万小时/(7*24)小时=60,分3班日夜不息的干需要180人*2000元/月，真是很烧钱呀。
    2，网络，申请1G独享带宽，带宽是按位计算的，换算到我们数据的单位就是1G/8=125M，125M*3600*24=10800000M=10800G，也就是说，即使申请1G带宽，24小时不间断传输，也只能满足1半站点汇总数据的要求。考虑到网络传输的稳定性，需要3-4G带宽来保证，真是很烧钱呀。
    兄弟努力吧，这个项目挑战性不亚于12306
      

  17.   

    可以用Hadoop,每天增量的数据打包成文件放到DFS上，跑MapReduce得到汇总的数据ETL导入到数据仓库，然后做分析。如果重头到尾都用关系型数据库解决问题的话成本太恐怖了，而且不一定能实现。
      

  18.   

    去了解下NoSQL方面的知识吧， 关系型数据库不适合做这种大数据
      

  19.   

    这个必须是用分布式存储，一个库肯定是抗不住的  我的想法是
    1：  先用hadoop的mapreduce机制 收集各个站点的数据   然后把数据存放到DFS  然后可以利用hbase或者是数据仓库存储  
    2：这种情况用关系型数据库会很头大的 哪怕你建立了更细粒度的分区 索引，同时后续的维护应该是比较困难的
    3：查询的时候只能是分布式的架构方式。
      

  20.   

    应该是做数据分析用的。必须建数据仓库、OLAP立方体，否则无论做报表还是查询，速度不能忍受。
      

  21.   

    如果时间同步，可以按数据时间上传到中央服务器，如果直接上传到中央服务器鸭梨大，那就中间再弄一个省会节点，一层一层的上传，可以入库，弄一个hadoop的平台，汇总处理生成报表
      

  22.   

    看来 就是做统计 或者分析用的。上mysql就可以 这位貌似说的差不多
      

  23.   

    可以按照 业务 分库 不同的库分到不同的机器上吧。
    然后你们既然压力不大 ，基本上是只要是取得数据就是。
    所以想法把查询拆掉成多条简单sql，千万别连表查就是，只要数据库不崩就是。
      

  24.   

    推荐使用淘宝海量数据库
    OceanBase
      

  25.   

    这么大的数据，传统的关系型数据库无法承受这个的，估计腾讯淘宝微博等一天也没有这么多吧，想建立个搜索引擎把？处理海量数据的公司比如百度google facebook 腾讯 新浪等都不是从现有的关系数据库产品寻找解决方案，因为这些产品不能符合需求， 比如 淘宝的 OceanBase， google 的有GFS。自己建一个吧。OceanBase 开源，github里面有。到淘宝挖个人试试，会省事省力省钱。
      

  26.   

    100E除以2W 得5 000 000 ,500W条啊 ，一条2K，5000*2=100000MB  10G数据啊 少年郎  你的比我这个大了整整20倍啊。
      

  27.   

    可以使用oracle bigdata机+exadata来解决
      

  28.   

    没有悬念，只能用NOSQL
    这个数据量级别，不用群集除非你数据塞进去就不用读取了
    关系型数据库到1000W保持一致性就会存在问题，
    linux+hadoop+hive吧
    估计要500-5000台以上服务器能达到业务需求当然若你就一个表大，数据一致性要求不高，没有大型报表需求
    可以做关系型数据，，，表拆成2W个这样一个表一天，10W，1个月300W，保持3个月数据在1000W以内，然后把表放在N各服务器里，需要哪个去哪个服务器。
    这样用关系型数据库都扛得下下来
    不过别想什么数据挖掘就是了
      

  29.   

    引用 52 楼 Yweige2010 的回复:引用 41 楼 han3zhu 的回复:成都的  顶一个!
     楼主做了这么久J2SE，可以学下Android。
     有C++基础   考虑弄下Cocos2dx
     
    嗯 现在在看android争取早日上手
     
    Android入门不是很难,你学习了好久了？
     可以来我们公司试试，在招Android
      

  30.   

    其实大数据量，大并发，需要考虑的太多：
    1、汇总到中央之后是否需要大查询。如果有需要可以设计对应的BI。
    2、各个分点的数据是否需要共享？
    3、中央的数据是否需要下放到地方？
    4、数据是否需要查询还是只存放即可？
    我们也遇到大数据量。不过也不算大。一天也就只一二百W级别的。我们用分布式处理。