JWorld@TW
the best professional Java site in Taiwan
| 註冊 | 登入 | 全文檢索 | 排行榜 |
|
» JWorld@TW
» 交流、聊天、灌水
 列印話題
寄給朋友
|
   
|
| 本主題所含的標籤 |
| 作者 | eTag的省思 |
JacoLiao
 
發文: 0 
|
 於 2014-01-08 11:52
      
今天早上跟同事閒聊著最近鬧得沸沸揚揚的國道電子收費議題 新聞報導有些用路人都收到一些很離譜的收費明細 我同事就在說這應該是系統的問題 這就引發我的好奇上網查了一下 我有看到一篇報導說遠通電收一天處裡的資料量大約是1400萬筆 這麼大量的資料不知道他們的系統是怎麼配置的? 因為小弟沒接觸過這種大量資料傳輸的系統 所以想請問各位前輩如果遇到這種大型系統 在配置實體機器跟設計資料庫及系統時會採取的策略是什麼? |
| 作者 | Re:eTag的省思 [Re:JacoLiao] |
lnmlee
發文: 290
|
於 2014-01-08 15:23
先評估 資料量 更新頻率 以及 CPU的 負荷程度 一日 1400 萬 筆資料 平均每秒 有162筆資料 以尖峰時間估算是一般的 10倍好了 那就要測試 當 每秒有 2000 筆資料產生的時候 你要怎麼去怎麼做分散處理 例外處理 或其他意外處理 假設 DB 每筆資料存取要 0.05秒(以Mysql為例) 那 1秒頂多存取不到 20筆資料 所以尖峰時間肯定是 hold 不住 那就有必要 做到 資料庫的 分散存取 跟最後集中管理 這又是另一個專業領域 這必須找行家 或是在前端就作資料初步簡化處理 不然也可以開大絕 買高檔硬體設備 加記憶體 加CPU 任它操 (提高國家預算....) 我看你腦袋驚奇 充滿創意 是萬中無一的程式奇才 我看與你有緣 這本基礎Java程式語言 就送給你了 |
| 作者 | Re:eTag的省思 [Re:JacoLiao] |
fjj
發文: 127
|
於 2014-01-08 16:07
這的確是個有趣的問題！ 但我相信eTag絕對不是唯一一個會處理到類似問題的， 而且eTag也絕對不會是第一個遇到的，我相信以前一定也有類似的情境。 舉個例子，例如：中華電信的市話通話記錄與收費系統。 我想人類具有高等智慧，許多的經驗可以傳承與類比。 這些重要的經驗正是人類賴以發展的無價之寶。 |
| 作者 | Re:eTag的省思 [Re:JacoLiao] |
javaX
發文: 188
|
於 2014-01-08 16:12
我覺得先改成固定收費或停掉再討論系統問題，不然被內外夾攻不死也傷。 教育部：要如何保證畢業即就業 經濟部：所以公司都是我開的 財政部：發前單位請不要幻想能春風化雨 行政院：為什麼該單位發錢的時候都想去當老師 |
| 作者 | Re:eTag的省思 [Re:JacoLiao] |
|
fjj
發文: 127
|
於 2014-01-16 08:50
今天後續的新聞顯示eTag更扯了！ 政院踢爆 全因APP設計不良 eTag遭駭 攏係假http://tw.news.yahoo.com/%E6%94%BF%E9%99%A2%E8%B8%A2%E7%88%86-%E5%85%A8%E5%9B%A0app%E8%A8%AD%E8%A8%88%E4%B8%  %E8%89%AF-etag%E9%81%AD%E9%A7%AD-%E6%94%8F%E4%BF%82%E5%81%87-213000854.html我實在真的不懂耶！ 難道遠東集團的工程師、資深工程師、總工程師、工程總監、技術顧問、技術總監... 這麼多人難道都沒人有過大型系統的工作經驗？ 難道這些人在系統上線前都不用經過｢系統壓力測試｣？！ 再者，難道eTag沒有分散式系統或是Loading Balance的設計？！ 我真的覺得太誇張！ 我更不懂的是技術總監或是總工程師怎麼能夠置身事外，好像系統設計沒有問題似的！ 
|
| 作者 | Re:eTag的省思 [Re:fjj] |
qrtt1
發文: 1755
|
於 2014-01-16 09:51
fjj wrote: 有 loading balance 也要整體戰力可以吃得下全部的 loading， 像跨年時，北捷如果不分散退場還是會 GG 的。 蝸牛角上爭何事？石火光中寄此身，隨富隨貧且歡樂，不開口笑是癡人。 my notes |
| 作者 | Re:eTag的省思 [Re:fjj] |
jimwayne
發文: 220
|
於 2014-01-16 10:12
fjj wrote: 根據之前網友爆料的內容，遠通是有用 load balancer，也有做分散式系統 只不過分散式是只有兩台 Windows IIS，load balancer 是一台老舊的伺服器～。 在台灣應該有不少這類型的問題，因為聘請工程師時，無經驗或經驗不足的工程師薪水比較低 很多企業其實一向認為三個臭皮匠可以勝過一個諸葛亮，請 5 個 22k 的無經驗工程師，會比請 1 個 200k 的老經驗工程師還有效果。 其次另一個問題是台灣的工程師們多半不傾向一輩子做開發，大多數人做開發做個十幾年就會開始轉管理職了 當然這是個大哉問，本來也不就是每個人都有辦法一輩子做開發，但台灣轉管理職的傾向遠比國外高很多 所以真正在這行做很久、很有經驗的工程師，數量並沒有想像中的那麼多 反過來說就是，企業往往能找到的工程師，多半都不是那麼有經驗的人～ 而老經驗卻轉管理職的高階技術主管，其實多半也沒時間管這麼細節的問題 比如說他們應該只會關注 Android App 開發進度如何，但不會在乎 Android App 的首頁操作失敗時要做什麼的這種細節 所以只要開發的工程師不說，整間公司大概就沒人知道了吧。 真正的問題的確就是沒做壓力測試就上線給上百萬的使用者使用～ 但我個人猜測是......既然會找這麼沒經驗又隨便的工程師來開發這個東西，大概也很難保證開發進度會很順利吧 有可能是開發進度 delay 了，但已經到了合約約定一定要上線的時間，所以就不管三七二十一先拿去交件了...。 我個人是覺得遠通的行為，應該蠻容易發生在台灣各種軟體開發公司 企業文化本身不在乎工程師的資質、經驗，也不那麼在乎開發出來的程式碼品質、系統效能時 做出來的東西就是那種吹彈可破的程度。 |
| 作者 | Re:eTag的省思 [Re:JacoLiao] |
|
mmolis
發文: 127
|
於 2014-01-16 11:17
事實上, 一天 1400 萬筆是平均值, 高峰值為 3000 萬筆, 一個月平均是 6 億筆 |
| 作者 | Re:eTag的省思 [Re:jimwayne] |
030251888
發文: 140
|
於 2014-01-17 01:23
雖然我不是很專業。不好意思發表言論 但我覺得這樣的系統有點誇張欸 努力尚未成功，松鼠扔須努力 |
| 作者 | Re:eTag的省思 [Re:mmolis] |
|
fjj
發文: 127
|
於 2014-01-17 08:05
mmolis wrote: 您這邊提到的數據量應該指的是 高速公路的車輛通行量， 而App爆發無法連結，甚至是遠通荒謬的說是被駭客攻擊， 這些都和您上述所提到的車輛通行量並沒有直接的關係。 手機App查詢的程式顯然有非常大的問題。 ( 可是單就這一部分，到目前為止遠通並沒有針對App事件公開說明，App事件為何說是被駭客攻擊的原委。 ) |
| 作者 | Re:eTag的省思 [Re:JacoLiao] |
|
LiaoLuke
發文: 106
|
於 2014-01-17 11:31
JacoLiao wrote: mmolis wrote: 他們可以去請教，台北捷運，如何運行的就好了， "一天 1400 萬筆是平均值"，應該比不上，捷運的上班尖峰時刻。 
|
| 作者 | Re:eTag的省思 [Re:lnmlee] |
|
plutotw
井底蛙
發文: 624
|
於 2014-01-17 11:39
不能這樣算.. 全部把所有的東西全塞進DB, 這是完全沒作好分析的動作 簡單的說,就算每日 4200 萬筆資料 實際上只有約 700萬台車,將每一筆資料丟到這700萬台車的獨立 DB (或檔案格式或 MDB ) 即可,效能及速度都可以達到 那每一台車的資料有多少 ? 以一台每天全台跑透2次一年是 319*2*2 *365= 46.6萬筆(實際上這已高估很多,而且比例很少) 如果將這 700萬台車 * 加每1筆的資料 都塞進同一個 DB ,當然很慢 4200萬筆資料來源如下 1.交通部運研所 : 歷年春節運量運能趨勢100年春節疏運政策檢討分析 每日通過收費站交通量(車輛數) 高速公路收費站共計23個 日平均最高240萬車次(97年)比最低218萬車次(98年)多10%，而日最大302萬車次(98年)比最低276.5萬車次(97年)則多9.2%。 2.319座計程收費感應門架 3. 302萬量/23 * 319 = 4188 萬 任何聰明的傻瓜都可以讓事情更大、更複雜、更激烈。要往反方向發展需要一絲天分以及許多勇氣。－愛因斯坦 |
| 作者 | Re:eTag的省思 [Re:LiaoLuke] |
|
mmolis
發文: 127
|
於 2014-01-18 00:20
LiaoLuke wrote: 是呀 |
| 作者 | Re:eTag的省思 [Re:plutotw] |
|
jimwayne
發文: 220
|
於 2014-01-18 03:25
plutotw wrote: 個人倒是覺得.....700 萬台車各自有獨立 DB 的話，造成的管理上的麻煩應該遠比效能提昇的優點大得多 就算把 700 萬台車的資料全放在同一個 DB，也不見得會真的很慢 如果考慮資料庫是分散式系統的話，實際上可以依據車牌或者某些特徵，將 700 萬台車分成 N 個群組 各自塞到 N 台資料庫上，每台資料庫平均來說是存放 (700 萬/N) 台車的資料，其中 N 可以視情況增加或減少 這樣也許效能比不上 700 萬台車各自有獨立 DB，但針對包括資料備援、程式化的系統操作等等都會有不少幫助，而效能差距也不致於太大。 |
| 作者 | Re:eTag的省思 [Re:jimwayne] |
|
plutotw
井底蛙
發文: 624
|
於 2014-01-18 08:12
jimwayne wrote: 你有沒有算過筆數,其資料量,加上 index 的容量 ? 有沒有實際去建這麼大的 DB 筆數,其 access 實際反應 ? 當資料是以億筆以上為基本單位時,分散是最佳的 但要分散,就分散到最底 , 為什麼分散到 台,因為可以不需用 車號建 index ,這 index 的量是很大的 , 甚至於如此可以不用建 index 也許初看 700 萬的檔案很多,實際上我都試過,同時放幾千萬的檔案在 PC 上,效能很好 缺點是備份真的麻煩,但也只是觀念與原本備份 單一 DB 的不同而已 任何聰明的傻瓜都可以讓事情更大、更複雜、更激烈。要往反方向發展需要一絲天分以及許多勇氣。－愛因斯坦 |
| 作者 | Re:eTag的省思 [Re:LiaoLuke] |
|
plutotw
井底蛙
發文: 624
|
於 2014-01-18 20:42
LiaoLuke wrote: http://web.trtc.com.tw/RidershipCounts/c/10212.htm 平均是每日 200 萬 也不會去想想 台北市設籍人口 270萬,就算有人估上班人口約 800 萬, 但這 800 萬數值是否正確(全台的 1/3 人口在台北市) ,哪知 ?? 會不會作這樣的分析,都是要作分析設計時最基本的條件 任何聰明的傻瓜都可以讓事情更大、更複雜、更激烈。要往反方向發展需要一絲天分以及許多勇氣。－愛因斯坦 |
| 作者 | Re:eTag的省思 [Re:plutotw] |
jini
SoftLeader Taiwan 版主 
發文: 1266
|
於 2014-01-20 09:21
plutotw wrote: 如果我設計的資料結構, 也會以車號為單位為 File or Table or DB. 在通過 etc gateway 所回傳的 records 是紀錄在各自的車號檔案之中, 另外, 尚未判讀或判讀有異常的則放在 warning check area. 這部分需要人工比對和檢核的. 之前出最多問題的並非 etc 紀錄的問題, 主要是官網 and app 查詢面出了問題吧 ?! Anyway, 這是一個交易系統, 千萬別以 facebook 類型的 bigdata 來比較. 以交易量來看, 這已經是大系統了. 感覺核心段沒有太大問題, 很多細節與檢核規則需要趕快補上, 總之, 驗收的人能力不足才是重點 ! |
| 作者 | Re:eTag的省思 [Re:jimwayne] |
|
jini
SoftLeader Taiwan 版主
發文: 1266
|
於 2014-01-20 09:24
jimwayne wrote: 這樣的系統真的能夠用兩台 IIS, 一台老舊的 load balancer 搞定, 這樣等級工程師所做出的程式效能不是非常高嗎 ? |
| 作者 | Re:eTag的省思 [Re:JacoLiao] |
|
javaX
發文: 188
|
於 2014-01-20 09:43
Etag 用微波會不會把大家都煮熟了? 教育部：要如何保證畢業即就業 經濟部：所以公司都是我開的 財政部：發前單位請不要幻想能春風化雨 行政院：為什麼該單位發錢的時候都想去當老師 |
| 作者 | Re:eTag的省思 [Re:plutotw] |
|
jimwayne
發文: 220
|
於 2014-01-20 10:19
plutotw wrote: 建一個 DB，但資料要怎麼放在裡面是可以有很多種選擇的.... 一個 DB 但有 700 萬張 table，效果實際上跟 700 萬個檔案差不了太多吧 而在分散式的環境中，DB 依據 table 去做資料分散，在實際的開發上會比把資料全部放成檔案來的容易 因為資料分散的工作可以交給 DB 的實作，不需要自行實作 load balancer 跟資料分散的細節 也許初看 700 萬的檔案很多,實際上我都試過,同時放幾千萬的檔案在 PC 上,效能很好 整串看下來應該沒有人質疑 700 萬個檔案的效能會很不好吧？ 我個人也同意放成檔案的效能應該會最好～上面講到的主要只有管理/維護上的議題而已。 |
| 作者 | Re:eTag的省思 [Re:jimwayne] |
|
plutotw
井底蛙
發文: 624
|
於 2014-01-20 10:29
jimwayne wrote: 靠 DB 去建 700萬個 table 應該會失敗，您可以試看看. 不是很多東西都適合放 DB, 不過放 DB 是可以省很多細節，但這是一般的系統 + 一般的人使用的方向 真的試過在 檔案系統內塞幾千萬個檔案的人不多 任何聰明的傻瓜都可以讓事情更大、更複雜、更激烈。要往反方向發展需要一絲天分以及許多勇氣。－愛因斯坦 |
| 作者 | Re:eTag的省思 [Re:jini] |
|
plutotw
井底蛙
發文: 624
|
於 2014-01-20 10:33
jini wrote: 根據他處的討論，是連紀錄都有問題，才會造成扣款錯誤 另一個我覺得最扯的是，報表竟然是通過那一支門架，收多少錢 ? 而不是依據門架，判斷出上下的交流道，及其里程數 (並列出偵測到的門架）.... - 這些人腦袋到底在想什麼? 任何聰明的傻瓜都可以讓事情更大、更複雜、更激烈。要往反方向發展需要一絲天分以及許多勇氣。－愛因斯坦 |
| 作者 | Re:eTag的省思 [Re:plutotw] |
|
jimwayne
發文: 220
|
於 2014-01-20 10:58
plutotw wrote: 700 萬是真的沒試過，不過之前有試過好像 100 萬還是 200 萬吧～ 如果資料庫類型不限定在 SQL 的話（允許使用 NoSQL），這些限制應該是很少的～ PS. 如果是 MySQL 之類的，個人感覺上也會覺得建個上百萬的 table 好像會有問題..... 同意有些實作靠自己依據自己的需求去特製，會有最好的效果 但也不是一般人的用法就是不好的用法，畢竟已經經過眾多的使用、修正的系統是有一定程度的可靠性和效能 實際要做哪種選項，應該是要花一些時間實際做簡易的運作測試來衡量 而不是說一般人都這麼做，這個作法就比較差。 這裡只是討論各種的可能性，實際上大家都沒真的去照這個情境跑過 所以也不用很嚴峻地去批判某個作法的好壞，單純就想像得到的部分討論一下即可。 plutotw wrote: 最初剛聽到計程收費時，原本以為會在每個交流道上都放感應器或攝影機 偵測/分析每輛車上國道、離開國道的位置 結果後來看報導說用門架來判斷....... 判斷的基準還真是不嚴謹呀........ 個人覺得這怎麼很像是大學生的畢業專題成果 Orz |
| 作者 | Re:eTag的省思 [Re:jimwayne] |
|
plutotw
井底蛙
發文: 624
|
於 2014-01-20 11:41
jimwayne wrote: 如果100~200萬的 table,建的起來，存取又沒被拖垮，建 connect 又很快 那應該 700 萬 table 是沒問題的 .. 因為很多是理論上沒限制，實際上就慢 本來就是要看案例決定方向的，什麼樣的案子適合什麼樣的架構 尤其是遇特殊的系統，自然就要跳脫瓶頸 門架裝在中間是 ok的，可以少掉一些問題，但是報表無法貼近使用者的認知，就是失敗的 任何聰明的傻瓜都可以讓事情更大、更複雜、更激烈。要往反方向發展需要一絲天分以及許多勇氣。－愛因斯坦 |
| 作者 | Re:eTag的省思 [Re:jimwayne] |
|
tropical
發文: 2
|
於 2014-01-22 17:50
這比較像是採用的研究方法的限制, 不過看來也沒有再去"除錯"以作為精準度校正的輔助措施, 這樣的架構下就很難不給人粗糙的感覺 jimwayne wrote: |
| » JWorld@TW » 交流、聊天、灌水 |
|
|
已讀文章 新的文章 被刪除的文章 |
