網站平台架構演變史（四） - 水平分割的查詢

標籤：排序   分布   問題   網站   前端   關心   使用者   條件   主鍵   

之前在講表拆分的時候氛圍垂直分割和水平分割

垂直分割的查詢其實不難，就是從單表變為了多表，而大部分情況下只是對主表的查詢多，從表的查詢會很少用到，這樣的情況下關聯查詢不需要太多的考慮

水平分割之前講了大資料量的情況下根據曆史時間來查詢，那麼今天來說另外一種，還有一隻是根據主鍵id模數後根據這樣的規則把資料均勻分布到不同的資料庫表中，一般可以以2、5、10來做，那麼分頁的時候怎麼做，使用者在查詢的時候是不知道你後台怎麼查的，他只關心資料的顯示，比如我分頁顯示10條，那麼在後台進去查詢的時候需要將"10/資料庫數量=實際對應每頁查詢數"，比如就用5好了，所有資料都是平均分布到5個不同的資料庫中，那麼10/5=2，分頁的時候需要對這5個資料庫查詢，那麼就是 ‘ limt row, 2 ‘，最後合并5次查詢的資料來反饋給最上層顯示。

這是即時的做法，如果不即時，採用緩衝或者搜尋引擎的時候，可以分別查詢一定的資料量來展示。舉個栗子，哪怕分頁有100多頁，一般使用者只看前10也，或者20頁的資料，那就用20頁，每頁顯示20條資料，20X20/5=80，那麼分別同步5個庫的80條資料，放入緩衝或者搜尋引擎中，來展示給使用者，這樣使用者在做查詢的時候就非常快，極少數情況下載20頁後的資料再去資料庫中查。

也許有人會問條件查詢、以及排序，如果直接查詢資料庫的話呢麼進行排序會比較難做，甚至不好做，而是用搜尋引擎就能很好的解決這個問題。

其實還有一點沒講，會再寫1-2篇來結束這次的架構內邀會的總結。近期實在很忙，手上兩個產品都要做，抽空總結，公眾號更新頻率下降了十分抱歉；其中一個產品預期7月底上線，期待與大家見面！

網站平台架構演變史（四） - 水平分割的查詢