Normally, a company may choose an API gateway or Nginx to mount multiple microservices, one for books, one for users, one for carts, etc. Or, they might wise up and use a monolith and put all 4 modules into one backend repository.

偷偷 diss 了一下 microservice XD

我就看過某家用 AWS Lambda 寫 API 的公司，有幾百個 Lambda 根本沒辦法維護...

aws lambda 拿來寫 app server 累死自己

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

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

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

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

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

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

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

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

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

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

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

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

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

你的說的沒錯 哈

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

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

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

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

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

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

clickhouse 看起來是給分析用的啊

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

為了 sharding 所以資料都不 join

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

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

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

想知道選擇 NodeBB 的原因

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

今年中會開收費

看英文比較準

漲價是這個?

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