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 唷。

IngramChen 積分 0

文中有寫到和 ALB 的優缺點,對我們而言比較重要的就是 ssl termination 了。NLB+nginx 的組合 ssl 就要自己管,有點麻煩

IngramChen 積分 0

node 現在有 managed node & fargate 可以用

兩者都不支援 spot instances, 然後 fargate 不支援 EBS,暈倒

ingress 的話,我目前是用 ALB + traefik ingress,其實還是可以用一台 ALB 搞定一卡車小站

哎,就是麻煩啊,k8s 的難度已經很高了,還要自己搞一套。而且我個人不喜歡 traffic 在 node 間 bounce。純 ALB 可以直通 pods,這算是 EKS 的優點。

cloudsql 聽到有 downtime 是一兩年前的事了,現在還會遇到嗎?拿麼恐怖

kakashi 積分 1

恩恩 感謝回覆我的問題!!! 不過我知道有些點有改善

  • master 要錢 <--- 真的貴
  • node 現在有 managed node & fargate 可以用 (心智成本又上升了)
  • GKE 其實到最後還是要熟 VPC 的部分,我們家有踩到一些雷,最後還是自己重切過
  • ingress 的話,我目前是用 ALB + traefik ingress,其實還是可以用一台 ALB 搞定一卡車小站
  • EC2 網卡這個我認同, 這個東西每次都要查一下,蠻麻煩的 Link1

GKE 我覺得很棒,但是 GCP 的問題一直都是其他 managed service 沒 AWS 多且穩定, 像是 cloudsql 會有 downtime 就抖抖的,這方面可能再跟大家請教下 XD

IngramChen 積分 0 編輯於

Google GKE 大概是做最好的吧,這也是去年 GCP 用戶上升的原因。

EKS 就是個拼裝車,把 AWS 現有的服務硬裝上 k8s,所以變成用戶除了使用 k8s 外,還要處理 AWS 本身的服務,以及橋接的部份。

  • EKS 的 master 要錢,mdfk
  • EKS 的 node 要自己安裝升級,還要一台台自己手動升,mdfk
  • EKS 還要先設好 VPC,VPC 除了設一堆 route table 外還要買固定 IP,然後超級難懂,mdfk
  • EKS 的 ingress 是不能共用 Load Balancer (ALB) 的,所以每個對外的網址都要開一台 LB,你開十個小站就要花十台 LB 的錢,mdfk
  • EKS node 延用 EC2 的網卡架構,舉例一台小 node 如果能配四張網卡,而一張網卡只能配四個 IP 的話,你一台 node 就只能裝 16 pods 左右,不論你 cpu/ram 還剩多少空間,mdfk
kakashi 積分 0

其實蠻想知道爛在哪 XD 有比 EKS 好的選擇嗎?求解

IngramChen 積分 1

我們用 AWS EKS,目前的更新計畫是 慢一版 (例如 EKS 升到 1.15 了,我們才會從 1.13 升到 1.14),週期大概是半年,更新的時候順便會一起升工具鍊 (helm 什麼的)

K8s 沒有 LTS 版,所以我傾向慢一版才更新 (等 bug 都抓完了),然後 EKS 又特別慢 ,官方已經 1.17 了,AWS 到現在 1.15 還沒生出來,所以大部份的情況我們團隊會慢 3~4 版左右。

雖然更新很慢但 k8s 到了 1.1x 版左右就很成熟了,目前沒什麼大問題。有問題的是 EKS。

===== EKS 爛到有剩 =====

j0n 積分 0

話說回來AWS有一堆複雜到不行的計價公式,而且基本上也是他說多少錢就多少錢

kaif 積分 1

其實大部分傳產都寧可要傳統的quota而不是pay as you go。這部分微軟就老經驗了

IngramChen 積分 0

笑一笑

不過 AWS 很複雜就是了, 即使我用了快十年還是很多東西不熟

j0n 積分 0

這個比例蠻威的,不知道是不是真的這麼強

IngramChen 積分 0 編輯於

重力子 這個名字有夠中二...

看到效能居然比 M5 還好,有點想試試 arm 的 openjdk..