好久沒更新。本次主題與玩耍過程滿開心的，分享給各位。已經熟練的朋友就笑笑，看看小弟為何套用這樣的情境。一本道初衷，還是非常基礎的從頭到尾弄一遍，包含耗我兩小時的一個小坑。
商業上遇到要查詢長串文字的需求，然而這樣的資料是存放在RDB SQL server內的資料。初時小弟陷入深思長考：直接RDB的套件如何滿足呢？其間包含甚至研究了apache HUE、R shiny套件(謝謝Carlos大大)、Google sheet API等等，目的是為了讓user 能夠自由用web browser作簡易查詢，並且UI要能夠非常的簡單好操作。再來，退一步的幕後，要非常能夠簡單維護，不然小弟平常打混的時間就被剝奪了(沒啦其實上班很認真XD)。
這倒真的陷入痛苦掙扎…. 不過回到維護懶惰、user易用的必須條件，小弟一一的剔除了選項。就在山窮水盡之時，我回到最原始的思考： 長串文字查詢，簡單易用UI ，我怎麼有點熟悉感！就像看到波多野結衣一樣，這莫名的熟悉感是怎麼回事？忽然靈光閃現
是 Elasticsearch Logstash Kibana 簡稱 ELK 小弟很熟悉的工具啊！
是的，原來是老朋友啊… 主要的思考盲區在於，已經在RDB的東西，小弟認為已經是相對終端的存在，為什麼還要「反過來」拉進 Elasticsearch呢？好的，這個基本觀念可以參考小弟拙作，包含作者本身的在下我，也陷入思考盲區。重新複習：
只要是data lake內，理論上應該相互透通，能維持資料的維護、管理、與方便使用，是最大的原則。那麼，由RDB SQL database拉進 Elasticsearch 又有何不可！一開始覺得這樣的作法很北七，後來發現原來是小弟我北七…. 有類似想法的朋友們不如看完系列吧。
以下就簡述好處與為什麼這樣做
- 免費
- 使用者易用
- 維護方便
- 文字搜尋強化
- 效能佳
- 分散db loading
- 減少我回應需求的時間
當然也是有缺點的
- 多了一個data end point
- 多了一個維護應用
- 多了使用者教育時間
很多技術堅持，是為了使用者需求的堅持與所有人的時間、精神成本節約，才有意義。小弟固然可以不管db like查詢的I/O，也可以裝模作樣讓自己有事情做，有ticket看起來好像很有產值。但這些都比不上user真心想查就查，想看就看，想胡就胡，方便爽快的快樂反饋。有時候這樣的反饋力量是大於ticket上的虛無飄渺KPI的喔。可以參考。
接下來，我將在下一篇引導各位安裝。 畢竟是 ELK 新的版本 7.5.0啊！幹我說第二沒人敢說最新啊，哈哈哈哈哈！
下一篇
PS 在此也感謝參考資料與各位無私的大大，小弟站在你們的肩膀才能望得更遠。
Originally published at http://datamansamxiao.wordpress.com on December 5, 2019.
