用 B-tree 可以解 high cardinality 的問題，現在流行的 prometheus & influxdb 用的演算法是 gorilla Link1 ，其實是可以把 time series 的資料壓縮到很小，B-tree 的話，我其實蠻想知道同樣的資料存進去會變多大XD

看他們的說明就是 partition 切很碎，每個很小速度就上來了

有點想不到用 B-tree 存 time series 有什麼好處...

只是 k8s 的日常…

這實在太銷魂了，而且 error messages 還看不出來。

現代化的 UI, 比 Discourse 簡單

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 看起來是給分析用的啊