資料模型是抽象描述現實世界的一種工具和方法，是通過抽象實體及實體之間聯絡的形式，用圖形化的形式去描述業務規則的過程，從而表示現實世界中事務以及相互關係的一種對映。
核心概念：
實體：現實世界中存在的可以相互區分的事物或概念稱為實體。
實體可以分為事物實體和概念實體。例如：乙個學生、乙個程式設計師等是事物實體。一門課、乙個班級等稱為概念實體。
實體的屬性：每個實體都有自己的特徵，利用實體的屬性可以描述不同的實體。例如。學生實體的屬性為姓名、性別、年齡等
資料建模大致分為三個階段，概念建模階段，邏輯建模階段和物理建模階段。
概念建模階段
概念建模階段，主要做三件事：
客戶交流
理解需求
形成實體
確定系統的核心需求和範圍邊界，設計實體與實體之間的關係。
在概念建模階段，我們只需要關注實體即可，不用關注任何實現細節。很多人都希望在這個階段把具體表結構，索引，約束，甚至是儲存過程都想好，沒必要！因為這些東西是我們在物理建模階段需要考慮的東西，這個時候考慮還為時尚早。概念模型在整個資料建模時間佔比：10%左右
邏輯建模階段
邏輯建模階段，主要做二件事：
進一步梳理業務需求
確定每個實體的屬性、關係和約束等。
邏輯模型是對概念模型的進一步分解和細化，描述了實體、實體屬性以及實體之間的關係，是概念模型
延伸，一般的邏輯模型有第三正規化，星型模型和雪花模型。模型的主要元素為主題、實體、實體屬性和關係。
雪花模型和星狀模型的主要區別是維度的層級 標準的星狀模型只有一層 而雪花模型可能涉及多層。
邏輯模型的作用主要有兩點。
一是便於技術開發人員和業務人員以及使用者進行溝通 交流，使得整個概念模型更易於理解，進一步明確需求。
二是作為物理模型設計的基礎，由於邏輯模型不依賴於具體的資料庫實現，使用邏輯模型可以生成針對具體 資料庫管理系統的物理模型，保證物理模型充分滿足使用者的需求。
邏輯模型在整個資料建模時間佔比：60—70%左右。
物理建模階段
物理建模階段，主要做一件事：
結合具體的資料庫產品（mysql/oracle/mongo/elasticsearch），在滿足業務讀寫效能等需求的前提下
確定最終的定義。
物理模型是在邏輯模型的基礎上描述模型實體的細節，包括資料庫產品對應的資料型別、長度、索引等因素，為邏輯模型選擇乙個最優的物理儲存環境。
邏輯模型轉化為物理模型的過程也就是實體名轉化為表名，屬性名轉化為物理列名的過程。
在設計物理模型時，還需要考慮資料儲存空間的分配，包括對列屬性必須做出明確的定義
例如：客戶姓名的資料型別是varchar2，長度是20，儲存在oracle資料庫中，並且建立索引用於提高該欄位的查詢效率。物理模型在整個資料建模時間佔比：20—30%左右
資料模型支撐了系統和資料，系統和資料支撐了業務系統。
乙個好的資料模型：
能讓系統更好的整合、能簡化介面。
能簡化資料冗餘 、減少磁碟空間、提公升傳輸效率。
相容更多的資料，不會因為資料型別的新增而導致實現邏輯更改。
能幫助更多的業務機會，提高業務效率。
能減少業務風險、降低業務成本
舉例: 借助logstash實現mysql到elasticsearch的增量同步，如果資料建模階段沒有設計時間戳或者自增id，就幾乎無法實現
}}（2）data denormalization（資料的非規範化）
這種方式，通俗點就是通過字段冗餘，以一張大寬表來實現粗粒度的index，這樣可以充分發揮扁平化的優勢。但是這是以犧牲索引效能及靈活度為代價的。使用的前提：冗餘的字段應該是很少改變的，比較適合與一對少量關係的處理。當業務資料庫並非採用非規範化設計時，這時要將資料同步到作為二級索引庫的es中，就需要進行定製化開發，基於特定業務進行應用開發來處理join關聯和實體拼接。
說明：寬表處理在處理一對多、多對多關係時，會有字段冗餘問題，適合「一對少量」且這個「一」更新不頻繁的應用場景
（3）nested objects（巢狀文件）put/user/_doc/
1put
/blogpost/_doc/2}
get/blogpost/_search},
}]}}
}
索引效能和查詢效能二者不可兼得，必須進行取捨。巢狀文件將實體關係巢狀組合在單文件內部，這種
方式犧牲建立索引效能（文件內任一屬性變化都需要重新索引該文件）來換取查詢效能，比較適合於一
對少量的關係處理
當使用巢狀文件時，使用通用的查詢方式是無法訪問到的，必須使用合適的查詢方式（nested query、
nested filter、nested facet等），很多場景下，使用巢狀文件的複雜度在於索引階段對關聯關係的組
織拼裝。
（4）parent/child relationships（父子文件）put/drivers
,"vehicle":,
"model":}
}}}}
}}put/drivers/_doc/1,
]}}put
/drivers/_doc/
2?refresh,]
}}get/drivers/_search},
}]}}
}}}}
}
父子文件犧牲了一定的查詢效能來換取索引效能,適用於寫多讀少的場景。父子文件相比巢狀文件較靈
活，適用於「一對大量」且這個「一」不是海量的應用場景，該方式比較耗記憶體和cpu，這種方式查詢比嵌
套方式慢5~10倍，且需要使用特定的has_parent和has_child過濾器查詢語法，查詢結果不能同時返回
父子文件（一次join查詢只能返回一種型別的文件）。受限於父子文件必須在同一分片上(可以通過
routing指定父文件id即可)操作子文件時需要指定routing
put my_index}}}}#插入父文件
put/my_index/_doc/
1?refresh
}put
/my_index/_doc/
2?refresh
#插入子文件
put/my_index/_doc/
3?routing=
1}
post my_index/_search}}}}
get my_index/_search}}
Elasticsearch 搜尋資料
elasticsearch 修改資料 elasticsearch 搜尋資料 現在我們已經了解了基本知識，讓我們嘗試使用更真實的資料。我們提供了一些虛構的客戶銀行賬戶資訊，格式如下所示 curl localhost 9200 cat indices?v 響應 health status index u...
二 elasticsearch入門（資料）
程式中大多的實體或物件能夠被序列化為包含鍵值對的json物件，鍵 key 是字段 field 或屬性 property 的名字，值 value 可以是字串 數字 波爾型別 另乙個物件 值陣列或者其他特殊型別，比如表示日期的字串或者表示地理位置的物件。accounts 文件元資料 乙個文件不只有資料。...
elasticSearch修改資料
elasticsearch幾乎能實時提供資料操作和搜尋功能。預設情況下，從開始索引 更新 刪除資料到出現搜尋結果的時間可以認為需要一秒的時間。這是與sql等其他平台的重要區別，其中資料在事務完成後可以立即使用。在上節中我們給索引建立了乙個文件，命令為 put customer doc 1 prett...