討論區快速選單
知識庫快速選單
討論區最近新進100則主題 Salesforce打造企業目標 網路投保旅行平安險
[ 回上頁 ] [ 討論區發言規則 ]
19天一個table要十億筆的資料量,該如何設計?
更改我的閱讀文章字型大小
作者 : ywchung(ywchung)
[ 貼文 6 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/4 下午 06:10:50
各位高手,

小妹算是初學者, 但是確碰上龐大的資料量, select 總是 time out, 硬碟也不夠 = =||
高手教教我, 該如何處理, 謝謝~
作者 : pantc328(好說) C#優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 894 | 人氣 14154 | 評價 3400 | 評價/貼文 3.8 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/8 上午 11:59:58
19 天10億筆??
程式設計,資料庫設計...有非常多種設計樣式及演算法去解.
我只知道這個數量對我而言是非常大的值.
但我要知道這些資料的意義為何?才有辦法給予正確的解法.
10億筆.真的是10億筆嘛?沒辦法壓縮嘛?資訊系統真的要垃圾進垃圾出嗎?
有人會去看10億記錄嗎?
.....
.....

如果是科學運算.
進去時就算統計.保留結果值就好了.

如果做交易資料.
就將最近的保留.其他的轉至歷史資料庫.然後用其他的媒體備份就好了.
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 上午 09:19:44


   這種事我們以前就用MS SQL做過
    
   基本上你要動態分拆TABLE
 
 硬碟也不夠? 不可能 那麼龐大資料 當然也不可能是一般電腦能跑
 要有磁碟陣列SERVER
   準備用HP 4 CPU 以上的主機 每顆CPU配4G RAM
   就跑的起來∼
 
  
  
>各位高手,
>
>小妹算是初學者, 但是確碰上龐大的資料量, select 總是 time out, 硬碟也不夠 = =||
>高手教教我, 該如何處理, 謝謝~
作者 : chiuinan2(青衫)討論區板主 Visual C++ .NET卓越專家VC++一代宗師Visual Basic優秀好手資訊類作業求救卓越專家一般曠世奇才程式設計甘苦談優秀好手C++ Builder優秀好手上班族的哈拉園地優秀好手C++頂尖高手Assembly優秀好手貼文超過3000則人氣指數超過150000點
[ 貼文 3732 | 人氣 170106 | 評價 34520 | 評價/貼文 9.25 | 送出評價 125 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 上午 09:50:16
我一開始也比較認同[好說]講的, 為什麼19天會有10億筆? 這個量, 太不可思議了, 絕非正常的量.

就像以前遇到的不良設計, 十來萬個類別, 每天進上萬個新聞, 一年下來就幾百億個類別資訊. 但這些真的有必要嗎? 不能分開存嗎? 還是甘脆不用資料庫, 改用檔案來壓縮存放?

如果真的量很多, 大部份會採用分散式資料庫, 把量分散. 只是到目前為止, 量多到這種程度, 還真的沒看過. 以前接xx小站的案, 也不過幾億筆而已...
作者 : ywchung(ywchung)
[ 貼文 6 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 上午 10:20:28
大大~我們是放晶片的測試資料, 所以很多, 而且無法過月就壓縮, 因為使用者會看去年的資料~
作者 : jeff377(jeff377)
[ 貼文 10 | 人氣 108 | 評價 30 | 評價/貼文 3 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 上午 10:33:40
如果資料量成長那樣快,那就直接依資料日期切割資料庫及資料表儲存。
一個資料庫儲存一個月(或一季)的資料,一個資料表儲存每一日的資料,
你在下查詢語法時,就依查詢的日期區間,去相對應的資料庫及資料集
去取得相關資料作統計。
作者 : pantc328(好說) C#優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 894 | 人氣 14154 | 評價 3400 | 評價/貼文 3.8 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 上午 11:49:04
要怎麼修,怎麼設計?看需求.看分析.
這些資料對使用者的意義?
使用者怎麼去使用,查詢資料?
......
在去看資料庫怎麼設計.
資料表怎麼切割.
資料怎麼備份.

如建暫存資料表.
統計資料表.
歷史資料表...

資料型態.
結構,如檔案結構,半結構,關聯結構..

我想沒人會去看19億筆資料.
他們只會去看19億筆所產生他們要的結果.
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 01:49:24

>大大~我們是放晶片的測試資料, 所以很多, 而且無法過月就壓縮, 因為使用者會看去年的資料~

  你是那間公司
  你做的跟我做的系統很像
  都是要放所有的晶片 測試資料
  一片大概都有3萬顆 一天有500片產能
 一個月就嚇死你
  跑不動 哈哈
   我7年前就開發出來 
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 02:01:52


  他们不清處你做什麼系統
  我大概知道你做什麼東西
  你也是園區的喔

>大大~我們是放晶片的測試資料, 所以很多, 而且無法過月就壓縮, 因為使用者會看去年的資料~
作者 : ywchung(ywchung)
[ 貼文 6 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 02:30:35
呵~是呀~但因為我算是初學者~所以很困擾~
不知您是如何設計的呢?
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 02:34:12


  MSN: bmw5r1000@hotmail.com
  我擔心你跟我是同業∼
 
>呵~是呀~但因為我算是初學者~所以很困擾~
>不知您是如何設計的呢?
作者 : ywchung(ywchung)
[ 貼文 6 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 02:39:59
看你醬子寫, 應該是 = =||
作者 : ywchung(ywchung)
[ 貼文 6 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 02:45:07
看你醬子寫, 應該是 = =||
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 02:51:48

>看你醬子寫, 應該是 = =||

你會不會是 晶x 那一間

  要是的話 我5年前就有留一套在那理∼∼
作者 : ywchung(ywchung)
[ 貼文 6 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 03:01:44
不是~哈~~~
我不在園區內, 你大可安心~
我也不新竹~你更可放心~
如果您願意教, 我會好感謝.......................
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/2/9 下午 03:09:51
MSN: bmw5r1000@hotmail.com
機密很多
不能上面講
作者 : jasper_dale(Falcon)
[ 貼文 133 | 人氣 5599 | 評價 480 | 評價/貼文 3.61 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/27 上午 09:37:00
阿不就正規化、Index。
幹嘛搞得這麼神秘?
(阿討論區的精神是........不需要討論)
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/27 上午 10:56:47


   假如 正規化、Index 能解決的話
    那就太簡單 大家都會了
    就是有些 你不會的東西 書上也學不到 的
    菜鳥跟有經驗的差別 從這理就可以區分出來
    
    
作者 : terenas(風) 貼文超過200則
[ 貼文 490 | 人氣 7440 | 評價 680 | 評價/貼文 1.39 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/28 上午 09:30:31
基本上是腦子進水了, 才會想到使用Database 去接這麼大量的raw data, 重點是, 哪些raw data
會被重複select 的機會又很低, 頂多是做點統計, 這樣的系統, 會用DBMS 去存, 不是腦子進水是什麼呢.
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/28 上午 11:52:33


>會被重複select 的機會又很低, 頂多是做點統計, 這樣的系統, 會用DBMS 去存, 不是腦子進水是什麼呢.

   你答對一半 select 的機會 很低 概嘛 存入 DB 

 哈哈哈∼∼∼

  
作者 : terenas(風) 貼文超過200則
[ 貼文 490 | 人氣 7440 | 評價 680 | 評價/貼文 1.39 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/28 下午 10:24:20

>
>
>>會被重複select 的機會又很低, 頂多是做點統計, 這樣的系統, 會用DBMS 去存, 不是腦子進水是什麼呢.
>
> 你答對一半 select 的機會 很低 概嘛 存入 DB 
>
> 哈哈哈∼∼∼
存DB 是因為有重覆使用的需要, 不是當垃圾堆.
這種簡單的東西, 用filesystem 來存就好了.

作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/29 上午 09:46:57

  當 select 的機會很低 因素排除
   也就是說 select 的機會很高 時 光統計檔也不能滿足需求 資料量又是好幾億 時 而且一定要放入 DB 時
   那你怎麼辦?

  

   >
>>
>>
>>>會被重複select 的機會又很低, 頂多是做點統計, 這樣的系統, 會用DBMS 去存, 不是腦子進水是什麼呢.
>>
>> 你答對一半 select 的機會 很低 概嘛 存入 DB 
>>
>> 哈哈哈∼∼∼
>存DB 是因為有重覆使用的需要, 不是當垃圾堆.
>這種簡單的東西, 用filesystem 來存就好了.
>
>
作者 : terenas(風) 貼文超過200則
[ 貼文 490 | 人氣 7440 | 評價 680 | 評價/貼文 1.39 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/29 上午 10:40:02
> 當 select 的機會很低 因素排除
> 也就是說 select 的機會很高 時 光統計檔也不能滿足需求 資料量又是好幾億 時 而且一定要放入 DB 時
> 那你怎麼辦?
哇, 看不懂你在寫什麼呢, 一下低一下高?
一定要放入 DB?
select for what? 區間式? 需畏left join 的形式? 需要join 多個table?
如果不是滿足以上全部需求, 而資料量又特別大, 哪就根本不考慮使用database
作者 : nick64227(sososo)
[ 貼文 138 | 人氣 1246 | 評價 210 | 評價/貼文 1.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/29 下午 12:00:57

  select for what? 區間式? 需畏left join 的形式? 需要join 多個table?
  都不用考慮
   就是要全部資料放進db 的情況下
   你還是要去解決
   我只能告訴你 還是有辦法解決

    
    

   
  
  
    
>> 當 select 的機會很低 因素排除
>> 也就是說 select 的機會很高 時 光統計檔也不能滿足需求 資料量又是好幾億 時 而且一定要放入 DB 時
>> 那你怎麼辦?
>哇, 看不懂你在寫什麼呢, 一下低一下高?
>一定要放入 DB?
>select for what? 區間式? 需畏left join 的形式? 需要join 多個table?
>如果不是滿足以上全部需求, 而資料量又特別大, 哪就根本不考慮使用database
>
作者 : terenas(風) 貼文超過200則
[ 貼文 490 | 人氣 7440 | 評價 680 | 評價/貼文 1.39 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/30 上午 07:56:05

>
> select for what? 區間式? 需畏left join 的形式? 需要join 多個table?
> 都不用考慮
> 就是要全部資料放進db 的情況下
> 你還是要去解決
> 我只能告訴你 還是有辦法解決
就是要全部放入db 哪是你決定的, 跟我何關?
哪是你決定的方向的問題,十億筆data? 簡單啊, 花錢去了事, 1G memory 不夠, 買10G囉
1T 硬碟不夠, 買10T 囉, 1CPU 不夠, 買10 CPU 囉, 這種東, 硬要搞DB, 可以的啊. 硬體你付得起錢, 沒什麼不可以.
問題是人, 腦子只有DB 沒別種解決問題的辨法而已.
反正, "就是要全部資料放進db"嘛
我只提供一個簡單的概念, 沒有我提的需要的data, 不需要進入DB, DB 不是垃圾堆, 給你來堆垃圾.
要19 天才能產生十億筆資料, 真的要產生, 一天就上百億都沒問題, trash in-trash out 而已, 寫支小程式去產生trash 而已.
作者 : cherokeehung(Jeep)
[ 貼文 13 | 人氣 0 | 評價 40 | 評價/貼文 3.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/30 上午 09:07:57
我以前是做基因定序分析的
我用的是linux
根據以前的經驗是先將raw data以file system的方式儲存
先利用shell script處理再存入資料庫

若你的前提是一定要全放入資料庫的話
若select的機會很少, 我會建議不要建index, 不然在做insert, delete時因為要重建index會變得很慢
而且在做insert時, 可以的話使用insert append或bulk insert會讓效好一點

若要進行query的話,可先用store procedure處理暫存成temp table,再進行query
不要直接使用online query,不然你會發瘋...^_^

作者 : terenas(風) 貼文超過200則
[ 貼文 490 | 人氣 7440 | 評價 680 | 評價/貼文 1.39 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/6/30 下午 09:43:16

>我以前是做基因定序分析的
>我用的是linux
>根據以前的經驗是先將raw data以file system的方式儲存
>先利用shell script處理再存入資料庫
>
>若你的前提是一定要全放入資料庫的話
>若select的機會很少, 我會建議不要建index, 不然在做insert, delete時因為要重建index會變得很慢
>而且在做insert時, 可以的話使用insert append或bulk insert會讓效好一點
>
>若要進行query的話,可先用store procedure處理暫存成temp table,再進行query
>不要直接使用online query,不然你會發瘋...^_^
select for 區間式? 需要left join 的形式? 需要join 多個table?
沒有以上的條件而且很大量的資料, 不要腦殘到想放進DB, 而且還很豪爽的說, raid, RAM, CPU 的.
十億筆資料的sequential search, file system 比db 來得快.
作者 : chiuinan2(青衫)討論區板主 Visual C++ .NET卓越專家VC++一代宗師Visual Basic優秀好手資訊類作業求救卓越專家一般曠世奇才程式設計甘苦談優秀好手C++ Builder優秀好手上班族的哈拉園地優秀好手C++頂尖高手Assembly優秀好手貼文超過3000則人氣指數超過150000點
[ 貼文 3732 | 人氣 170106 | 評價 34520 | 評價/貼文 9.25 | 送出評價 125 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/7/1 上午 06:05:58
個人覺得, sososo既然敢講, 必定有他的解決之道, 但因為機密問題, 因此也不必多問 (雖然心中大概有個譜, 但沒確認, 因此也不知對不對).

如果是我的話, 我會偏向"風"提的, file system. 只不過必須好好分析資料的整個運用狀況, 新增/刪除/更新/讀取的機率各多高, 當然還包括資料內容是什麼型態, 才能決定如何去安排整個的檔案結構, 以及資料壓縮的方向. Database, 多是以通用處理為目的, 在巨量資料的存取效率上, 明顯會差很多.

如果不必跟外界競爭/評比, 我想, 還是應以sososo私下講的為是. 畢竟, 不同行業, 有不同的考量, 不能以自我想了就算. 隔行如隔山, 放諸皆然.

---- 分隔線 ----

資料量到一定程度後, 一定要壓縮. 因為disk的存取速度已完全跟不上cpu的處理速度. 雖然我目前還沒處理過十億筆以上的資料, 但億筆還是有的, 而且每個資料(或檔案), 幾百MB以上多的是. 大抵一個原則總沒錯: 減少disk access, 大多很容易就能提升效能. (但非絕對, 要在之中取得平衡, 那才是困難點, 不然每個人都變專家了... ^^)
作者 : terenas(風) 貼文超過200則
[ 貼文 490 | 人氣 7440 | 評價 680 | 評價/貼文 1.39 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/7/1 上午 08:34:33

>個人覺得, sososo既然敢講, 必定有他的解決之道, 但因為機密問題, 因此也不必多問 (雖然心中大概有個譜, 但沒確認, 因此也不知對不對).
>
>如果是我的話, 我會偏向'風'提的, file system. 只不過必須好好分析資料的整個運用狀況, 新增/刪除/更新/讀取的機率各多高, 當然還包括資料內容是什麼型態, 才能決定如何去安排整個的檔案結構, 以及資料壓縮的方向. Database, 多是以通用處理為目的, 在巨量資料的存取效率上, 明顯會差很多.
>
>如果不必跟外界競爭/評比, 我想, 還是應以sososo私下講的為是. 畢竟, 不同行業, 有不同的考量, 不能以自我想了就算. 隔行如隔山, 放諸皆然.
>
>---- 分隔線 ----
>
>資料量到一定程度後, 一定要壓縮. 因為disk的存取速度已完全跟不上cpu的處理速度. 雖然我目前還沒處理過十億筆以上的資料, 但億筆還是有的, 而且每個資料(或檔案), 幾百MB以上多的是. 大抵一個原則總沒錯: 減少disk access, 大多很容易就能提升效能. (但非絕對, 要在之中取得平衡, 那才是困難點, 不然每個人都變專家了... ^^)
>
我所接觸過的手機測試資料, 並無所胃新/改的問題, data-in data-out, one way iterative 就搞定所需要的報表了.
刪除的問題, 基本上也極少發生, 因為哪是測試的資料, 你測出來是怎樣就怎樣, 沒有什麼好刪的, 刪掉後可能讓統計結果失真.
很多人是盲目的使用database, 不管他是沒有filesystem 的經驗, 還是完全不會用filesystem來處理, 最後變成只能進database 這種妙論.
基本上, 簡單的計算, 19天10億筆, 約150 bytes 好了.
哪麼總共需要硬碟: 225000000000 bytes ~=209GB, Index 需要不算, 否則超過300GB 是很簡單的事. 哪麼要存多久的資料?
假設16GB全部給DB用, 則16GB 的memory 來當209GB 的資料Cache? 則1GB 的ram 要能map 到約13GB 的data.
不知各位有空可以試一下,寫支簡單的C 去讀取13GB 的data, 不用保留, 不用處理, 看需時多久. 就知道, 這種想法, 沒有on-line
的可行性. 試想同時有三四位user 就好了, 在查詢不同的資料.
照他字面上的講法不過是將209GB 散在各RAID HD 上, 採取raid 0 來加速, 以加速讀入的速度. partition table 的idea也沒多難.硬體撐場而已.
partition table 的概念 SQL server 篇
http://ithelp.ithome.com.tw/question/10028069
http://ithelp.ithome.com.tw/question/10028215
Oracle 篇
http://ithelp.ithome.com.tw/question/10031545
http://ithelp.ithome.com.tw/question/10031726
作者 : eliot(小台) VB.Net卓越專家SQL Server 7/2K卓越專家ASP.Net頂尖高手貼文超過2000則人氣指數超過10000點
[ 貼文 2213 | 人氣 28768 | 評價 9240 | 評價/貼文 4.18 | 送出評價 17 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/2/18 下午 04:57:56
好久沒上線了,原因不外乎是這邊已經越來越少可以挑戰或者學習的題材!
不過這篇問題燃起了我的興趣,可惜時間好久了,可能已經被改善

其實能解決的方法要配合資料的樣子...
最有機會解決的辦法就是將資料"分類"存入不同的Table
而且Table要依時間作Create,讓每個Table的資料量都不會太大!

但是如果使用者的查詢分析條件就是沒辦法先做出分類的(也不適合依時間切割)...
也就是必須去大海中撈針的...那就只能全部放到一個Table之中並且把條件資料加上Index了!
最後再把TimeOut放大!
(SQL Server 的查詢時間是可以無限大的,會發生TimeOut的原因是因為執行程式有幫Connection的執行Command時間設定Time Out)

如果可以"分類"的行為是可行的!
再依條件去把有機會查詢到的Table查詢一遍!
時效上會快很多...程式設計上則會複雜一些!!!
作者 : lionx(LionX)
[ 貼文 95 | 人氣 0 | 評價 270 | 評價/貼文 2.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/2/20 上午 04:44:38
怪了一秒6.700筆資料量的處理很困難嗎 ㄖㄖa
1000000000(10億)/19(天)/24(時)/60(分)/60(秒)=609.16
再來了當然拉 我比較建議也是filesystem
但如果一定要用DB的話
我會限制一個查詢間隔 意指當下能查詢的資料不會是立即資料
我想如果是測試的資料這樣應該是OK的
然後 測試資料大部分就是一直加入加入加入
這邊我不知道你們的加入是多工還是單工的加入?
所以預設A B C D E...資料庫
A負責資料的立即寫入 然後建立排程備份給定時間前的資料到BCDE...去
至於開的表分為 當下 之前 之後 3張表
資料寫入當下的表 排程將之前的表寫到其他資料庫內
然後刪除之前的表建立之後的表
這樣一來系統就會有間隔時間可以用來處理表的更換
噗 輕輕鬆鬆10秒內解決 哈~
怕有人看不懂 我帶參數說明好了
先做2之預存程序
1寫入紀錄用 將測試資料寫入 20110301XXXX的表內(其中XXXX為當日間隔片段)
2備份資料用 檢查是否存在當下時間片段前的表 存在就轉備份的BCDE..去然後建立下一個片段的表

每個時間片段為5分鐘(所以一天會有288個片段)
假設當下時間片段為0(當天剛開始)
預存1
檢查當下時間為第幾片段
使用上面結果寫入資料至當下時間片段表201103010000


預存2
檢查是否存在上一個片段表201102280288
存在
轉移備份至BCDE
成功備份
刪除201102280288表
不成功
......錯誤處理
建立201103010001表

然後1給測試紀錄使用 2給排程使用

至於我把建立下個時間片段表留給排程去建立
不讓1來檢查是否存在 不存在再建立
是因為1會被大量頻繁呼叫所以我去避免做過多的操作
而2因為只為再給定時間內跑一次所以讓它去負責建立
寫入者如果是多工你把檢查再建表放在1會更OOXX
最後查詢者只向BCDE來去做查詢就好
我想不會有人連5分鐘都等不起吧??
作著作業員看著辦公室那些工程師聊天打屁泡茶喝咖啡
我想5分鐘對她們來說應該是很可以接受的 = =
想想我一個月2萬8他們爽爽一個月4.5萬 我忌妒我羨幕阿~~!!
作者 : lionx(LionX)
[ 貼文 95 | 人氣 0 | 評價 270 | 評價/貼文 2.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/2/20 上午 05:02:22
在修正一下 如果不考慮維修變更的方便性
你還可以把計算寫入哪張測試表給放在寫入的那端機器算
這樣一來A資料庫就能更降低這部分效能損耗
不過當你要調整時間片段大小時... 呵呵....
然後剛剛算了一下5分鐘會有1.20萬筆資料
嫌多的改成1分鐘2分鐘都可以
最後 如果像我一樣很閒的 還可以做個中介伺服器
把寫入資料都傳到中介伺服器去
由中介伺服器來處理鎖的問題
這樣一來DB就不存在多工寫入時的鎖競爭
個人是認為程式內的鎖競爭比DB的還快
而且還可以緩衝短時間超大量寫入的問題
當然你也可以變更對資料庫的寫入為非阻塞方式 讓作業系統幫你緩衝
這個部分就見仁見智了
不過這種方法就又必須注意連線的問題
不過 我看工程師們都很閒應該是沒關係才對
我們一條線還只能有一兩個人同時離崗而已 唉....
作者 : jasperbf(jasperbg)
[ 貼文 3 | 人氣 286 | 評價 50 | 評價/貼文 16.67 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/4/14 下午 06:11:58
我設計過電信業的系統,直接跟你說,如果是資料庫的設計方式,你只有下面幾種選擇:

1. 找特別的資料庫,比方Sybase IQ或是Greenplum這種專門只跑分析的資料庫,然後把交易和分析給切開兩個資料庫 (我們就是這樣)
sql server只用來處理資料庫的交易,然後每一星期轉檔到 IQ 或 Greenplum上面,這種特別的資料庫雖然處理交易不行,但是跑查詢快到爆表,而且壓縮比超高,匯入資料速度快,只是要花錢....

2. Table Partition:把Data和Index依照範圍來切不同的地方,比方三個月內的資料放到p1,三個月到半三年的資料放到p2,超過的放到p3,加上適合的index,這樣子也許在where 某個時間區間的資料時,不用掃全部的device而是只看某一個partition,也許資料出的來,但是如果資料量太大還是有可能跑不出東西

3. table 切成 table001,到一個時間,切成table002,依此類推,然後建view,用union all的方式串起來,加上適合的index,但是如果資料量太大還是有可能跑不出東西

當初實際也有找過Oracle 這些原廠來看看怎麼做,但是後來發現只能用第一種方式(很特別的資料庫),因為連oracle在跑的時後切rac也輸給這種特別的資料庫,就放棄oracle的table re-design和tunning了。
作者 : jasperbf(jasperbg)
[ 貼文 3 | 人氣 286 | 評價 50 | 評價/貼文 16.67 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人ywchung註記此篇回應為很有道理 2011/4/14 下午 06:12:08
我設計過電信業的系統,直接跟你說,如果是資料庫的設計方式,你只有下面幾種選擇:

1. 找特別的資料庫,比方Sybase IQ或是Greenplum這種專門只跑分析的資料庫,然後把交易和分析給切開兩個資料庫 (我們就是這樣)
sql server只用來處理資料庫的交易,然後每一星期轉檔到 IQ 或 Greenplum上面,這種特別的資料庫雖然處理交易不行,但是跑查詢快到爆表,而且壓縮比超高,匯入資料速度快,只是要花錢....

2. Table Partition:把Data和Index依照範圍來切不同的地方,比方三個月內的資料放到p1,三個月到半三年的資料放到p2,超過的放到p3,加上適合的index,這樣子也許在where 某個時間區間的資料時,不用掃全部的device而是只看某一個partition,也許資料出的來,但是如果資料量太大還是有可能跑不出東西

3. table 切成 table001,到一個時間,切成table002,依此類推,然後建view,用union all的方式串起來,加上適合的index,但是如果資料量太大還是有可能跑不出東西

當初實際也有找過Oracle 這些原廠來看看怎麼做,但是後來發現只能用第一種方式(很特別的資料庫),因為連oracle在跑的時後切rac也輸給這種特別的資料庫,就放棄oracle的table re-design和tunning了。
 板主 : 徵求中
 > SQL Server 2005 - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - SQL Server 2005 - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
SQL Server 2005
1 小朱 380 
2 老芋仔 300 
3 狼鷹 150 
4 joe 100 
5 Aries 100 
6 100 
7 LionX 50 
8 50 
9 Peter.huang 50 
10 jonay 50 
SQL Server 2005
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2017 程式設計俱樂部 http://www.programmer-club.com.tw/
8.984375E-02