將日期格式對映為「strict_date_optional_time||epoch_millis」，在輸入資料「2003/4/7」時，提示如下錯誤：
type: "illegal_argument_exception", reason: "invalid format: "
2003/4/7
" is malformed at "/4/7
""檢閱文件，提示日期可以為以下三種格式：
1. 2015-01-01[文字格式];
2. 2015-01-01t12:10:30z[文字格式];
3. 1420070400001[數字格式];
針對文字格式，對間隔符的要求不高，無論是「-」還是「/」都能自動識別，但是字元的位數要嚴格匹配，例如本例中出錯的原因就在於「2003/4/7」位數不全，應該補齊為「2003/04/07」。
將位置資訊宣告為「geo_point」時，提交如下的資料：
"addr_geo" : ["24.31", "117.39"]],
,"reason":"failed to parse"
,"caused_by":},
"status":400
}
elasticsearch支援的地理資料格式有兩種：
1. 陣列代表的經緯度資料[lon, lat]，經度在前，維度在後；
2. json物件格式的經緯度資料，
需要注意的是，這兩種格式都要求資料為number，不可是字串，否則可能會出現解析錯誤。
另外，南緯與西經為負值，北緯與東經為正值，所以維度的取值範圍是[-90, 90]，經度的取值範圍為[-180, 180]，如果不好記憶，請記住處於東經北半球的中國的經緯度資訊(都是正數):
1. 經度範圍：[73.66, 135.05]
2. 維度範圍：[3.86， 53.55]
解決resultMap對映資料錯誤的問題
目錄 maaubtylfupper檔案使用了resultmap進行一對多關係對映，不管怎麼配置 沒有問題 sql語句查詢出來的結果，和呼叫mapper 物件產生的entry資料就是不一致。在mapper的sql語句中加上order by。資料庫改了乙個欄位的名字，後來牽扯到實體類標準化都要改，原來以...
redis底層設計（二） 記憶體對映資料結構
上篇我們講了內部資料結構，雖然內部資料結構非常強大，但是建立一系列完整的資料結構本身也是一件相當耗費時間的工作，當乙個物件包含的元素數量並不多，或者元素本身的體積並不大時，使用代價高昂的內部資料結構並不是最好的辦法。因此我們會用記憶體對映資料結構來代替內部資料結構。記憶體對映資料結構是一系列經過特殊...
資料分析中會常犯哪些錯誤，如何解決？ 二
截圖說話 譁眾取寵的美國fox news經常用的一些招數。這些招數更多的是從視覺上給人一種 錯覺 比如說，本來不大的差異，截掉y軸的一部分，瞬間差異就會讓看的人覺得 差得這麼多！想象你明天要跟你的經理作報告，手裡有一堆結果，但是顯然這些結果對於之前的方法只有邊際的增長 好訊息是，你幾乎一定可以找到乙...