kakashi 積分 0

我也覺得應該是熟悉程度的問題,像是對岸的面試題,可以看到一堆 MySQL 分庫分表,但也許有些場景用 NoSQL/newSQL,甚至 graph database 都比較好解。

kakashi 積分 0

其實你量大,價錢什麼的都可以去吵 XD

IngramChen 積分 0

只要不是那三家,其他家價格都很正常的啦

kaif 積分 0

不過我們沒有做到 resharding 那麼高級,只能條新建立的 weight 而已 xd

kaif 積分 0

之前也在應用層做 sharding,為了相容原本用 JPA 的 code 只好做了 sharding 版本的 TransactionManager, EntityManager 什麼的

haocheng 積分 2

但這問題應該是每一家雲端服務平台都一樣吧?

kaif 積分 1 編輯於

想到以前無名時代都是說種花吸血,現在換成給外國人吸了 (然後再去買創新高的 AMZN (X))

j0n 積分 2

而且所有的流量、CPU使用時數全都是 AWS 說了算,你連吵都沒得吵,他說多少就多少

haocheng 積分 1

AWS 是很貴沒錯,不過也是因為疫情的關係 Zoom 流量暴增才會差這麼多吧,一個月的流量是 217,000 terabytes...

IngramChen 積分 1 編輯於

AWS 吸血吸的太過份了,連 AZ 間的流量都收高價 (跟跨 region 一樣的錢)

所以如果你 deploy k8s 在 AWS,預設的情況都是 cross-AZ,然後你還搞 micro service 的話,流量一大就會看到帳單出現以前從沒見過的收費 - 那些你在 service/pod 間的呼叫通通要錢

microservice 就是要吃大流量才想用的架構,但你一上雲端就是吃光你的錢。

koji 積分 0

最近看同事在碰resharding...在 RDBMS 又是應用層內部做的。 好想加加新機器就搞定~

kaif 積分 1

我覺得關鍵還是主事者熟悉哪一套技術吧,真的量大一定都還是要人下去 tune,就算用AWS黑科技 auroa/dynamodb一樣會爛。

例如之前 mongodb 很紅的時候很多人以為用了就無敵了,後來用下去也是該踩的雷都少不了 (雖然以這題來說感覺蠻適合的)

IngramChen 積分 0

olap 能處理大資料, 但不能處理大量 request

你貼的那個範例應該不可能放在 quora站上讓一般用戶即時查看吧

chao 積分 1

對,算是可以用於OLAP的DB,但同時也可以針對數十億、甚至上百億筆的資料去運算。

這是剛剛查詢一個大約千億筆資料的performance: 1. 單純count - 112.97 billion rows/s 2. 使用DATE做group by - 4.94 billion rows/s

IngramChen 積分 0

clickhouse 看起來是給分析用的啊

chao 積分 1

大table除了NoSQL,也可以考慮放到clickhouse,partition設計的好跟用MySQL幾乎一樣。

IngramChen 積分 1

為了 sharding 所以資料都不 join

跟裡面的留言一樣,我也覺得這些大 table 搬到 NoSQL 才是。但他們回 HBase 不太行。啊本來就不該用 HBase 吧,大概是不想再增加技術門檻了才不想換,從他們選擇自己做 shard 就知道 (NIH...)。

其實我還以為 quora 已經死掉了,你 google 去找根本很少是 quora 的文章說

IngramChen 積分 0

三大雲端廠商最常聽到主機不足的就是 Azure

IngramChen 積分 0

沒吧,這是兩年前的規定 (當時宣告免費)。

今年中會開收費

看英文比較準

haocheng 積分 0

漲價是這個?

注意事項:2017 年 11 月 28 日起,系統在計算 GKE 叢集管理費用時,已「不再」採用以「每個叢集每小時」為單位的「固定費率」計價方式 (不分叢集大小一律適用)。

IngramChen 積分 1

跟 AWS 一樣一個月一個 cluster 要 70美金左右, 只有第一個免費

還好沒轉到 GKE

IngramChen 積分 0 編輯於

nginx cert-manager 大概只要是 bare metal 都是這樣做,在自己的主機玩都這樣。

一開始我們先用 ALB,因為 ALB controller 雖然現在沒有可以共用 path rule,但其實已經做好了,等待 alpha 測試完畢就可以用了。結果沒想到一等就等半年 (作者太忙,他們都 AWS 的人)。所以現在卡的不上不下的,如果打掉重練的話可以重新考慮 nginx 的作法。

不過, NLB 進來的封包,會先經過 kube-proxy (iptables 吧?),再到 nginx pods,再到 app pods,一個封包在 nodes 間 bounce 兩次以上這種事我實在是受不了… 如果 node 是跨 Availability Zone 的話,每次 bounce AWS 都要收錢的

popcorny 積分 1

SSL Termination 可以用 cert-manager,用 let's encryption issuer1 其實挺無腦的。他好像沒有提到 ALB 比較貴的缺點,我怎麼看都覺得 NLB + nginx 比較好。話說我們用 GCP 也是用 L4 LB + nginx ingress 唷。