你的SQL中使用了好多 in 關鍵字，效率肯定不高了，例如下面的SQL
SELECTCOUNT(p.id)pstn_totalnum
FROMportp
WHEREp.device_idin(SELECTde.id
FROMdevicede
WHEREde.local_net_id=810
ANDde.sub_type=2001)
你完全可以不使用 in 關鍵字，如：
SELECTCOUNT(p.id)pstn_totalnum
FROMportp,devicede
WHEREp.device_id=de.id
andde.local_net_id=810
andde.sub_type=2001
都是同樣的結果，但效率肯定是不一樣的，device 符合條件的數據越多，效率越慢，至於上面的一些SQL，肯定還有優化的地方，比如 exists 關鍵字內部的SQL，效率也不會高，根據邏輯看看有沒有需要優化的地方。
B. DSL是什麼意思
兩個意思，一個是數字用戶線路，另一個是領域特定語言。
DSL的中文名是數字用戶線路，是以電話線為傳輸介質的傳輸技術組合。DSL技術在傳遞公用電話網路的用戶環路上支持對稱和不對稱的傳輸方式，解決了網路服務商與終端用戶之間經常出現的「最後一公里」傳輸瓶頸問題。
領域特定語言（英語：domain-specific language、DSL）指的是專注於某個應用程序領域的計算機語言。又譯作領域專用語言。同名著作是DSL領域的一部不朽作品。該書由世界一流的軟體開發大師和軟體開發「教父」Martin Fowler撰寫多年而成，ThoughtWorks中國翻譯。
(2)sql轉esdsl擴展閱讀：
領域特定語言的分類：
1、外部DSL：與應用程序系統中使用的語言不同，通常使用用戶定義的語法。宿主應用的代碼採用文本解析技術來解析外部DSL編寫的腳本。例子如：正則表達式、SQL、AWK以及Struts的配置文件等。
2、內部DSL：通用語言的特定語法，內部DSL編寫的腳本是一個合法的程序，但它有特定的風格，而且只使用部分語言特性來處理整個系統的一個小方面。
3、語言工作台：一個特殊的IDE用於定義和構造DSL。具體來說，語言工作台不僅用於確定DSL的語言結構，還用於確定編寫DSL腳本的人員的編輯環境。最後一個腳本將編輯環境與語言本身結合起來。
C. DSL是什麼意思
DSL（Digital Subscriber Line）的中文名是數字用戶線路，是以電話線為傳輸介質的傳輸技術組合。DSL包括ADSL(Asymmetric Digital Subscriber Line，非對稱數字用戶線)、RADSL、HDSL和VDSL等等。
DSL技術在傳遞公用電話網路的用戶環路上支持對稱和非對稱傳輸模式，解決了經常發生在網路服務供應商和最終用戶間的「最後一公里」的傳輸瓶頸問題。由於DSL 接入方案無需對電話線路進行改造，可以充分利用可以已經被大量鋪設的電話用戶環路，大大降低額外的開銷。
因此，利用銅纜電話線提供更高速率的網際網路接入，更受用戶的歡迎，在一些國家和地區得到大量應用。
(3)sql轉esdsl擴展閱讀：
用戶終端設備是DSL數據機。它轉換二進制數據到數字電脈沖，使得信號在數字音頻流的頻段內傳輸。
另外如果用戶在同一根線路上使用老式電話，還需要加裝一個被動電子濾波器。這樣就能保證DSL數據機和電話只接受他們設計使用的信號。如果使用"wires-only"服務，用戶可以把濾波器插入一個現有的電話插槽，或者DSL運營商可能安裝它。
在交換局端使用數字用戶線路訪問復用器（DSLAM）將DSL電路上的數據匯聚然後轉發到其他的網路。它還能分離出語音部分。
參考資料來源：網路-DSL
D. 為什麼sparkSQL
Shark和sparkSQL 但是，隨著Spark的發展，其中sparkSQL作為Spark生態的一員繼續發展，而不再受限於hive，只是兼容hive；而hive on spark是一個hive的發展計劃，該計劃將spark作為hive的底層引擎之一，也就是說，hive將不再受限於一個引擎，可以採用map-rece、Tez、spark等引擎。
Shark為了實現Hive兼容，在HQL方面重用了Hive中HQL的解析、邏輯執行計劃翻譯、執行計劃優化等邏輯，可以近似認為僅將物理執行計劃從MR作業替換成了Spark作業（輔以內存列式存儲等各種和Hive關系不大的優化）；同時還依賴Hive Metastore和Hive SerDe（用於兼容現有的各種Hive存儲格式）。這一策略導致了兩個問題，第一是執行計劃優化完全依賴於Hive，不方便添加新的優化策略；二是因為MR是進程級並行，寫代碼的時候不是很注意線程安全問題，導致Shark不得不使用另外一套獨立維護的打了補丁的Hive源碼分支（至於為何相關修改沒有合並到Hive主線，我也不太清楚）。
此外，除了兼容HQL、加速現有Hive數據的查詢分析以外，Spark SQL還支持直接對原生RDD對象進行關系查詢。同時，除了HQL以外，Spark SQL還內建了一個精簡的SQL parser，以及一套Scala DSL。也就是說，如果只是使用Spark SQL內建的SQL方言或Scala DSL對原生RDD對象進行關系查詢，用戶在開發Spark應用時完全不需要依賴Hive的任何東西。
E. 「日記」ElasticSearch7.x新功能介紹
說明：ElasticSearch7.X很多新功能主要基於lucene8.X新特性，故對於lucene8.X新特性不贅述。
在6.1中已加入這個功能，但是默認是關閉的，在7.0中開始默認開啟。若有兩個節點，且其中一個節點上有一個索引的主分片，另一個節點上有同一個索引的副本分片，在6.X中關閉此特性時，不管每個節點狀態如何，是否在做耗時操作，如GC等，每次請求過來時，都會通過輪詢的方式訪問兩個分片其中之一；而在7.X開啟後，ES會統計每次請求耗時，根據每個節點訪問響應的耗時長度，對每個節點的訪問頻次進行自動調整。
Elasticsearch 7.0 中若分片在30秒內無請求訪問，則分片進入"search idle"狀態。一旦進入此狀態且分片所在索引沒有明確設置refresh間隔時間的（默認每秒執行），則定時的refresh停止直到下一個訪問請求達到才進行下一次的refresh，在此期間相比原來，將明顯增強索引數據的吞吐。如果明確設置了refresh間隔時間，則仍按配置中的間隔時間進行調度執行。
Elasticsearch5.3中發布了跨集群搜索（cross-cluster search）功能，供用戶跨多個集群進行查詢，如本地協調節點去訪問多個不同機房的ES集群查詢日誌信息等。Elasticsearch 7.0中引入ccs_minimize_roundtrips執行模式可以減少一次請求來回的網路開銷。
詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/moles-cross-cluster-search.html
Elasticsearch 6.x 及之前的版本使用名為 Zen Discovery 實現，存在一些缺點，如選主時間較慢（秒級）、部分配置存在易於錯配等情況。
Elasticsearch 7重新設計了集群協調子系統，移除了minimum master nodes設置，由集群自己選擇可以形成法定數量的節點。並且新的子系統可以在很短時間內（亞秒級）完成選主。
Elasticsearch 7.0新增加了一個熔斷器，更好的追蹤內存使用量，准確地根據內存用量去拒絕客戶端請求，避免節點異常；另外聚合操作返回的bucket限制為10000以內。
在 Elasticsearch 6.5中作為beta功能引入，6.7、7.X中GA，可以用在跨機房、跨地區情況下的集群數據同步。在這個版本中加入了一些監控的特性，解決了一些例如主從同步異常的問題。
詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.6/ccr-getting-started.html
索引生命周期管理（Index Lifecycle Management）作為一個beta特性在6.6發布，在7.0GA。索引生命周期管理現在可以管理frozen indices，他作為其cold階段的一部分；也可以對其管理的索引使用CCR功能。
frozen indices詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.0/frozen-indices.html
ILM詳情： https://www.cnblogs.com/sanzxcvbnm/p/12083735.html ； https://www.jianshu.com/p/94e37a5b0878?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
Elasticsearch SQL可以讓用戶能夠使用SQL進行交互查詢Elasticsearch中索引數據。該功能在Elasticsearch 6.3中作為alpha版本引入，目前在Elasticsearch 6.7和7.0中也能夠生產使用。 通過 Elasticsearch REST endpoints 、 Elasticsearch SQL command line interface 、 JDBC driver 、 ODBC driver 可以使用es sql。
從Elasticsearch 7.0.0開始，High-level REST Client（HLRC）API的所有功能已經宣布完成。原來TransportClient使用者可以計劃將TransportClient遷移到HLRC。
Elasticsearch 7.0.0引入了JDK8原生時間庫，可以處理納秒精度時間戳。
JDK11可以支持TLS1.3，所以如果使用JDK11，那在es中可以選擇使用TLS1.3.另外TLS1.0被移除，使用老版本jdk的可以選擇使用TLS1.1或者1.2。
內置了OpenJDK，使得上手起來更加快速。
在日誌目錄下，我們會看到有.json拓展的日誌。這便於我們使用類似jq的工具去查看日誌，同時也在日誌中加入了許多額外結構化信息，例如node.id, cluster.uuid, type。
這是lucene8中的重要版本功能更新。在之前的版本中，查詢會計算所有命中的文檔，但是用戶經常查詢 'a' , 'the' 等詞彙，這種詞彙不會增加多少文檔得分，但迫使查詢過程為大量的文檔進行打分。
因此，如果檢索結果只需要返回 TOP-K 的結果，而非范圍准確的命中數量，可以對此進行優化，Lucene 8 中引入了 WAND 演算法來實現此特性。當檢索結果小於指定的結果總數時，該優化不會生效。
在停止計算命中文檔總數之後，查詢 QPS 得到大幅提升，以下結果來自 lucene 官方基準測試
Bool AND 查詢，提升 2.3 倍左右。
Bool OR 查詢，提升 2.5 倍左右。
Term 查詢，提升 40 倍左右。
在 Elasticsearch 7中，要在查詢中返回 TOP-K 的結果，通過 track total hits 參數來指定，默認值為10000，根據自己的需要設置返回前 K 個命中結果，或者設置為 true，返回全部命中結果數量。
計算 TOP-K 的過程中需要評估文檔的最大得分，這需要在索引過程中寫入一些額外的信息。Lucene 將詞典劃分一個個的 block，並構建了一個跳躍表，在查詢的時候跳過不匹配的文檔，現在，索引過程中會為每個塊中最高影響(impacts）的摘要添加到該跳錶中，可以計算出該塊可能產生的最大得分，如果該得分不具有競爭力，則可以跳過它。更多信息可以閱讀 此處 。
Elasticsearch 7.0 中新增了兩個數據類型： rank_feature and rank_features 。他們只作用於數值型數據，且底層實現上可以利用上面top hits的特性。故可以看作是function score簡化出的一個功能，利用他們可以對排序打分進行干預且查詢效率更快。更多可以看以下詳情： https://www.elastic.co/cn/blog/easier-relevance-tuning-elasticsearch-7-0
別名function score2。拓展性更佳，可以支持多種腳本語言及java插件，function score原有功能也都可以支持。詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.0/query-dsl-script-score-query.html
在ElasticSearch7.2+後關閉狀態的索引也可以進行分片復制，以便於後面集群異常時可以成為主分片，或者進行數據恢復。
可以作於搜索聯想功能，用戶輸入部分查詢詞後，返回聯想詞列表。與Completion suggester和Context Suggester功能大部分重復，但兩者有不同的底層實現，search_as_you_type可以利用到最新top hits的特性，而suggester底層使用FST數據結構。之所以重新開發了一個數據欄位，原因歸結為：新數據欄位更有利於佔用更少的內存開銷；新數據欄位功能拓展性更加，可以用在普通的query語句中，結合其他filter等語法。
詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.6/search-as-you-type.html ； https://github.com/elastic/elasticsearch/issues/33160 ； https://stackoverflow.com/questions/42127894/whats-the-difference-between-search-as-you-type-and-context-suggester
只能作用於date, date_nanos, 及 geo_point數據類型的欄位。可以放置於query語法中，在查詢中過濾不符合范圍的時間或者距離，查詢語法中需要設置origin（即初始的時間節點或者經緯度）。
一個只能在選舉時投票而不能成為主節點的角色被引入了，這有助於高可用，且相對於主節點，這些節點只需要消耗非常少量的CPU和內存開銷。
新的 Analyzer reload API 允許去修改運行時的分析器及其相應資源。例如，在之前版本中，重載同義詞需要先關閉索引，再打開索引。使用這個api就不需要再關閉索引了。
通過這個欄位可以直接索引json數據。僅為整個JSON對象創建一個欄位映射，這可以幫助防止由於大量不同的欄位映射而導致 映射爆炸 。
詳情： https://blog.csdn.net/UbuntuTouch/article/details/103713730
有兩種欄位類型： sparse_vector 和 dense_vector ，用於計算和查詢向量之間的餘弦相似度和點積。
如題。
僅限於設置為只讀的別名索引可以同步，write索引不可以同步。
如題。
在ElasticSearch6.X中，使用 Terms Aggregation會佔用更多的內存，此版本進行了優化，降低內存消耗壓力。
使用無監督的異常檢測演算法分析索引中每條doc的數值型欄位，並在每條doc中記錄一個異常值，以比較彼此之間的異常差異。提供 evaluate data frame analytics API ，以獲取在演算法使用期間的一些指標數據。
它會聚合出在特定欄位中很少出現的欄位值。計劃使用它去替換terms aggregation中的"order" : { "_count" : "asc" }配置項。
提供新介面 pinned query ，可以指定排在返回結果前列的docs，適用於需要使用引導數據的場景。
支持AdoptOpenJDK 13，並將其打包在ES包中。
如果查詢是以_search結尾，那麼當對端連接被關閉後，查詢也會被中止。
通過這個欄位可以在es插入一個幾何范圍，即每條doc都是通過一串坐標點定義的幾何范圍，而通過shape query結合relationship配置，可以對每條doc計算是否是包含、相交等等關系，並將符合條件的取出。
詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/query-dsl-shape-query.html ； https://blog.csdn.net/wjzt7322/article/details/103385560 ；
增加了一個新的圓形預處理，把圓形定義的幾何圖形轉化為一個近似的規則幾何，便於查詢、聚合、索引等操作。圖形如下：
詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/ingest-circle-processor.html
現在直方圖和日期直方圖將支持范圍欄位，例如用其去計算特定時間段內的電話數等。
如題。
Elasticsearch 5.x版本中引入了Ingest Node的概念（預處理節點），它使得Es在事實上具備了Logstash的部分功能，即對索引數據的預處理。
在7.5增加了一個新的ingest processor，它可以使得新數據索引時從原有其他索引中抽取欄位數據豐富正在插入的doc。
詳情： https://www.felayman.com/articles/2017/11/24/1511527532643.html ； https://blog.csdn.net/UbuntuTouch/article/details/103400061
新的快照生命周期管理功能，允許用戶設置定時策略去刪除老的索引。
新增暫停和恢復介面，使用戶可以臨時暫停自動復制的模式
分類分析是一個有監督的機器學習演算法，可以預測離散的分類值。在Es中可以進行二分類的演算法執行，即將數據分為兩個可能的類別。
詳情： https://www.elastic.co/guide/en/machine-learning/7.x/dfa-classification.html
暫略（ https://www.elastic.co/guide/en/elasticsearch/reference/7.x/histogram.html ）
新版本lucene對這方面進行了重構，重構後也能在排序時過濾在打分上沒有競爭力的文檔(類似top hits)，在查詢效率上提升至少10倍。
ElasticSearch 7.2.0中引入，現在GA。 Transforms and Transform APIs 提供給我們一個能力，即指定索引中不同欄位進行聚合，並將聚合結果索引入一個新建索引中（聚合結果中可以產生出其他新的欄位，如同類型欄位值的出現數量等），在這個過程中我們可以通過管理介面進行管理，每次聚合結果索引入新索引後，原索引中都會有一個checkpoint，故後面可以繼續做批量聚合。
詳情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/transforms.html
參考資料：
https://gitbook.cn/gitchat/column/5ce4ff9a308dd66813d92799/topic/5d47cfa4cb702a087ef8b77b
https://blog.csdn.net/UbuntuTouch/article/list/1
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/release-highlights-7.3.0.html
F. jooq 為什麼不直接寫sql
JOOQ設計上，就是通過類去操作資料庫，減少開發人員直接寫SQL的麻煩。可以說它是基於ORM卻高於ORM的一個設計。通過DSL編寫，繼承了傳統的ORM框架的優點，也彌補了Mybatis這類半自動化框架的不足。總之這個框架設計思想還是不錯的。
G. elasticsearch基本查詢筆記（三）-- es查詢總結
term 查詢是簡單查詢，接受一個欄位名和參數，進行精準查詢，類似sql中：
ES中對應的DSL如下：
在ES5.x及以上版本，字元串類型需設置為keyword或text類型，根據類型來進行精確值匹配。
當進行精確值查詢，可以使用過濾器，因為過濾器的執行非常快，不會計算相關度（ES會計算查詢評分）,且過濾器查詢結果容易被緩存。
bool過濾器組成部分：
當我們需要多個過濾器時，只須將它們置入 bool 過濾器的不同部分即可。
terms是包含的意思，如下：
name包含["奧尼爾","麥迪"]
返回結果：
range查詢可同時提供包含（inclusive）和不包含（exclusive）這兩種范圍表達式，可供組合的選項如下：
類似sql中的范圍查詢：
ES中對應的DSL如下：
如下sql，age不為null：
ES中對應的DSL如下：
如下sql，age為null：
ES中對應的DSL如下：
註：missing查詢在5.x版本已經不存在。
匹配包含 not analyzed（未分詞分析）的前綴字元：
匹配具有匹配通配符表達式（ (not analyzed ）的欄位的文檔。 支持的通配符：
1） * 它匹配任何字元序列（包括空字元序列）；
2） ? 它匹配任何單個字元。
請注意，此查詢可能很慢，因為它需要遍歷多個術語。
為了防止非常慢的通配符查詢，通配符不能以任何一個通配符*****或 ? 開頭。
正則表達式查詢允許您使用正則表達式術語查詢。
舉例如下：
注意： * 的匹配會非常慢，你需要使用一個長的前綴，
通常類似.*?+通配符查詢的正則檢索性能會非常低。
模糊查詢查找在模糊度中指定的最大編輯距離內的所有可能的匹配項，然後檢查術語字典，以找出在索引中實際存在待檢索的關鍵詞。
舉例：
檢索索引test_index中，type為user的全部信息。不過在 es6.x 版本，一個index僅有一個type，未來 es7.x 版本，將取消type，所以這個查詢沒啥意義。
返回指定id的全部信息。
全文檢索查詢，是通過分析器，對查詢條件進行分析，然後在全文本欄位進行全文查詢。
全文搜索取決於mapping中設定的analyzer（分析器），這里使用的是ik分詞器。
所以在進行查詢開發時候，需要先了解index的mapping，從而選擇查詢方式。
匹配查詢接受文本/數字/日期類型，分析它們，並構造查詢。
對查詢傳入參數進行分詞，搜索詞語相同文檔。
match_phrase查詢分析文本，並從分析文本中創建短語查詢。
用戶已經漸漸習慣在輸完查詢內容之前，就能為他們展現搜索結果，這就是所謂的即時搜索（instant search） 或輸入即搜索（search-as-you-type） 。
不僅用戶能在更短的時間內得到搜索結果，我們也能引導用戶搜索索引中真實存在的結果。
例如，如果用戶輸入 johnnie walker bl ，我們希望在它們完成輸入搜索條件前就能得到： Johnnie Walker Black Label 和 Johnnie Walker Blue Label 。
match_phrase_prefix與match_phrase相同，除了它允許文本中最後一個術語的前綴匹配。
H. Dsl轉為sql drools
1、打開使用的編程軟體，找到設置並點擊進入。
2、找到格式設置，將Dsl轉換為sql，並將drools選項打開就完成格式的轉換了。
I. sql中怎麼設置默認值
1、首先新建一個學生表：student，需求：欄位password的默認值是1213142。
J. 日誌平台的一點思考
日誌平台的對開發、運維人員的幫助是非常大的，它可以方便開發、運維人員快速定位問題，從這個角度，日誌平台是個搜索平台；同時還可以做有效的數據分析，比如分析 pv, uv，httpstatus，用戶行為，資源消耗，網路攻擊、trace等等，應用場景非常豐富，這時候它又是個數據分析平台，在馬上到來的5G時代，物聯網的真正興起，日誌平台會發揮更大的價值。
日誌其實是比較寬泛的概念，應用列印的server log,Linux文件系統的syslog，/var/messages 等等都是日誌，日誌本質上其實是一種時序數據，類似於監控領域的metrics，只不過metrics一般是比較結構化的，每個欄位數據長度都比較小，通常是時間+tag+value ，而日誌也帶有時間，但是單條日誌可能會比較長（有時候不止一行） ，同時大多數都是非結構化的文本數據，它們共同的特點是數據產生後不會被更新。
簡單說日誌平台既要存儲又要計算
功能上，日誌平台應該具備以下幾個基本的功能點
1、日誌的採集
2、日誌數據的存儲
3、日誌數據的快速檢索和分析
日誌要搜索，就要集中存儲，就要採集日誌，以前日誌採集分2種，一種是agent的方式，一種是agentless的方式，前者是在要採集的伺服器上部署一個agent，agent將日誌不斷的發送給日誌server端，agentless的方式是通過類似ssh遠程登錄伺服器去抓日誌。
agentless的方式不需要部署agent，一般是定時的方式去拉日誌過來，這種方式時效性很差，不能實時監聽文件系統獲取最新的日誌數據，基本上業內很少有人採用了，以前阿里巴巴的TLog似乎是採用這種方式。
現在大部分是採用部署agent的方式獲取日誌，比較有名的是flume,logstash,filebeat等等，flume和logstash在使用的時候，不方便控制佔用的cpu和內存資源，在微服務化架構的環境中，採集日誌對agent的性能要求越來越高，同時資源消耗要盡可能的低，filebeat相對比較輕量，功能也非常強大，使用人越來越多。
agent的方式本質上是調用server的api介面將數據發送給日誌的server，因此另一種使用方式就是app直接調用日誌server的api，比如將這個功能做成log4j的插件，或者寫入其它的常用的日誌組件中，這樣日誌採集的成本最低，但是當日誌服務不可用的時候，日誌數據恢復成了稍微麻煩的事情。
通常在一個成規模的企業內部，使用agent的方式採集日誌，管理agent也是一個問題，比如阿里巴巴目前聲稱SLS的agent部署超過200萬個節點，不要說200萬個節點，就是200個節點，我們總不能挨個登陸去修改agent的配置文件吧，因此採集任務的自動下發，生效，更改非常重要，同時還要能夠自動管理agent的狀態，升級agent等等。
以前阿里巴巴的TT也有agent採集，部署規模也較大，在實現方面，有些場景下agent會請求服務端的clientAPI，這種設計在雙11降級恢復的時候，會給clientAPI帶來非常大的壓力，因此，在設計應用於大規模的agent部署場景的時候，應該考慮這種問題。
寫的目的是為了讀，要更好的讀，就要設計更合理的存儲方案。既要滿足檢索，又要做數據統計和分析，似乎解決方案只有倒排索引了？開源社區一提到日誌的存儲，一般都會選擇elasticsearch，一些創業公司也會基於或者借鑒es來做存儲的方案，這個東西的確開箱即用，一個命令拉起來，日誌灌進去，搜索效果似乎也不錯，kibana也能分析，但是當我們實際部署應用起來，就會發現用es存日誌是一個成本非常昂貴的方案。
在一家稍有規模的公司，日誌數據10w/s每秒的寫入是非常容易出現的，實時索引，然後刷到文件系統緩存才可見，es這種實現方式，本身就不適合迎接這種高tps的寫入，同時它讀寫不分離，一般情況下，Lucene的設計在日誌場景下需要經過特殊的優化，比如將那些常駐內存的數據進行lru處理，將不常用的索引關閉，在merge的時候對避免重復IO，segment關系映射內存優化等等，越深入了解，越發現這種方案真的太奢華了，業內用es做日誌存儲的基本上都是土豪，動輒幾百上千的伺服器堆砌 + 精細化運維，性價比極低，真是暴殄天物，日誌規模較大的，財力一般的公司就不要考慮這種敗家的方案了。
日誌的存儲實際上需要實時求是，根據日誌的特點，靈活的設計存儲方案。
日誌搜索也是一種典型的互動式查詢的場景, 當然是越快越好，比較理想的情況是1-3秒返回結果，但是時間跨度非常大的場景，十幾秒用戶也能接受，超大規模查詢最慢不超過30秒等等，檢索方面，除了輸入關鍵字，還希望能夠支持功能強大的分析、過濾、統計。這種特點，其實給存儲留下了非常大的設計空間，也是不小的挑戰。
存儲首先應該是分布式的，可以方便水平擴展的，同時根據日誌的特點，做少量的必要的索引。比如日誌一般是按照時間范圍搜索和分析的，那麼時間顯然是最重要的索引，同時日誌來自哪些機器，屬於哪個應用，什麼機房，應該會有一些標簽，那做一些基於標簽的索引就足夠了，那麼現有的一些存儲系統能不能直接利用呢？
前面說了日誌是一種時序數據，那麼opentsdb能不能做日誌的存儲呢？opentsdb本身依賴hdfs，hbase，從部署角度講，太復雜，同時它一行就存儲一小時的數據，每一行是一個metric，這種方式，你日誌怎麼存，顯然不合理。
kafka這種東西呢，它也給每條消息加了時間戳信息，支持按照時間戳seek，kafka的架構設計其實給了我很多日誌存儲設計的啟發，但是它的索引僅有時間是不夠的，也許你會想能不能在topic名字上做點文章，我想也是不可以，因為我們要索引的東西還是蠻多的，kafka在topic數量非常大的情況下，性能會下降的比較明顯。
日誌統計和分析方面阿里巴巴的SLS是通過標准SQL來做的，但是我更喜歡類似shell命令行的風格和方式，sql思維需要一些時間轉變，用戶並不一定都會喜歡sql，但是不管怎麼樣，要分析、統計日誌，需要在日誌存儲系統上面搭建一套DSL分析引擎，能夠加入常用的運算元，同時還能分布式執行這些運算，同時快速的返回結果，曾經想過用MLSQL載入日誌的數據然後用sql分析完將結果取回，這其實也是一條很好的思路，雖然MLSQL不需要每次都提交spark作業的過程，但是搬運數據還是會犧牲掉一部分時效性，好處是計算和存儲是分離的，同時我還希望日誌平台能夠實時的監聽一些我感興趣的日誌事件，然後在自定義的dashboard中展示，支持報警等等。
最近1-2年一直在研究探索更具性價比的日誌管理平台，後續會將一些心得體會、解決方案記錄下來跟大家分享。