6
MySQL sharding at Quora - Engineering at Quora - Quora (www.quora.com)
IngramChen 積分 1

為了 sharding 所以資料都不 join

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

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

kaif 積分 1

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

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

koji 積分 0

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

kaif 積分 0

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

kaif 積分 0

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

kakashi 積分 0

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

chao 積分 1

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

IngramChen 積分 0

clickhouse 看起來是給分析用的啊

chao 積分 1

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

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

IngramChen 積分 0

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

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

chao 積分 0

你的說的沒錯 哈