Re: [問卦] 簡訊實聯制資料龐大疫調緩慢根本騙人

看板Gossiping作者時間2年前 (2021/07/05 11:42), 2年前編輯推噓72(77推 5噓 114→)
留言196則, 90人參與, 2年前最新討論串7/10 (看更多)
cdc有沒有跟地方政府講過資訊龐大 調取很慢 如何應用在疫調上還要研議 有嘛 #1WuQ7-XX https://www.ptt.cc/bbs/Gossiping/M.1625399806.A.861.html 然後還有一堆護航仔護航1700萬筆很大 電腦跑不出來是哪招 連我跑了一百萬筆還是可以護航 我就不能因為隨身碟不足 切成22個縣市來做嘛 好吧那我再把隨身碟清出1G 隨機產出八百萬筆資料 接近1G https://imgur.com/TCJCoyn
https://imgur.com/uU0jaAT
我一天分成白天 晚上 兩個時段存成兩個table 這樣817可以不要再找理由了嘛? 明明就是很小的資料 我存成Access一樣搜尋匡列者 秒出 搜尋時間不到一秒 找到131位匡列者 https://imgur.com/rLscEP5
SQL指令跟上一篇文章一樣 只用了一個SELECT句子 連再匯入SQL Server都懶得匯 直接用最爛的Access解決
噓
07/04 02:11,
你把資料從100萬膨脹到1000萬就知道了
07/04 02:11
噓
07/04 05:48,
資料十倍速度不會只慢十倍，還好你不
07/04 05:48
→
,
是工程師 114.34.162.26 07/04 05:48
推
07/04 06:58,
你可以實作一千七百萬筆 索引要建立多久
07/04 06:58
噓
07/04 09:08,
你懂這個是N ^2的複雜度嗎
07/04 09:08
→
07/04 12:05,
一天1700萬，然後你只產生了100萬
07/04 12:05
→
07/04 12:08,
才100萬筆也好意思出來嘴
07/04 12:08
→
07/04 14:47,
然後要是要跟你要跨區資料就等著裝死
07/04 14:47
→
07/04 22:59,
你只有要求分忘記要求小時，還有十倍資
07/04 22:59
→
07/04 22:59,
料不等於只需要十倍時間，還要看記憶體
07/04 22:59
→
07/04 22:59,
會不會炸掉
07/04 22:59
好了可以下去領便當了 ※ 引述《wayne4321 ()》之銘言： : CDC說 簡訊實聯制資料龐大 疫調緩慢 如何應用還在研議 使用上有困難 : https://www.chinatimes.com/realtimenews/20210701001128-260407?chdtv : 真的是這樣嗎？ : 之前有鄉民算出 : 一天簡訊的量約1700萬則 : 只要存28天 超過的刪掉就好 : 就分28個表格存 : 我剛用我的2015年 Macbook pro做個試驗 : 因為我外接usb開機成window usb空間有限 裝了SQL Server後只剩幾GB : 所以簡化計算 : 我只隨機產出100萬筆資料 : 跟簡訊實聯制一樣 包含三個欄位 電話 商店代碼 時間 : 這樣的純文字檔資料不到100MB : 目標是找出確診者進入商店後 : 十分鐘內出現的人 把他匡列出來 : 不管用SQL Server或是最爛的Access : 查詢結果幾乎都是秒出 找出56位匡列者（我沒有濾掉確診者本身） : https://i.imgur.com/7t2Q2Hy.jpg
: https://i.imgur.com/c2vbQax.jpg
: SQL指令就那幾行 : 這麼簡單的工作也可以推諉卸責 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.169.22.247 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Gossiping/M.1625456554.A.CDD.html
→
07/05 11:42, 2年前 , 1F
源頭都民進黨放進來的 土裡長不出病毒啦
07/05 11:42, 1F
推
07/05 11:43, 2年前 , 2F
現在記憶體很便宜阿 隨便都64G
07/05 11:43, 2F
我用2015年的Macbook pro 記憶體16G 外插剩不到2G的空間的隨身碟開機跑匡列資料 會有這種北爛政府 都是這些愛護航的817寵出來的
→
07/05 11:43, 2年前 , 3F
唐鳳在想什ㄇ
07/05 11:43, 3F
→
07/05 11:43, 2年前 , 4F
最好裝不下啦
07/05 11:43, 4F
推
07/05 11:44, 2年前 , 5F
真的要作怎麼可能做不到
07/05 11:44, 5F
推
07/05 11:44, 2年前 , 6F
重點是金主沒有技術辦法接案
07/05 11:44, 6F
推
07/05 11:44, 2年前 , 7F
不管辣 id大臣說不行就是不行
07/05 11:44, 7F
→
07/05 11:45, 2年前 , 8F
重點是可以開八億預算啊
07/05 11:45, 8F
→
07/05 11:46, 2年前 , 9F
至於有沒有用，很重要嗎？
07/05 11:46, 9F
推
07/05 11:46, 2年前 , 10F
希望像你這樣的工程師越多越好:)
07/05 11:46, 10F
推
07/05 11:46, 2年前 , 11F
阿有人去把紙本key進去嗎
07/05 11:46, 11F
沒有吧 連這種簡單資料都在北爛了 誰會去key紙本
推
07/05 11:46, 2年前 , 12F
這其實不是很難的東西，唐鳳不知道在?
07/05 11:46, 12F
→
07/05 11:47, 2年前 , 13F
我想問題與其說在 SQL 不如說在整合
07/05 11:47, 13F
→
07/05 11:47, 2年前 , 14F
id大臣
07/05 11:47, 14F
→
07/05 11:47, 2年前 , 15F
很有道理 但可能有其他層面的問題 像是
07/05 11:47, 15F
→
07/05 11:47, 2年前 , 16F
我猜應該是沒人騎腳踏車去電信商要資料
07/05 11:47, 16F
→
07/05 11:48, 2年前 , 17F
法律部分 可以講解一下嗎
07/05 11:48, 17F
推
07/05 11:48, 2年前 , 18F
隨便一個線上購物網站資料庫都比他大吧
07/05 11:48, 18F
推
07/05 11:48, 2年前 , 19F
一看就知道在唬洨呀，金融單位每天交易
07/05 11:48, 19F
→
07/05 11:48, 2年前 , 20F
資料庫最少幾百萬筆，你看交割會跟你說
07/05 11:48, 20F
→
07/05 11:48, 2年前 , 21F
有什麼法律問題當初設計這個早就考慮
07/05 11:48, 21F
→
07/05 11:48, 2年前 , 22F
下個月再扣款嗎
07/05 11:48, 22F
→
07/05 11:49, 2年前 , 23F
簡單的說，金融出不來會被告到飛天
07/05 11:49, 23F
推
07/05 11:49, 2年前 , 24F
臉好響
07/05 11:49, 24F
→
07/05 11:49, 2年前 , 25F
但疫調，其實沒差 ... xD
07/05 11:49, 25F
還有 137 則推文
還有 21 段內文
→
07/05 17:18, 2年前 , 163F
用到唐大大，一般的人google一下也寫
07/05 17:18, 163F
→
07/05 17:18, 2年前 , 164F
得出來。我覺得在實際的案例中最常發
07/05 17:18, 164F
→
07/05 17:18, 2年前 , 165F
生就是欄位不一致，例如中華電信欄位a
07/05 17:18, 165F
→
07/05 17:18, 2年前 , 166F
，b，c是分開的，遠傳電信的欄位則是a
07/05 17:18, 166F
→
07/05 17:18, 2年前 , 167F
, bc，bc分割或是中華電信的b c何並是
07/05 17:18, 167F
→
07/05 17:18, 2年前 , 168F
不得不做的。還有資料重複在join上的
07/05 17:18, 168F
→
07/05 17:18, 2年前 , 169F
問題，當然可以join電話加上身份證，
07/05 17:18, 169F
→
07/05 17:18, 2年前 , 170F
但效能就會掉下來，而且debug也會變難
07/05 17:18, 170F
→
07/05 17:18, 2年前 , 171F
。
07/05 17:18, 171F
→
07/05 17:18, 2年前 , 172F
其次就是紙本資料，用OCR去跑嗎？手寫
07/05 17:18, 172F
→
07/05 17:19, 2年前 , 173F
的大概OCR也是陣亡。
07/05 17:19, 173F
→
07/05 17:19, 2年前 , 174F
雖然進度比預期來的慢，
07/05 17:19, 174F
→
07/05 17:19, 2年前 , 175F
但我覺得沒有想像的那麼單純，
07/05 17:19, 175F
紙本的不在討論範圍內 因為cdc在推卸責任的是 簡訊實聯制 紙本不是簡訊 各大電信公司的資料一定是正規化的資料 就三個欄位而已 司法機關調的通聯紀錄就是正規化的資料 所以這件事情就是這麼簡單 不要再幫cdc抹粉了
→
07/05 17:19, 2年前 , 176F
當然對外解釋就是說資料庫龐大，
07/05 17:19, 176F
→
07/05 17:19, 2年前 , 177F
但哪種龐大我們也不知道。也不可能想
07/05 17:19, 177F
→
07/05 17:19, 2年前 , 178F
研究所一樣報告目前碰到什麼問題吧。
07/05 17:19, 178F
→
07/05 17:19, 2年前 , 179F
或許政府可以拋出來目前碰到的問題，
07/05 17:19, 179F
→
07/05 17:19, 2年前 , 180F
例如欄位錯亂資料無法對齊，例如效能
07/05 17:19, 180F
→
07/05 17:19, 2年前 , 181F
的JOIN，GROUP BY優化等等，程式人很
07/05 17:19, 181F
→
07/05 17:19, 2年前 , 182F
多大家一起想辦法或許也不是壞事。
07/05 17:19, 182F
噓
07/05 17:27, 2年前 , 183F
你貼的CDC說資料庫龐大讀太慢沒反
07/05 17:27, 183F
→
07/05 17:27, 2年前 , 184F
應過 不就記者亂寫
07/05 17:27, 184F
不是記者吧 澎湖說有cdc有講 cdc說澎湖沒反應過 那cdc還是沒否認他有講過啊
推
07/05 17:51, 2年前 , 185F
我想瓶頸出在遠端的資料庫存取頻寬
07/05 17:51, 185F
→
07/05 17:52, 2年前 , 186F
不知道他怎麼去call的 也許有流程改善餘地
07/05 17:52, 186F
有八億能做成這樣推諉卸責 我也是醉了
推
07/05 19:48, 2年前 , 187F
幫高調
07/05 19:48, 187F
感謝內
→
07/06 05:14, 2年前 , 188F
就已經回沒有反應過了，還要否認沒有講過
07/06 05:14, 188F
→
07/06 05:14, 2年前 , 189F
？中時的報導沒出現名字整篇邏輯前後不
07/06 05:14, 189F
→
07/06 05:14, 2年前 , 190F
對，陳述的問題不一，結果鄉民只對著資
07/06 05:14, 190F
→
07/06 05:14, 2年前 , 191F
料龐大這點做文章。
07/06 05:14, 191F
→
07/06 05:15, 2年前 , 192F
自己都覺得資料量不是很大，現有技術足以
07/06 05:15, 192F
→
07/06 05:15, 2年前 , 193F
克服，卻又相信媒體資料過多難以使用的
07/06 05:15, 193F
→
07/06 05:16, 2年前 , 194F
報導
07/06 05:16, 194F
就不相信啊 沒看到cdc開記者會在那邊推託的嘴臉 人家問他 實聯制簡訊資訊量龐大，所以如何用在疫調上面尚在研議 cdc不敢正面回答 只敢扯簡訊實聯制只能當輔助 如果cdc沒跟縣市政府說過這些話的話 這是地方政府夢到的嗎？ cdc自己也承認 有部分的資料會調閱超過一天 很好笑內 我按顆鍵就能產出的資料 疫調是跟病毒賽跑的事情 疫調的前處理 調簡訊 花了八億 可以搞超過一天 這你也能護航的下去
推
07/06 08:05, 2年前 , 195F
RDBMS實作至少都是B tree複雜度是log(n
07/06 08:05, 195F
→
07/06 08:05, 2年前 , 196F
) 如果sql寫得隨便也是線性搜尋N而已
07/06 08:05, 196F
哥94專業 ※ 編輯: wayne4321 (118.166.44.5 臺灣), 07/06/2021 10:02:44
‣ 更多 wayne4321 的文章
文章代碼(AID): #1Wud-gpT (Gossiping)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 7 之 10 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共10篇)
‣ 更多 wayne4321 的文章
文章代碼(AID): #1Wud-gpT (Gossiping)