開始沒設計好，我訂單分為4個千萬級資料表關聯（oracle），當一個客戶進來后，我要列出他所有的訂單，這樣4個大表關聯，賊賊慢，我就在想前些年不是一直在喊大資料嗎，大資料怎么來解決這個問題呢。
實時性很高，速度也要求很快
uj5u.com熱心網友回復：
你這問得太籠統了。大資料意味著分布式，即分布式存盤和計算。4個kw級表join，還要快速回應，那首先問題是準備好多少臺什么配置的節點。。。然后才是資料如何分布式治理和采用什么計算框架的問題了。。。uj5u.com熱心網友回復：
大資料可能應該這么做，把四個關聯好的做成一個寬表 放到hbase 或者什么的地方，索引放在es里面，這樣應該也可以秒級回應uj5u.com熱心網友回復：
4個千萬級表做級聯能滿足你實時計算，實時查詢？樓上的答案是一般的大資料解決方案，hbase寬表存資料，es做索引。
查詢如果比較單一的話，可以直接設計好hbase的表的rowkey，查詢起來比ES快。
uj5u.com熱心網友回復：
建議考慮建立寬表，在kudu中，通過sparkJobServer發布rest介面，做實時查詢。前提要求機器配置也比較高，最少8臺256G記憶體的機器集群uj5u.com熱心網友回復：
我繼續補充下我的問題，開始沒講清楚，不好意思。首先這個表是訂單表，意味著插入很頻繁。其次歷史資料意義重大，我上面的需求是需要把符合條件的3年的資料查出來。
就想問大資料方面能否做到這么實時，有我直接從oracle查出來實時么。
uj5u.com熱心網友回復：
我的實時訂單能進去么uj5u.com熱心網友回復：
講下我目前解決思路，感覺好low.邏輯庫中創建一個表，包含經常要查詢的欄位。通過觸發器記錄這4個表的新增和修改，每秒刷到這個大表中，通過這種方式來避免多表聯合查詢。但是帶來了性能損失，看起來好low.就想了解下，如何利用大資料知識去解決這類問題。
uj5u.com熱心網友回復：
能把資料放到記憶體中查嗎？uj5u.com熱心網友回復：
沒有完美的解決方案，所有聽起來高大上的東西，原理都很low。
只有符合現階段需求和拓展預期的最佳實踐。
建議從分布式的幾大原則入手學習。例如CAP理論，分布式一致性演算法（Raft等），BASE理論。
多學習現有的分布式資料庫（NoSQL的HBase，Mongo，OLTP的RDB集群，HTAP的如TiDB），以及資料的分治演算法，MapReduce思想，一致性哈希等等。
uj5u.com熱心網友回復：
建個寬表，包含四個表的所有欄位，不要主鍵。寫個定時任務，把表中新增的資料，不斷的刷到寬表中。然后查詢時直接查寬表。 查寬表還慢，把寬表放到Mongo中，直接通過Mongo查詢？uj5u.com熱心網友回復：
大資料是兩個方面的意思：1是非常“大”的離散資料，比如說幾百億記錄分布在幾千臺機器上，如何把幾千個表當作一個表來寫查詢陳述句。2是一堆數學統計軟體包，用來做最基本的所謂神經病網路分類演算法，用了大資料這個時髦詞兒。對于1來說，從來也沒有說它比單機處理的速度更快。人家是根本不可能單機，所以才分為幾千臺機器上進行存盤的。于是就回到了你的后邊提出的問題。你在資料庫中搞什么“觸發器”來將資料寫到快取，這是本末倒置了。快取資料應該是第一位的、不落地的。資料即使還沒有保存到資料庫中備份之前，就應該落在快取里了。而且資料庫操作可以是異步的，不需要阻塞真正的業務操作，特別是不應該去讓許多執行緒收到什么資料庫事務鎖的垃圾限制，因此把快取操作當作資料庫表的觸發器的結果是完全是本末倒置了。
uj5u.com熱心網友回復：
滿腦子只有關系資料庫增上改查的時候，才會什么技術都往資料庫表、觸發器上去聯系。uj5u.com熱心網友回復：
仔細看了您的回復，感覺很有道理，但是又想不出一個方案，請指導一下，幫我指個小一點的方向，謝謝
uj5u.com熱心網友回復：
1.從業務角度考慮，實時調取歷史訂單，是不是可以區分 動態變化的訂單 + 歷史不變的訂單。2. 如果可以區分開，對于動態變化的訂單 可以采用oracle 查詢。對于 歷史不變的訂單 可以建立寬表，spark streaming 實時計算獲得結果，存盤到hbase，供前端查詢。
uj5u.com熱心網友回復：
我雖然是個剛入門的，我也給點思路，我建議你使用solr加 hbase 加spark。把關聯資料利用spark計算結果存入hbase，用solr做全欄位索引，再訪問solr去查。和1樓思路差不多。速度是比較快的，至于四表關聯的優化有很多，spark這邊可以做。對于增量更新的問題，可以放在solr里面做，如果有洗掉標志位和時間戳，可以自動實作增量更新的。一點點拙見uj5u.com熱心網友回復：
需求要先搞清楚，通常列出“所有”訂單并不是完全所有，因為一個螢屏也裝不下啊，都是分頁的。像普通電商公司一般采用mysql分下庫，單個庫中的每個表一般最多3kw~5kw，對查詢都是毫秒級出結果的。4個表join這個優化一下關系型資料庫完全沒問題，你這點資料量其實是很少的，分下庫就每個表只有幾百萬，沒必要用spark、hadoop這些重武器，而且可以告訴你的這種應用一點也快不起來，成本還很高。轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/42588.html
標籤：Spark