頁:
[1]
大量資料查詢如何減低時間
本帖最後由 sigefred 於 2016-5-14 01:01 PM 編輯每個月有1千多萬筆 一年會有一億筆
問題一 在這大資料取出加總或區間如何減低查詢時間
做預存函式和切table和檔案嗎
問題二如果要取出一百萬筆或更多raw data有辦法減低查詢時間嗎
加index?<div></div> 本帖最後由 jt200809 於 2016-5-15 04:00 AM 編輯
有很多種方式 你要哪一種 ??
1.擴充硬體 ?
2.Database Tuning?
3.改寫應用程式 ?
另外 你資料是放在 一般關聯式資料庫 還是 Hive 這類的.....?? 本帖最後由 sigefred 於 2016-5-15 08:30 PM 編輯
擴充硬體 比較不可能
Database Tuning是要如何調校?
改寫應用程式不知要如何下手HIVE是?
資料就是很單純日期 機型 值 ,機型關聯到部門,因為要每分鐘存所以一個月會有1千萬筆
會存兩年歷史資料,重點在使用者想看任意區間時間又想在10秒內就看到資料,如果只有一個月資料查詢可以很快但如果時間一久資料越來越多在這麼多資料查詢一個月就會變久,又要看一整年的資料
...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 本帖最後由 chevylin0802 於 2016-5-15 08:42 PM 編輯
sigefred 發表於 2016-5-15 08:12 PM static/image/common/back.gif
擴充硬體 比較不可能
Database Tuning是要如何調校?
改寫應用程式不知要如何下手HIVE是?
這跟資料庫的設計相關連
甚至於可以根據某一個鍵值作為資料表的標頭
另外自動建立資料表與新增資料
好比以用戶編號作為鍵值的時候
也一樣可以用用戶編號作為新的資料表的標頭名再加上必要的字串
另外建立成一個資料表
再把原始資料表每日所新增的資料dump到各個編號資料表裏面
如此也一樣可以讓一份資料表的筆數縮減下來
就會有利於搜尋用途以及加總用途
比如許多電信業者的帳務系統
就會用內碼的編碼加固定字串作為資料表的建立的方式
至於如何從一個總資料表的資料分別dump到各個資料表
這並不難做
通常使用的是stored procedure
以每日定時時間去進行"過帳程序"
...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> sigefred 發表於 2016-5-15 08:12 PM static/image/common/back.gif
擴充硬體 比較不可能
Database Tuning是要如何調校?
改寫應用程式不知要如何下手HIVE是?
Apache Hive 是適用於 Hadoop 的資料倉儲系統，可透過 HiveQL (與 SQL 類似的查詢語言) 執行資料摘要、查詢以及資料分析。Hive 可以互動方式用於探索資料，或者建立可重複使用的批次處理工作。
以上 是從 Microsoft Azure 看到的關於 Hive 的簡單描述,看你在 C#那邊問人 就Google 一下微軟Azure的說法
在談到 Database Tuning 前,先說一下 請你想想你的作法是否合理 ?? 舉個例子 我們常用 Google 搜尋資料的時候,它會顯示第1頁 以及 "約有 92,700 項結果 (搜尋時間：0.75 秒)"這樣的訊息,你覺得 它是一次把 9萬多的結果 塞到 Client 端嗎 ?? 還是只是部份的結果 傳到 Client 端 ??
一般 Database Tuning 常見的 就資料庫主機的OS Tuning (一些作業系統參數調校...) 和 Database 本身的 比如 Share Memory 的增加,Database 使用 CPU 的數目增加.... 把需要效能存取的資料搬到較高速度的儲存設備......
你的資料 比較像是機器設備所產生的資料,Index 建 是一定要建 而且是以查詢的角度來建,再來切割 table 的問題,坦白說 你那單純的資料 查詢的區間 大概是落在 1~2年 不大可能連 5年以上的資料也要查,所以切割時 除了資料量大小 也得考慮資料的常用性.....
還有 別被 User 的說法拉著走 正常人不可能看得完 百萬筆的資料 上千都會有困難,更何況這種單純的資料.... 想想 Google 搜尋的作法...
至於 作統計分析的 不會直接從 Raw Data 下去撈,會對 Raw Data 先做一些加工 然後再拿 這些加過工的資料來做統計分析,這樣速度才會快.... 至於你要拉出Raw Data 來 那 加工後的Data 和 Raw Data 的 mapping 可能得做一下....
想想 你用一些 SQL 工具 執行 Select * from 某個 table ,你覺得 後端資料庫 是一次把整個 table 倒給你 ? 還是只有部分的資料先傳到你的 SQL 工具裡?
以上僅供參考~
補充內容 (2016-5-16 12:49 AM):
我沒有 運行在群集上資料庫的經驗 所以無法回答群集方面的問題
補充內容 (2016-5-16 02:32 AM):
看你用微軟平台 你就去研究一下 .Net 資料庫相關的資料 比如 ADO.NET,Entity Framework....
看看 返回的資料結果 怎麼操作 如何跟你的顯示控件做結合...
補充內容 (2016-5-16 02:37 AM):
讓 .Net本身提供的功能 自動運作管理 Client 和 Database 間的資料傳輸,除非是不符合你的需求 否則沒必要自己去寫這一段的程式...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div><br><br><br><br><br><div></div> 本帖最後由 kwj 於 2016-5-16 01:06 AM 編輯
sigefred 發表於 2016-5-15 08:12 PM static/image/common/back.gif
擴充硬體 比較不可能
Database Tuning是要如何調校?
改寫應用程式不知要如何下手HIVE是?
關於問題二～就算使用者要看一整年的資料，也不會真的一次倒一整年的給他吧
就算他真的拿到一整年的資料，也沒辦法一次看（上百萬筆資料擺在眼前，誰都不知道該怎麼看吧）
如果是要下載下來也就算了，如果是線上看的話，通常用分頁之類的方式就可以解決了
問題可以縮減成「在數千萬或數億筆資料中，幾秒內找出裡面的特定 N 筆資料」，N=50 之類的。
沒有那種神奇的方法可以在幾秒內取得幾百萬筆資料的～
就算資料庫本身可以透過分散式來達成，使用者端通常也沒辦法幾秒內把幾百萬筆資料一口氣下載完。
問題一....我個人是認為適度做一些預先算好的數字，可能會比較能夠達成有效率地加總。
例如某個加總的結果事先以一週為單位計算與儲存。
每分鐘新增資料時，都一併計算本週的加總，這樣一整年總共會有約 52 筆資料是以週為單位的統計資料
如果需要計算一整年，只需要把這 52 筆資料全數加起來就好～
而如果要取的是例如一年中的某 10 天的加總，則先取指定 10 天內包含的完整一週的統計值
再搜尋額外 3 天的數字加上去，就可以很快得到結果了～。
亦即，最糟糕的狀況，最多也就是 52 週加上 6 天，總共不到 60 個數字的加總。...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 了解那問題就只剩
在數千萬或數億筆資料中，幾秒內找出裡面的特定 N 筆資料 N=50
這個有可能嗎,有試過一旦筆數增加查詢特定N筆會增加查詢時間 sigefred 發表於 2016-5-16 08:20 PM static/image/common/back.gif
了解那問題就只剩
在數千萬或數億筆資料中，幾秒內找出裡面的特定 N 筆資料 N=50
這個有可能嗎,有試過一旦 ...
到現在的感覺 就是 你根本沒在真實的環境去試過,頂多只在 自己的環境試一些 然後其他用想像的
硬體不能擴充 Database Tuning 也有一定的極限,就算建 Index 也只是增加一點速度... 當這些手段都不能達到你想像認為該有的速度時 你該怎麼辦 ??
能做的 就回歸原始的根本 "薄點的書 總比 厚的書 翻得快" 就是 table 切割 你 table 變小 ;在台灣 軟體公司 一些資料庫設計上 都會有歷史檔案的概念在 , online 交易用的 table 盡量維持小 這樣在資料異動的時候 速度才會快
你不管資料的常用性 硬要從那麼大的table 去撈資料 越來越慢 也只是正常......
況且 數億筆的資料 放在一個 table 裡 這個 table 比較容易出問題 別相信廠商 宣稱的東西
別一切 只從技術的角度出發 人通常才是解決問題的關鍵 人的問題解決了 問題自然就迎刃而解...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 本帖最後由 kwj 於 2016-5-17 10:42 AM 編輯
在巨量資料的環境裡要維持 Table 存取的效率
若是資料庫有支援分散式的情況下，可以對 Table 做 sharding
資料庫沒有支援，則就如樓上大大所說，自己手動對 Table 資料做適當地切割。
但本質上，上面兩種其實是在做一樣的事情
差別只是是程式設計師告訴資料庫如何做 sharding，然後資料庫自動去做
還是使用者自己去做 sharding 而已。
PS. sharding 就是程式設計師指定某些欄位，告訴資料庫說要以這些欄位的值做資料切割
例如欄位值為 A、跟欄位值為 B 的資料，就會因此自動被分配在不同的資料庫主機上
以達成單一資料庫主機上的資料量維持在較小的程度
並且使用者在查詢資料時，能夠很平均地把查詢量分散給不同的主機。
不過這當然也代表了，程式設計師指定的 sharding key 如果太爛，效率也好不起來
因為資料庫是完全依照程式設計師的指示去做資料切割，所以切割基準設定地不好的話也沒救～。
所以最終程式設計師還是必須自己思考，自己的資料類型應該怎麼切割才是最好的。
最後還是要再強調一次，電腦跟程式一點都不神奇，沒有什麼魔術
不存在什麼神秘的力量，可以讓看起來明明就很慢的事情變得很快。
補充內容 (2016-5-18 10:52 AM):
其實應該寫「沒有什麼魔法」（There is no magic）。魔術實際上比較像是程式設計師在做的事情
補充內容 (2016-5-18 10:53 AM):
讓使用的人以為我們做了什麼神奇的事情，但其實這些神奇的事情，背後都是有系統地設計出來的。...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 感謝解答,對這問題有一些了解因為第一次接觸資料庫還不了解所以認為是不是有神奇的方法來解<br><br><br><br><br><div></div>
頁:
[1]