1、問題

es如何與hive或mysql結合使用？es不支持事務有什么好的彌補方案嗎？

2、事務的核心概念

如果一個數據庫聲稱支持事務的操作，那么該數據庫必須要具備以下ACID四個特性：

• 原子性（Atomicity）
  原子性是指事務包含的所有操作要么全部成功，要么全部失敗回滾，

• 一致性（Consistency）
  一致性是指事務必須使數據庫從一個一致性狀態變換到另一個一致性狀態，也就是說一個事務執行之前和執行之后都必須處于一致性狀態。

• 隔離性（Isolation）
  隔離性是當多個用戶并發訪問數據庫時，比如操作同一張表時，數據庫為每一個用戶開啟的事務，不能被其他事務的操作所干擾，多個并發事務之間要相互隔離。

• 持久性（Durability）
  持久性是指一個事務一旦被提交了，那么對數據庫中的數據的改變就是永久性的，即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。

為了更好地理解ACID，以銀行賬戶轉賬為例：

1START TRANSACTION;
2SELECT balance FROM checking WHERE customer_id = 10233276;
3UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 10233276;
4UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276;
5COMMIT;

原子性：要么完全提交（10233276的checking余額減少200，savings 的余額增加200），要么完全回滾（兩個表的余額都不發生變化）

一致性：這個例子的一致性體現在 200元不會因為數據庫系統運行到第3行之后，第4行之前時崩潰而不翼而飛，因為事務還沒有提交。

隔離性：允許在一個事務中的操作語句會與其他事務的語句隔離開，比如事務A運行到第3行之后，第4行之前，此時事務B去查詢checking余額時，它仍然能夠看到在事務A中被減去的200元（賬戶錢不變），因為事務A和B是彼此隔離的。在事務A提交之前，事務B觀察不到數據的改變。

持久性：一個事務一旦commit，對數據的修改是持久的。

3、Elasticsearh不支持事務

一些支持ACID數據存儲的數據庫包括：Postgres, SQLite, Oracle, MySQL (with InnoDB), and MongoDB (4.0+)，不包括Elasticsearch。

Elasticsearch的底層技術是Lucene，Lucene是追求速度而非冗余的信息檢索技術。Lucene具有完全不同的體系結構，可以提供極快的性能，但代價是更容易受到數據丟失的影響。

丟失數據有很多種方式，如果需要的話，你需要重新創建數據。 沒錯，Elasticsearch有一個快照/恢復功能，但是這個過程只會在數據丟失的情況下部分恢復。 除非您在其他系統對數據有額外的備份存儲，否則最新快照和中斷之間的更新將會丟失。 快照/恢復在分裂大腦的情況下也無濟于事，因為沒有用于協調每個分區的更新的機制。 更新將會丟失。

4、Elasticsearch支持的場景

• 數據安全性場景：ElasticSearch的shard支持replication，一份數據可以保存多份，如果某一臺機器掛掉了，數據在其他機器上還有，不用擔心丟失。

• 訪問安全性場景：隨著x-pack開源，ElasticSearch支持驗證，不用擔心未授權的訪問。或者借助第三方search-guard等。

• 遷移特性：ElasticSearch支持眾多的插件，在和其他開源系統之間導入，導出數據都很簡單。
  

• 

• 數據完整性：ElasticSearch支持保存數據原文。

5、Elasticsearch不支持的場景

• 不支持事務，如前所述。

• 類似數據庫中通過外鍵的復雜的多表關聯操作，Elasticsearch天生支持不足。

• 讀寫有一定延時，寫入的數據，最快1s中能被檢索到。
  實時性的官網解讀：

In Elasticsearch, this lightweight process of writing and opening a
new segment is called a refresh. By default, every shard is refreshed
automatically once every second. This is why we say that Elasticsearch
has near real-time search: document changes are not visible to search
immediately, but will become visible within 1 second.

默認的刷新頻率設置是1秒，也就是說文檔從Index請求到對外可見能夠被搜到，最少要1秒鐘，強制的，你的網絡和CPU再快也不行。這么做是Lucene為了提高寫操作的吞吐量而做出的延遲犧牲，當然這個設置是可以手動調整的，但是并不建議你去動它，會極大地影響搜索性能。不同的應用對實時性的定義并不一樣，這取決于你的需求。

• ES不是關系數據庫，因此如果您的數據會受益于外鍵等等，那么ES不是您主要數據存儲的好選擇

6、系統設計數據庫選型考量

使用哪種產品作為數據倉庫或主數據庫存儲完全取決于具體的應用場景。

1. 如果信息獲取及分析的能力是你的首要需求，那么無疑Elasticsearch是一個好的選擇。

2. 如果你的數據并不頻繁的update操作，也沒有事務性操作，那么完全可以用Elasticsearch替代其他存儲。

3. 實時性要求高的場景，需要結合ACID特性的數據庫和Elasticsearch結合使用。

選型核心思考問題如下：

 

7、數據庫如何與Elasticsearch結合使用？

設計時候注意：

1. 創建的每個Elasticsearch索引都應該由符合ACID的數據存儲支持。

2. 數據庫應該是真實的最終來源，從中填充索引。

3. 如果異常情況發生（節點丟失，中斷或誤操作 ）導致丟失了索引，您將能夠完全恢復它。

4. 一般的用法是另外的數據庫比如NOSQL里面有一份，然后實時同步到ES，這樣一個用于鍵值查詢，一個用于各種其他查詢。 如果ES升級了之類的，比如數據結構變了，那么老版本數據可以不要，直接NOSQL再導入一份到新版本，還可以恢復。

5. logstash的同步插件如logstash_input_jdbc 不支持同步刪除操作，建議改為更新操作加標記flag，或者通過業務邏輯實現同步刪除操作。

核心操作：

1. ES中只存儲檢索字段，方便快速檢索、全文檢索。

2. Mysql中存儲全部字段，利用ACID事務特性。

3. 通過關聯字段建立關聯，比如：news_id在ES和mysql中要有相同的值。

4. 核心數據先通過ES快速獲取Id（如news_id）,再通過Mysql二次查詢。