caterpillar 積分 0 編輯於

只能說自動模組是必要之惡吧!

這也說明了,在決定遷移至模組化之前,看看各程式庫官方是不是決定好(自動)模組名稱,可以免去後續的一些麻煩。

kaif 積分 0 編輯於

他建議現階段一般都先改MANIFEST.MF就好,不用先加module-info.java。測了一下這樣改必須把intellij (2017.3 EAP), maven compiler plugin (3.7.0)等等都升到最新版才會work。

kaif 積分 0

Do not release to Maven Central a modular jar file that depends on an automatic module, unless the automatic module has an "Automatic-Module-Name" MANIFEST.MF entry.

ksc91u 積分 0

我覺得上班時候跑,等他跑完下班。這樣比較好,要觀察有沒有跑到一半斷掉很辛苦的

chao 積分 0

匯出來用diff 會不會比較快?

popcorny 積分 0 編輯於

方法1: 直接在 DB query. 兩個大table內部就是用 sort merge join

方法2: 用 spark,開兩個 dataset,然後 join, 當然 spark 內部也是用類似 sort merge join。

方法2好處是直接可以輸出到文字檔,對 DB 的impact小。而且可以平行,除了stage 1因為拉資料可能只能有兩個task,stage 2可以 shuffle 到很多個partition 去做平行處理。

kaif 積分 0

幾億的資料不就下班下query明天來再收就好了嗎XD

natsu 積分 0

原來是 Berkeley DB ...

不過光是把 資料全部都撈回來 local 就要花掉不少時間了吧?(假設資料筆數很多的話)

natsu 積分 0
  1. 寫 procedure, 但是好像好麻煩

應該還是寫 procedure 效能會比較快吧...

Hibernate 在這方面好像就無能為力?

  1. 把資料全部都撈回來 local 跑, 用 DBD 之類的 key value db, key = 他要比對的欄位, value = 他要寫入的資料在檔案的位置(offset) 這樣應該就會快多了吧

請問 DBD 是什麼?

chchwy 積分 0

牽涉到Database所以就不能單純看時間複雜度啦。DB query過程中可能會存取硬碟,而存取硬碟的時間遠大於存取記憶體的時間,O()預測法八成會失準(因為常數太大)。

我自己猜測直接用 DB Query 會比較快,因為DB本身的資料結構通常都已經針對硬碟存取優化過了。

真的要硬做的話,直覺的作法就是先排序然後用二分搜尋法,看你的資料量有多「大」,能不能全部塞進記憶體裡面做。

ksc91u 積分 0

覺得有趣是, 首先把時間複雜度從 n^2 降到 n log n 然後又有人跟我講說query db 很耗時間。 所以想,

  1. 寫 procedure, 但是好像好麻煩
  2. 把資料全部都撈回來 local 跑, 用 DBD 之類的 key value db, key = 他要比對的欄位, value = 他要寫入的資料在檔案的位置(offset) 這樣應該就會快多了吧
fox 積分 0

現在的密碼 hash 前不是都要加 salt ,這種不加 salt 的單純密碼 hash 應該越來越沒有用處了吧。

alsuka 積分 2

真是不錯的分享。 個人認為,舉辦比賽的公司巧思在於,透過釋放部份資料,把原本自己公司想研究的東西包裝成比賽,只要獎賞夠吸引人,應該會有不少資料分析人才會提供不錯的演算方法 https://inclass.kaggle.com/c/kkbox-data-game-17-06

延伸閱讀, Kaggle 平台還不錯 https://www.inside.com.tw/2017/03/09/kaggle-joins-google-cloud

kaif 積分 2 編輯於

• 整篇就是解microservice架構帶來的各種雷

• 微服務通訊讓人類看得懂:從gRPC/protolbuf轉到json

• 避免microservice有"flapping"(時好時壞)的狀況:每個microservice做連線數限制限流、若有錯誤發生暫時隔離

• 各種監控

• Sizing

• 感覺這些內容要做過以後看才有fu

• 微服務太吃維運和持續的照料,傳統dev/ops分離,或是走瀑布流程出貨後就不管的組織運作,感覺不太適合

kaif 積分 0

作者寫一半就中離到airbnb了qq

kaif 積分 3
  1. filesystem對critical mission不是那麼可靠
  2. 如果application的資料有點重要,與其自己刻,不如寫到sqllite
  3. 讀出來做checksum應該是確認檔案寫入健康最簡單的方法
IngramChen 積分 0 編輯於

壓縮比高和解釋的容易理解

不過專門搞影像處理的人大概覺得沒什麼吧

IngramChen 積分 0

我想說怎麼會在 hacker news 這麼紅,一讀才知道,wow! it's magic!

kaif 積分 2

他的算法好像傾向選長文阿

koji 積分 0

me 2...等哪天會用到就會看懂了...XD

kaif 積分 1 編輯於

架構看來在處理數K小檔時, 相較於其他家latnecy會很有優勢