㈠ 如何利用索引提高sqlServer數據處理的效率
在良好的資料庫設計基礎上，能有效地使用索引是SQL Server取得高性能的基礎，SQL Server採用基於代價的優化模型，它對每一個提交的有關表的查詢，決定是否使用索引或用哪一個索引。因為查詢執行的大部分開銷是磁碟I/O，使用索引提高性能的一個主要目標是避免全表掃描，因為全表掃描需要從磁碟上讀表的每一個數據頁，如果有索引指向數據值，則查詢只需讀幾次磁碟就可以了。
所以如果建立了合理的索引，優化器就能利用索引加速數據的查詢過程。但是，索引並不總是提高系統的性能，在增、刪、改操作中索引的存在會增加一定的工作量，因此，在適當的地方增加適當的索引並從不合理的地方刪除次優的索引，將有助於優化那些性能較差的SQL Server應用。實踐表明，合理的索引設計是建立在對各種查詢的分析和預測上的，只有正確地使索引與程序結合起來,才能產生最佳的優化方案。本文就SQL Server索引的性能問題進行了一些分析和實踐。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指針指向數據頁面，所以使用聚簇索引查找數據幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。建立聚簇索引的思想是：
1、大多數表都應該有聚簇索引或使用分區來降低對表尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的吞吐量。
2、在聚簇索引下，數據在物理上按順序排在數據頁上，重復值也排在一起，因而在那些包含范圍檢查(between、<、<=、>、>=)或使用group by或order by的查詢時，一旦找到具有范圍中第一個鍵值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜索，避免了大范圍掃描，可以大大提高查詢速度。
3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖沖突。
4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，數據行必須移動到新的位置。
5、選擇聚簇索引應基於where子句和連接操作的類型。
聚簇索引的侯選列是：
1、主鍵列,該列在where子句中使用並且插入是隨機的。
2、按范圍存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不經常修改的列。
5、在連接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的數據，而是對每一行存儲索引列值並用一個指針指向數據所在的頁面。換句話說非聚簇索引具有在索引結構和數據本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問數據的不同排序順序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：
1、索引需要使用多少空間。
2、合適的列是否穩定。
3、索引鍵是如何選擇的，掃描效果是否更佳。
4、是否有許多重復值。
對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該數據的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除數據的進程也會有類似的開銷，另外，刪除進程還必須把數據移到頁面上部，以保證數據的連續性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況：
1、某列常用於集合函數(如Sum,....)。
2、某列常用於join,order by,group by。
3、查尋出的數據不超過表中數據量的20%。
三、覆蓋索引(covering indexes)的使用
覆蓋索引是指那些索引項中包含查尋所需要的全部信息的非聚簇索引，這種索引之所以比較快也正是因為索引頁中包含了查尋所必須的數據,不需去訪問數據頁。如果非聚簇索引中包含結果數據,那麼它的查詢速度將快於聚簇索引。
但是由於覆蓋索引的索引項比較多,要佔用比較大的空間。而且update操作會引起索引值改變。所以如果潛在的覆蓋查詢並不常用或不太關鍵，則覆蓋索引的增加反而會降低性能。
四、索引的選擇技術
p_detail是住房公積金管理系統中記錄個人明細的表，有890000行，觀察在不同索引下的查詢運行效果，測試在C/S環境下進行，客戶機是IBM PII350(內存64M),伺服器是DEC Alpha1000A(內存128M),資料庫為SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date>』19990101』 and op_date<』
19991231』 and pri_surplus1>300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date>』19990101』 and
pay_month between『199908』 and』199912』
不建任何索引查詢1 1分15秒
查詢2 1分7秒
在op_date上建非聚簇索引查詢1 57秒
查詢2 57秒
在op_date上建聚簇索引查詢1 <1秒
查詢2 52秒
在pay_month、op_date、pri_surplus1上建索引查詢1 34秒
查詢2 <1秒
在op_date、pay_month、pri_surplus1上建索引查詢1 <1秒
查詢2 <1秒
從以上查詢效果分析，索引的有無，建立方式的不同將會導致不同的查詢效果，選擇什麼樣的索引基於用戶對數據的查詢條件,這些條件體現於where從句和join表達式中。一般來說建立索引的思路是：
(1)主鍵時常作為where子句的條件，應在表的主鍵列上建立聚簇索引，尤其當經常用它作為連接的時候。
(2)有大量重復值且經常有范圍查詢和排序、分組發生的列，或者非常頻繁地被訪問的列，可考慮建立聚簇索引。
(3)經常同時存取多列，且每列都含有重復值可考慮建立復合索引來覆蓋一個或一組查詢，並把查詢引用最頻繁的列作為前導列，如果可能盡量使關鍵查詢形成覆蓋查詢。
(4)如果知道索引鍵的所有值都是唯一的，那麼確保把索引定義成唯一索引。
(5)在一個經常做插入操作的表上建索引時，使用fillfactor(填充因子)來減少頁分裂，同時提高並發度降低死鎖的發生。如果在只讀表上建索引，則可以把fillfactor置為100。
(6)在選擇索引鍵時，設法選擇那些採用小數據類型的列作為鍵以使每個索引頁能夠容納盡可能多的索引鍵和指針，通過這種方式，可使一個查詢必須遍歷的索引頁面降到最小。此外，盡可能地使用整數為鍵值，因為它能夠提供比任何數據類型都快的訪問速度。
五、索引的維護
上面講到,某些不合適的索引影響到SQL Server的性能,隨著應用系統的運行,數據不斷地發生變化,當數據變化達到某一個程度時將會影響到索引的使用。這時需要用戶自己來維護索引。索引的維護包括：
1、重建索引
隨著數據行的插入、刪除和數據頁的分裂，有些索引頁可能只包含幾頁數據，另外應用在執行大塊I/O的時候，重建非聚簇索引可以降低分片，維護大塊I/O的效率。重建索引實際上是重新組織B-樹空間。在下面情況下需要重建索引：
(1)數據和使用模式大幅度變化。
(2)排序的順序發生改變。
(3)要進行大量插入操作或已經完成。
(4)使用大塊I/O的查詢的磁碟讀次數比預料的要多。
(5)由於大量數據修改，使得數據頁和索引頁沒有充分使用而導致空間的使用超出估算。
(6)dbcc檢查出索引有問題。
當重建聚簇索引時，這張表的所有非聚簇索引將被重建。
2、索引統計信息的更新
當在一個包含數據的表上創建索引的時候，SQL Server會創建分布數據頁來存放有關索引的兩種統計信息：分布表和密度表。優化器利用這個頁來判斷該索引對某個特定查詢是否有用。但這個統計信息並不動態地重新計算。這意味著，當表的數據改變之後，統計信息有可能是過時的，從而影響優化器追求最有工作的目標。因此，在下面情況下應該運行update statistics命令：
(1)數據行的插入和刪除修改了數據的分布。
(2)對用truncate table刪除數據的表上增加數據行。
(3)修改索引列的值。
六、結束語
實踐表明，不恰當的索引不但於事無補，反而會降低系統的執行性能。因為大量的索引在插入、修改和刪除操作時比沒有索引花費更多的系統時間。例如下面情況下建立的索引是不恰當的：
1、在查詢中很少或從不引用的列不會受益於索引，因為索引很少或從來不必搜索基於這些列的行。
2、只有兩個或三個值的列，如男性和女性(是或否)，從不會從索引中得到好處。
另外，鑒於索引加快了查詢速度，但減慢了數據更新速度的特點。可通過在一個段上建表，而在另一個段上建其非聚簇索引，而這兩段分別在單獨的物理設備上來改善操作性能。
㈡ hashjoinrightsemi如何優化
MySQL一直被人詬病沒有實現HashJoin，最新發布的8.0.18已經帶上了這個功能，令人欣喜。有時候在想，MySQL為什麼一直不支持HashJoin呢？我想可能是因為MySQL多用於簡單的OLTP場景，並且在互聯網應用居多，需求沒那麼緊急。另一方面可能是因為以前完全靠社區，這種演進速度畢竟有限，Oracle收購MySQL後，MySQL的發版演進速度明顯加快了很多。
HashJoin本身演算法實現並不復雜，要說復雜，可能是優化器配套選擇執行計劃時，是否選擇HashJoin，選擇外表，內表可能更復雜一點。不管怎樣現在已經有了HashJoin，優化器在選擇Join演算法時又多了一個選擇。MySQL本著實用主義，相信這個功能增強也回應了一些質疑，有些功能不是沒有能力做好，而是有它的優先順序。
在8.0.18之前，MySQL只支持NestLoopJoin演算法，最簡單的就是Simple NestLoop Join，MySQL針對這個演算法做了若干優化，實現了Block NestLoop Join，Index NestLoop Join和Batched Key Access等，有了這些優化，在一定程度上能緩解對HashJoin的迫切程度。下文會單獨拿一個章節講MySQL的這些Join優化，下面先講HashJoin。
Hash Join演算法
NestLoopJoin演算法簡單來說，就是雙重循環，遍歷外表(驅動表)，對於外表的每一行記錄，然後遍歷內表，然後判斷join條件是否符合，進而確定是否將記錄吐出給上一個執行節點。從演算法角度來說，這是一個M*N的復雜度。HashJoin是針對equal-join場景的優化，基本思想是，將外表數據load到內存，並建立hash表，這樣只需要遍歷一遍內表，就可以完成join操作，輸出匹配的記錄。如果數據能全部load到內存當然好，邏輯也簡單，一般稱這種join為CHJ(Classic Hash Join)，之前MariaDB就已經實現了這種HashJoin演算法。如果數據不能全部load到內存，就需要分批load進內存，然後分批join，下面具體介紹這幾種join演算法的實現。
In-Memory Join(CHJ)
HashJoin一般包括兩個過程，創建hash表的build過程和探測hash表的probe過程。
1).build phase
遍歷外表，以join條件為key，查詢需要的列作為value創建hash表。這里涉及到一個選擇外表的依據，主要是評估參與join的兩個表(結果集)的大小來判斷，誰小就選擇誰，這樣有限的內存更容易放下hash表。
2).probe phase
hash表build完成後，然後逐行遍歷內表，對於內表的每個記錄，對join條件計算hash值，並在hash表中查找，如果匹配，則輸出，否則跳過。所有內表記錄遍歷完，則整個過程就結束了。過程參照下圖，來源於MySQL官方博客
左側是build過程，右側是probe過程，country_id是equal_join條件，countries表是外表，persons表是內表。
On-Disk Hash Join
CHJ的限制條件在於，要求內存能裝下整個外表。在MySQL中，Join可以使用的內存通過參數join_buffer_size控制。如果join需要的內存超出了join_buffer_size，那麼CHJ將無能為力，只能對外表分成若干段，每個分段逐一進行build過程，然後遍歷內表對每個分段再進行一次probe過程。假設外表分成了N片，那麼將掃描內表N次。這種方式當然是比較弱的。在MySQL8.0中，如果join需要內存超過了join_buffer_size，build階段會首先利用hash算將外表進行分區，並產生臨時分片寫到磁碟上；然後在probe階段，對於內表使用同樣的hash演算法進行分區。由於使用分片hash函數相同，那麼key相同(join條件相同)必然在同一個分片編號中。接下來，再對外表和內表中相同分片編號的數據進行CHJ的過程，所有分片的CHJ做完，整個join過程就結束了。這種演算法的代價是，對外表和內表分別進行了兩次讀IO，一次寫IO。相對於之之前需要N次掃描內表IO，現在的處理方式更好。
第一張圖是外表的分片過程，第二張圖是內表的分片過程，第三張圖是對分片進行build+probe過程。
Grace Hash Join
主流的資料庫Oracle，SQLServer，PostgreSQL早就支持了HashJoin。Join演算法都類似，這里介紹下Oracle使用的Grace Hash Join演算法。其實整個過程與MySQL的HashJoin類似，主要有一點區別。當出現join_buffer_size不足時，MySQL會對外表進行分片，然後再進行CHJ過程。但是，極端情況下，如果數據分布不均勻，導致大量的數據hash後都分布在一個分桶中，導致分片後，join_buffer_size仍然不夠，MySQL的處理方式是一次讀分片讀若干記錄構建hash表，然後probe對應的外表分片。處理完一批後，清理hash表，重復上述過程，直到這個分片的所有數據處理完為止。這個過程與CHJ在join_buffer_size不足時，處理邏輯相同。
GraceHash在遇到這種情況時，會繼續分片進行二次Hash，直到內存足夠放下一個hash表為止。但是，這里仍然有極端情況，如果輸入join條件都相同，那麼無論進行多少次Hash，都沒法分開，那麼這個時候GraceHashJoin也退化成和MySQL的處理方式一樣。
hybrid hash join
與GraceHashJoin的區別在於，如果緩存能緩存足夠多的分片數據，會盡量緩存，那麼就不必像GraceHash那樣，嚴格地將所有分片都先讀進內存，然後寫到外存，然後再讀進內存去走build過程。這個是在內存相對於分片比較充裕的情況下的一種優化，目的是為了減少磁碟的讀寫IO。目前Oceanbase的HashJoin採用的是這種join方式。
MySQL-Join演算法優化
在MySQL8.0.18之前，也就是在很長一段時間內，MySQL資料庫並沒有HashJoin，主要的Join演算法是NestLoopJoin。SimpleNestLoopJoin顯然是很低效的，對內表需要進行N次全表掃描，實際復雜度是N*M，N是外表的記錄數目，M是記錄數，代表一次掃描內表的代價。為此，MySQL針對SimpleNestLoopJoin做了若干優化，下面貼的圖片均來自網路。
BlockNestLoopJoin(BNLJ)
MySQL採用了批量技術，即一次利用join_buffer_size緩存足夠多的記錄，每次遍歷內表時，每條內表記錄與這一批數據進行條件判斷，這樣就減少了掃描內表的次數，如果內表比較大，間接就緩解了IO的讀壓力。
IndexNestLoopJoin(INLJ)
如果我們能對內表的join條件建立索引，那麼對於外表的每條記錄，無需再進行全表掃描內表，只需要一次Btree-Lookup即可，整體時間復雜度降低為N*O(logM)。對比HashJoin，對於外表每條記錄，HashJoin是一次HashTable的search，當然HashTable也有build時間，還需要處理內存不足的情況，不一定比INLJ好。
Batched Key Access
IndexNestLoopJoin利用join條件的索引，通過Btree-Lookup去匹配減少了遍歷內表的代價。如果join條件是非主鍵列，那麼意味著大量的回表和隨機IO。BKA優化的做法是，將滿足條件的一批數據按主鍵排序，這樣回表時，從主鍵的角度來說就相對有序，緩解隨機IO的代價。BKA實際上是利用了MRR特性(MultiRangeRead)，訪問數據之前，先將主鍵排序，然後再訪問。主鍵排序的緩存大小通過參數read_rnd_buffer_size控制。
總結
MySQL8.0以後，Server層代碼做了大量的重構，雖然優化器相對於Oracle還有很大差距，但一直在進步。HashJoin的支持使得MySQL優化器有更多選擇，SQL的執行路徑也能做到更優，尤其是對於等值join的場景。雖然MySQL之前對於Join做過若干優化，比如NBLJ，INLJ以及BKA等，但這些代替不了HashJoin的作用。一個好用的資料庫就應該具備豐富的基礎能力，利用優化器分析出合適場景，然後拿出對應的基礎能力以最高效的方式響應請求。
㈢ websphere 分布式計算和架構是怎麼實現的
介紹
分布式計算簡單來說，是把一個大計算任務拆分成多個小計算任務分布到若乾颱機器上去計算，然後再進行結果匯總。 目的在於分析計算海量的數據，從雷達監測的海量歷史信號中分析異常信號(外星文明)，淘寶雙十一實時計算各地區的消費習慣等。
海量計算最開始的方案是提高單機計算性能，如大型機，後來由於數據的爆發式增長、單機性能卻跟不上，才有分布式計算這種妥協方案。 因為計算一旦拆分，問題會變得非常復雜，像一致性、數據完整、通信、容災、任務調度等問題也都來了。
舉個例子，產品要求從資料庫中100G的用戶購買數據，分析出各地域的消費習慣金額等。 如果沒什麼時間要求，程序員小明就寫個對應的業務處理服務程序，部署到伺服器上，讓它慢慢跑就是了，小明預計10個小時能處理完。 後面產品嫌太慢，讓小明想辦法加快到3個小時。
平常開發中類似的需求也很多，總結出來就是，數據量大、單機計算慢。 如果上Hadoop、storm之類成本較高、而且有點大才小用。 當然讓老闆買更好的伺服器配置也是一種辦法。
利用分片演算法
小明作為一個有追求有理想的程序員，決定用介於單機計算和成熟計算框架的過度解決方案，這樣成本和需求都能滿足了。 分布式計算的核心在於計算任務拆分，如果數據能以水平拆分的方式，分布到5台機器上，每台機器只計算自身的1/5數據，這樣即能在3小時內完成產品需求了。
如上所述，小明需要把這些數據按照一定維度進行劃分。 按需求來看以用戶ID劃分最好，由於用戶之間沒有狀態上的關聯，所以也不需要事務性及二次迭代計算。 小明用簡單的hash取模對id進行劃分。
f(memberid) % 5 = ServerN
這樣程序可以分別部署到5台機器上，然後程序按照配置只取對應余數的用戶id，計算出結果並入庫。 這種方式多機之間毫無關聯，不需要進行通信，可以避免很多問題。 機器上的程序本身也不具備分布式的特性，它和單機一樣，只計算自身獲取到的數據即可，所以如果某台機器上程序崩潰的話，處理方式和單機一樣，比如記錄下處理進度，下次從當前進度繼續進行後續計算。
利用消息隊列
使用分片方式相對比較簡單，但有如下不足之處。
它不具有負載均衡的能力，如果某台機器配置稍好點，它可能最先計算完，然後空閑等待著。也有可能是某些用戶行為數據比較少，導致計算比較快完成。
還有一個弊端就是每台機器上需要手動更改對應的配置， 這樣的話多台機器上的程序不是完全一樣的，這樣可以用遠程配置動態修改的辦法來解決。
小明這種方式引入了個第三方，消息隊列。 小明先用一個單獨的程序把用戶信息推送到消息隊列里去，然後各台機器分別取消費這個隊列。 於是就有了3個角色：
推送消息的，簡稱Master。
消息隊列，這里以Rabbitmq為例。
各個處理程序，簡稱Worker或Slave都行。
雖然僅僅引入了個第三方，但它已經具備了分布式計算的很多特性。
計算任務分發。 Master把需要計算的用戶數據，不斷的推送消息隊列。
程序一致性。 Worker訂閱相同的消息隊列即可，無需更改程序代碼。
任意擴容。 由於程序完全一樣，意味著如果想要加快速度，重復部署一份程序到新機器即可。 當然這是理論上的，實際當中會受限於消息隊列、資料庫存儲等。
容災性。 如果5台中某一台程序掛了也不影響，利用Rabbitmq的消息確認機制，機器崩潰時正在計算的那一條數據會在超時，在其他節點上進行消費處理。
Hadoop簡介
Hadoop介紹已經相當多了，這里簡述下比如:」Hadoop是一套海量數據計算存儲的基礎平台架構」，分析下這句話。
其中計算指的是MapRece，這是做分布式計算用的。
存儲指的是HDFS，基於此上層的有HBase、Hive，用來做數據存儲用的。
平台，指可以給多個用戶使用，比如小明有一計算需求，他只需要按照對應的介面編寫業務邏輯即可，然後把程序以包的形式發布到平台上，平台進行分配調度計算等。 而上面小明的分布式計算設計只能給自己使用，如果另外有小華要使用就需要重新寫一份，然後單獨部署，申請機器等。Hadoop最大的優勢之一就在於提供了一套這樣的完整解決方案。
下面找了介紹Hadoop的概覽圖，跟小明的設計做對比下:
圖中「大數據計算任務」 對應小明的100G用戶數據的計算任務。
」任務劃分「 對應Master和消息隊列。
「子任務」 對應Worker的業務邏輯。
」結果合並「 對應把每個worker的計算結果入庫。
「計算結果」 對應入庫的用戶消費習慣數據。
PS：為了方便描述，把小明設計的分布式計算，叫做小和尚。
MapRece
由於MapRece計算輸入和輸出都是基於HDFS文件，所以大多數公司的做法是把mysql或sqlserver的數據導入到HDFS，計算完後再導出到常規的資料庫中，這是MapRece不夠靈活的地方之一。 MapRece優勢在於提供了比較簡單的分布式計算編程模型，使開發此類程序變得非常簡單，像之前的MPI編程就相當復雜。
狹隘的來講，MapRece是把計算任務給規范化了，它可以等同於小和尚中Worker的業務邏輯部分。 MapRece把業務邏輯給拆分成2個大部分，Map和Rece，可以先在Map部分把任務計算一半後，扔給Rece部分繼續後面的計算。 當然在Map部分把計算任務全做完也是可以的。 關於Maprece實現細節部分不多解釋，有興趣的同學可以查相關資料或看下樓主之前的C#模擬實現的博客【探索C#之微型MapRece】。
如果把小明產品經理的需求放到Hadoop來做，其處理流程大致如下：
把100G數據導入到HDFS
按照Maprece的介面編寫處理邏輯，分Map、Rece兩部分。
把程序包提交到Maprece平台上，存儲在HDFS里。
平台中有個叫Jobtracker進程的角色進行分發任務。 這個類似小和尚的Master負載調度管理。
如果有5台機器進行計算的話，就會提前運行5個叫TaskTracker的slave進程。 這類似小和尚worker的分離版，平台把程序和業務邏輯進行分離了， 簡單來說就是在機器上運行個獨立進程，它能動態載入、執行jar或dll的業務邏輯代碼。
Jobtracker把任務分發到TaskTracker後，TaskTracker把開始動態載入jar包，創建個獨立進程執行Map部分，然後把結果寫入到HDFS上。
如果有Rece部分，TaskTracker會創建個獨立進程把Map輸出的HDFS文件，通過RPC方式遠程拉取到本地，拉取成功後，Rece開始計算後續任務。
Rece再把結果寫入到HDFS中
從HDFS中把結果導出。
這樣一看好像是把簡單的計算任務給復雜化了，其實如果只有幾台計算任務的話，使用Maprece確實是殺雞用牛刀了。 如果有TB、PB級別的數據、跑在成百上千台計算節點上，Maprece的優勢才會體現出來。 其計算框架圖架構如下：
離線計算
通常稱Maprece及小和尚這種計算為離線計算，因為它對已經持久化的文件數據進行計算，不能實時響應。 還有個原因就是它的處理速度比較慢，它的輸入和輸出源都是基於HDFS設計，如果數據不是一開始就寫入到HDFS上，就會涉及到數據導入導出，這部分相對耗費時間。 而且它的數據流動是基於文件系統的，Map部分輸出的數據不是直接傳送到Rece部分，而是先寫入HDFS再進行傳送。
處理速度慢也是Maprece的不足之處，促使了後面實時計算的誕生。
另外個缺點是Maprece的計算任務流比較單一，它只有Map、Rece兩部分。 簡單的可以只寫一部分邏輯來解決，如果想拆分成多個部分，如邏輯A、邏輯B、邏輯C等， 而且一部分計算邏輯依賴上一次計算結果的話，MapRece處理起來就比較困難了。 像storm框架解決此類問題的方案，也稱為流式計算，下一章繼續補充。