1.結(jié)構(gòu)名稱不同
10年的興慶網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。營銷型網(wǎng)站建設(shè)的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整興慶建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“興慶網(wǎng)站設(shè)計”,“興慶網(wǎng)站推廣”以來，每個客戶項目都認(rèn)真落實執(zhí)行。
2.ES分布式搜索，傳統(tǒng)數(shù)據(jù)庫遍歷式搜索
3.ES采用倒排索引，傳統(tǒng)數(shù)據(jù)庫采用B+樹索引
4.ES沒有用戶驗證和權(quán)限控制
5.ES沒有事務(wù)的概念，不支持回滾，誤刪不能恢復(fù)
6.ES免費，完全開源；傳統(tǒng)數(shù)據(jù)庫部分免費
有關(guān)更詳細(xì)的比較內(nèi)容，可以到黑馬程序員官網(wǎng)找到社區(qū)技術(shù)文章，找不到可以對話框問一下。里面還有結(jié)合工作的舉例。
ES6 是一種 JS 的規(guī)范化， JS 是 ES 的拓展。
TS 是一種 JS 的類型補充。
Web 中的 JS = ES + Web API ( DOM + BOM )
Node 中的 JS = ES + Node API ( fs + Net + etc )
TS = JS + 類型系統(tǒng)
如下圖 3.1
ES6 中推出了兩個新的關(guān)鍵字 let 、const 。
因為 var 存在變量提升，所以在定義之前調(diào)用變量不會報錯，而是會得到一個 undefined 。這在很多編碼過程中看來，是不合理的，因為變量先定義后使用，才是符合正常的思維邏輯的。故而推出了兩個關(guān)鍵字?let 、const?。
兩者都沒有變量提升，因為閉包機制， 所以只在聲明位置所屬的塊作用域內(nèi)生效。
Proxy? 可以理解為監(jiān)聽器 ， 攔截器， 可以修改對象原本的方法?？梢酝ㄟ^構(gòu)造函數(shù)的方法使用，也可以在對象內(nèi)部定義為? Proxy? 屬性的方式來調(diào)用。
Proxy 兩種使用方法
Proxy? 傳入兩個參數(shù)，都是對象格式。? target? 是被攔截的對象， handler? 中盛放了攔截 target? 的方法。如果被攔截的對象是一個空對象，那么在使用構(gòu)造函數(shù)調(diào)用時候，可以用構(gòu)造對象調(diào)用攔截方法會產(chǎn)生相同效果。
target為空對象情況
Reflect
Reflect? 是一種新的? API? ，將Object對象的屬于語言內(nèi)部的方法放到 Reflect? 對象上，即從? Reflect? 對象上拿? Object? 對象內(nèi)部方法。
將用老? Object? 方法報錯的情況，改為返回? false 。
讓 Object? 操作變成函數(shù)行為。
Reflect? 和? Proxy? 有著一樣的方法，兩者可以相輔相成 。
圖片引自阮一峰 ES6
這樣的操作使得攔截操作更為合理，把攔截的操作交給? Reflect? ，而? Proxy? 的功能主要為輸出日志。
Set? ?不重復(fù)集合。
Symbol 具有唯一性，可以作為對象的 key ，避免重復(fù)。
生成器 Generator ： 內(nèi)部可以通過 yeld 來分步執(zhí)行。返回一個對象 { value， done}。
有些聚合分析的算法，是很容易就可以并行的，比如說max
有些聚合分析的算法，是不好并行的，比如說，count(distinct)，并不是說，在每個node上，直接就出一些distinct value，就可以的，因為數(shù)據(jù)可能會很多，假設(shè)圖中的協(xié)調(diào)節(jié)點3百萬個數(shù)據(jù)去重后還剩下100萬distinct的數(shù)據(jù)，那么內(nèi)存需要來存儲這100萬條數(shù)據(jù)，這是不可能的
es會采取近似聚合的方式，就是采用在每個node上進行近估計的方式，得到最終的結(jié)論，cuont(distcint)，100萬，1050萬/95萬 -- 5%左右的錯誤率
近似估計后的結(jié)果，不完全準(zhǔn)確，但是速度會很快，一般會達(dá)到完全精準(zhǔn)的算法的性能的數(shù)十倍
precision_threshold優(yōu)化準(zhǔn)確率和內(nèi)存開銷
brand去重，如果brand的unique value，在100個以內(nèi)，小米，長虹，三星，TCL，HTL。。。
在多少個unique value以內(nèi)，cardinality，幾乎保證100%準(zhǔn)確
cardinality算法，會占用precision_threshold * 8 byte 內(nèi)存消耗，100 * 8 = 800個字節(jié)
占用內(nèi)存很小。。。而且unique value如果的確在值以內(nèi)，那么可以確保100%準(zhǔn)確
100，數(shù)百萬的unique value，錯誤率在5%以內(nèi)
precision_threshold，值設(shè)置的越大，占用內(nèi)存越大，1000 * 8 = 8000 / 1000 = 8KB，可以確保更多unique value的場景下，100%的準(zhǔn)確
field，去重，count，這時候，unique value，10000，precision_threshold=10000，10000 * 8 = 80000個byte，80KB
doc value正排索引
搜索+聚合 是怎么實現(xiàn)的？
假設(shè)是倒排索引實現(xiàn)的
倒排索引來實現(xiàn)是非常不現(xiàn)實的，因為我們搜索的那個字段search_field 有可能是分詞的，這就需要去掃描整個索引才能實現(xiàn)聚合操作，效率是及其低下的。
正排索引結(jié)構(gòu)：
doc2: agg1
doc3: agg2
1萬個doc -- 搜 - 可能跟搜索到10000次，就搜索完了，就找到了1萬個doc的聚合field的所有值了，然后就可以執(zhí)行分組聚合操作了
doc value原理
1、doc value原理
（1）index-time生成
PUT/POST的時候，就會生成doc value數(shù)據(jù)，也就是正排索引
（2）核心原理與倒排索引類似
正排索引，也會寫入磁盤文件中，然后呢，os cache先進行緩存，以提升訪問doc value正排索引的性能
如果os cache內(nèi)存大小不足夠放得下整個正排索引，doc value，就會將doc value的數(shù)據(jù)寫入磁盤文件中
（3）性能問題：給jvm更少內(nèi)存，64g服務(wù)器，給jvm最多16g
es官方是建議，es大量是基于os cache來進行緩存和提升性能的，不建議用jvm內(nèi)存來進行緩存，那樣會導(dǎo)致一定的gc開銷和oom問題
給jvm更少的內(nèi)存，給os cache更大的內(nèi)存
64g服務(wù)器，給jvm最多16g，幾十個g的內(nèi)存給os cache
os cache可以提升doc value和倒排索引的緩存和查詢效率
2、column壓縮
doc1: 550
doc2: 550
doc3: 500
合并相同值，550，doc1和doc2都保留一個550的標(biāo)識即可
（1）所有值相同，直接保留單值
（2）少于256個值，使用table encoding模式：一種壓縮方式
（3）大于256個值，看有沒有最大公約數(shù)，有就除以最大公約數(shù)，然后保留這個最大公約數(shù)
重點：
對分詞的field，直接執(zhí)行聚合操作，會報錯，大概意思是說，你必須要打開fielddata，然后將正排索引數(shù)據(jù)加載到內(nèi)存中，才可以對分詞的field執(zhí)行聚合操作，而且會消耗很大的內(nèi)存
先修改 字段的fielddata屬性為true,再查 就能查找到數(shù)據(jù)
當(dāng)然，我們也可以使用內(nèi)置field(keyword)不分詞，對string field進行聚合,如果對不分詞的field執(zhí)行聚合操作，直接就可以執(zhí)行，不需要設(shè)置fieldata=true
分詞field+fielddata的工作原理
doc value -- 不分詞的所有field，可以執(zhí)行聚合操作 -- 如果你的某個field不分詞，那么在index-time，就會自動生成doc value -- 針對這些不分詞的field執(zhí)行聚合操作的時候，自動就會用doc value來執(zhí)行
分詞field，是沒有doc value的。。。在index-time，如果某個field是分詞的，那么是不會給它建立doc value正排索引的，因為分詞后，占用的空間過于大，所以默認(rèn)是不支持分詞field進行聚合的
分詞field默認(rèn)沒有doc value，所以直接對分詞field執(zhí)行聚合操作，是會報錯的
對于分詞field，必須打開和使用fielddata，完全存在于純內(nèi)存中。。。結(jié)構(gòu)和doc value類似。。。如果是ngram或者是大量term，那么必將占用大量的內(nèi)存。。。
如果一定要對分詞的field執(zhí)行聚合，那么必須將fielddata=true，然后es就會在執(zhí)行聚合操作的時候，現(xiàn)場將field對應(yīng)的數(shù)據(jù)，建立一份fielddata正排索引，fielddata正排索引的結(jié)構(gòu)跟doc value是類似的，
但是只會講fielddata正排索引加載到內(nèi)存中來，然后基于內(nèi)存中的fielddata正排索引執(zhí)行分詞field的聚合操作
如果直接對分詞field執(zhí)行聚合，報錯，才會讓我們開啟fielddata=true，告訴我們，會將fielddata uninverted index，正排索引，加載到內(nèi)存，會耗費內(nèi)存空間
為什么fielddata必須在內(nèi)存？因為大家自己思考一下，分詞的字符串，需要按照term進行聚合，需要執(zhí)行更加復(fù)雜的算法和操作，如果基于磁盤和os cache，那么性能會很差
我們是不是可以預(yù)先生成加載fielddata到內(nèi)存中來？？？
query-time的fielddata生成和加載到內(nèi)存，變?yōu)閕ndex-time，建立倒排索引的時候，會同步生成fielddata并且加載到內(nèi)存中來，這樣的話，對分詞field的聚合性能當(dāng)然會大幅度增強
重慶分公司
重慶分公司
