关于大数据量的数据库设计问题
从全国的2万个网点汇总数据到中央数据库，每天数据总量大约100亿条左右，每调数据大约为2K。
数据库打算用oracle,要考虑到以后的报表和查询问题，数据库服务器如何设计，数据库如何设计，表如何设计，是要一个网点一个表设计比较好，还是每天一个表好？是否要用到RAC？请各位高手指点。
[解决办法]
用动态语句吧，每天建立一张表。这样虽然麻烦，但后期的维护等的效率都高。
如果一个分区建立一张表，那么表只会的慢慢的增大。这对后期不利
[解决办法]
不导，直接用分区视图？
各个网点两份数据，做读写分离，一份供正常业务用，同步一份供中央服务器做分区视图用。各网点负责自己的数据安全。
若因为网点过多实现不方便，当然还可以再分解任务，网点汇总到市级，市级汇总到省级，中央服务器用分区视图关联省级。
[解决办法]
从时间上计算：1000000万/2万=500000，每天每个网点50万数据,500000/12/3600=11.57，就算11吧，每个网点每秒钟产生11笔数据
从空间上计算: 2K*100亿=20000000000K=20000000M=20000G=20T,每天20T数据
这个数量级上应该不是数据库干的事情，这数据进了数据库就废了，你可以问问Google和Facebook,他们用的什么技术，Hadoop
[解决办法]
-- 用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 的间隔分区非常好用，建议多 熟悉一下！
[解决办法]
这个说法 靠谱点。
这可能多半不是数据库的事情了。多半在架构。
我的想法：
首先明确.数据什么特点？
1.要求实时传输到总库吗？还是可以是异步？如果是实时的话，有突然数据暴增的情况吗？
2.数据要求事务性吗？是0容忍错误，还是可以容忍一些不一致。
3.有备，容灾要求吗？
4.数据的访问大致会是个什么情况？并发大吗？
回答上面的问题后
其次首先要说的是。
1.如果公司很有钱，领导也支持。那么建议买人家成熟的产品。从你问的方式来看基本可以确定你搞不定这个事情。而且也不是一个人能搞定的。
2.如果以行不通，那么自己搞得话 。这么大的数据自己去实现一套分布式系统太难。那么用市场上的数据库吧。
如果有钱买oracle。没钱用mysql吧。采用分治的方法。把数据分到不同的库和机器上。因为数据的确太大。再要细说，得看业务需求，和数据的特点。
----羡慕楼主有机会做这么大数据的项目！
[解决办法]
就我的感觉，这数据，进了数据库，就是等于把数据库弄废了，
你无法使用任何数据库基础平台的功能，比如事务，比如索引等等，
google有bigTable方案，大的数据，怎么存储，我觉得应该按照他们的方式来。
其实就是hadoop，以及其周边一系列的解决方案，简而言之就是noSql~
[解决办法]
这个必须是用分布式存储，一个库肯定是抗不住的 我的想法是
1： 先用hadoop的mapreduce机制 收集各个站点的数据 然后把数据存放到DFS 然后可以利用hbase或者是数据仓库存储
2：这种情况用关系型数据库会很头大的 哪怕你建立了更细粒度的分区 索引，同时后续的维护应该是比较困难的
3：查询的时候只能是分布式的架构方式。
[解决办法]
1.要求实时传输到总库吗？还是可以是异步？如果是实时的话，有突然数据暴增的情况吗？
不要求实时传输到总库，一两天能传过去就行。
2.数据要求事务性吗？是0容忍错误，还是可以容忍一些不一致。
数据不要求事务性，可以容忍一些不一致。
3.有备，容灾要求吗？
备份容灾都是要求的。
4.数据的访问大致会是个什么情况？并发大吗？
=============================================================================
第一点
数据分级存储，每个地方保留一份，上传一份，数据库只负责存，用另外的服务器抽插数据
第三点
备份感觉可以在分节点上备份，缓解压力
第四点
各级表的分区，要按需设计，在应用端判断根据需求，连接哪里的数据库。