關于es與sqlserver的信息

ES與傳統數據庫的比較

1.結構名稱不同

10年的興慶網站建設經驗，針對設計、前端、開發、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。營銷型網站建設的優勢是能夠根據用戶設備顯示端的尺寸不同，自動調整興慶建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現優雅布局與設計，從而大程度地提升瀏覽體驗。成都創新互聯從事“興慶網站設計”,“興慶網站推廣”以來，每個客戶項目都認真落實執行。

2.ES分布式搜索，傳統數據庫遍歷式搜索

3.ES采用倒排索引，傳統數據庫采用B+樹索引

4.ES沒有用戶驗證和權限控制

5.ES沒有事務的概念，不支持回滾，誤刪不能恢復

6.ES免費，完全開源；傳統數據庫部分免費

有關更詳細的比較內容，可以到黑馬程序員官網找到社區技術文章，找不到可以對話框問一下。里面還有結合工作的舉例。

ES 與 TS

ES6 是一種 JS 的規范化， JS 是 ES 的拓展。

TS 是一種 JS 的類型補充。

Web 中的 JS = ES + Web API ( DOM + BOM )

Node 中的 JS = ES + Node API ( fs + Net + etc )

TS = JS + 類型系統

如下圖 3.1

ES6 中推出了兩個新的關鍵字 let 、const 。

因為 var 存在變量提升，所以在定義之前調用變量不會報錯，而是會得到一個 undefined 。這在很多編碼過程中看來，是不合理的，因為變量先定義后使用，才是符合正常的思維邏輯的。故而推出了兩個關鍵字?let 、const?。

兩者都沒有變量提升，因為閉包機制， 所以只在聲明位置所屬的塊作用域內生效。

Proxy? 可以理解為監聽器 ， 攔截器， 可以修改對象原本的方法。可以通過構造函數的方法使用，也可以在對象內部定義為? Proxy? 屬性的方式來調用。

Proxy 兩種使用方法

Proxy? 傳入兩個參數，都是對象格式。? target? 是被攔截的對象， handler? 中盛放了攔截 target? 的方法。如果被攔截的對象是一個空對象，那么在使用構造函數調用時候，可以用構造對象調用攔截方法會產生相同效果。

target為空對象情況

Reflect

Reflect? 是一種新的? API? ，將Object對象的屬于語言內部的方法放到 Reflect? 對象上，即從? Reflect? 對象上拿? Object? 對象內部方法。

將用老? Object? 方法報錯的情況，改為返回? false 。

讓 Object? 操作變成函數行為。

Reflect? 和? Proxy? 有著一樣的方法，兩者可以相輔相成 。

圖片引自阮一峰 ES6

這樣的操作使得攔截操作更為合理，把攔截的操作交給? Reflect? ，而? Proxy? 的功能主要為輸出日志。

Set? ?不重復集合。

Symbol 具有唯一性，可以作為對象的 key ，避免重復。

生成器 Generator ： 內部可以通過 yeld 來分步執行。返回一個對象 { value， done}。

es使用與原理6 -- 聚合分析剖析

有些聚合分析的算法，是很容易就可以并行的，比如說max

有些聚合分析的算法，是不好并行的，比如說，count(distinct)，并不是說，在每個node上，直接就出一些distinct value，就可以的，因為數據可能會很多，假設圖中的協調節點3百萬個數據去重后還剩下100萬distinct的數據，那么內存需要來存儲這100萬條數據，這是不可能的

es會采取近似聚合的方式，就是采用在每個node上進行近估計的方式，得到最終的結論，cuont(distcint)，100萬，1050萬/95萬 -- 5%左右的錯誤率

近似估計后的結果，不完全準確，但是速度會很快，一般會達到完全精準的算法的性能的數十倍

precision_threshold優化準確率和內存開銷

brand去重，如果brand的unique value，在100個以內，小米，長虹，三星，TCL，HTL。。。

在多少個unique value以內，cardinality，幾乎保證100%準確

cardinality算法，會占用precision_threshold * 8 byte 內存消耗，100 * 8 = 800個字節

占用內存很小。。。而且unique value如果的確在值以內，那么可以確保100%準確

100，數百萬的unique value，錯誤率在5%以內

precision_threshold，值設置的越大，占用內存越大，1000 * 8 = 8000 / 1000 = 8KB，可以確保更多unique value的場景下，100%的準確

field，去重，count，這時候，unique value，10000，precision_threshold=10000，10000 * 8 = 80000個byte，80KB

doc value正排索引

搜索+聚合 是怎么實現的？

假設是倒排索引實現的

倒排索引來實現是非常不現實的，因為我們搜索的那個字段search_field 有可能是分詞的，這就需要去掃描整個索引才能實現聚合操作，效率是及其低下的。

正排索引結構：

doc2: agg1

doc3: agg2

1萬個doc -- 搜 - 可能跟搜索到10000次，就搜索完了，就找到了1萬個doc的聚合field的所有值了，然后就可以執行分組聚合操作了

doc value原理

1、doc value原理

（1）index-time生成

PUT/POST的時候，就會生成doc value數據，也就是正排索引

（2）核心原理與倒排索引類似

正排索引，也會寫入磁盤文件中，然后呢，os cache先進行緩存，以提升訪問doc value正排索引的性能

如果os cache內存大小不足夠放得下整個正排索引，doc value，就會將doc value的數據寫入磁盤文件中

（3）性能問題：給jvm更少內存，64g服務器，給jvm最多16g

es官方是建議，es大量是基于os cache來進行緩存和提升性能的，不建議用jvm內存來進行緩存，那樣會導致一定的gc開銷和oom問題

給jvm更少的內存，給os cache更大的內存

64g服務器，給jvm最多16g，幾十個g的內存給os cache

os cache可以提升doc value和倒排索引的緩存和查詢效率

2、column壓縮

doc1: 550

doc2: 550

doc3: 500

合并相同值，550，doc1和doc2都保留一個550的標識即可

（1）所有值相同，直接保留單值

（2）少于256個值，使用table encoding模式：一種壓縮方式

（3）大于256個值，看有沒有最大公約數，有就除以最大公約數，然后保留這個最大公約數

重點：

對分詞的field，直接執行聚合操作，會報錯，大概意思是說，你必須要打開fielddata，然后將正排索引數據加載到內存中，才可以對分詞的field執行聚合操作，而且會消耗很大的內存

先修改 字段的fielddata屬性為true,再查 就能查找到數據

當然，我們也可以使用內置field(keyword)不分詞，對string field進行聚合,如果對不分詞的field執行聚合操作，直接就可以執行，不需要設置fieldata=true

分詞field+fielddata的工作原理

doc value -- 不分詞的所有field，可以執行聚合操作 -- 如果你的某個field不分詞，那么在index-time，就會自動生成doc value -- 針對這些不分詞的field執行聚合操作的時候，自動就會用doc value來執行

分詞field，是沒有doc value的。。。在index-time，如果某個field是分詞的，那么是不會給它建立doc value正排索引的，因為分詞后，占用的空間過于大，所以默認是不支持分詞field進行聚合的

分詞field默認沒有doc value，所以直接對分詞field執行聚合操作，是會報錯的

對于分詞field，必須打開和使用fielddata，完全存在于純內存中。。。結構和doc value類似。。。如果是ngram或者是大量term，那么必將占用大量的內存。。。

如果一定要對分詞的field執行聚合，那么必須將fielddata=true，然后es就會在執行聚合操作的時候，現場將field對應的數據，建立一份fielddata正排索引，fielddata正排索引的結構跟doc value是類似的，

但是只會講fielddata正排索引加載到內存中來，然后基于內存中的fielddata正排索引執行分詞field的聚合操作

如果直接對分詞field執行聚合，報錯，才會讓我們開啟fielddata=true，告訴我們，會將fielddata uninverted index，正排索引，加載到內存，會耗費內存空間

為什么fielddata必須在內存？因為大家自己思考一下，分詞的字符串，需要按照term進行聚合，需要執行更加復雜的算法和操作，如果基于磁盤和os cache，那么性能會很差

我們是不是可以預先生成加載fielddata到內存中來？？？

query-time的fielddata生成和加載到內存，變為index-time，建立倒排索引的時候，會同步生成fielddata并且加載到內存中來，這樣的話，對分詞field的聚合性能當然會大幅度增強

分享題目：關于es與sqlserver的信息
文章源于：http://m.kartarina.com/article16/hdopgg.html

成都網站建設公司_創新互聯，為您提供自適應網站、域名注冊、定制網站、網站策劃、標簽優化、網站維護

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯