很久以前寫過一篇基本的 mongodb group 語法的基本介紹，在這些年間也持續跟 mongodb 持續纏鬥無法自拔…，對他又愛又恨，雖然超想拔掉他，但是從用途/功能性上卻無法找到他的取代品。
如今已經面臨要開始用他來 JOIN 了，感覺這毒是越吸越重了..XD 讓我們繼續看下去..
我們今天試著從 3.2 開始 aggregate 新支援的語法 $lookup 搭配 3.6 開始的 lookup pipeline 來解決我們需要 LEFT JOIN 的問題。
Continue reading…
如同前文所述，我在電商產業工作，近年來隨著公司的發展，開始將研發的重點強調在數據與 AI 的應用上，因此資料的蒐集儲存的彈性就需要不段的擴增，來滿足斷續分析與應用的需求。
近一年的工作有一半是在做資料的處理/整合，記錄一下工作上 data pipeline 的需求與演進，概念上就是如何從基本的 rds 進化成可以擴展到適合大數據分析的資料庫架構。
Continue reading…
目前在日常生活偶爾會使用 mongodb 做一些開發或存一些 log，除了基本的 json query 以外，偶爾需要用到如 mysql 的 group 功能，剛開始覺得好像沒有辦法直接用 query 做很困擾，實際做過一次複雜的 query 以後才發現 mongodb 的彈性實在是強大不少，除了語法不相容要重學以外。
舉一個實際的例子，有一個表存了 web 的 access log，然後想找到哪個頁面(page)最常被存取，按照頁面的存取次序排序，每一個人在一天存取同個頁面多次都只能算一次（不重複的工作階段 in GA），而且要排除特定 IP 不被計算（自己）。
在 SQL 裡面直覺寫出來大概會是這樣：
SELECT page, count(*) count FROM access_log WHERE IP != '192.168.1.1' GROUP BY page ORDER BY count DESC limit 10
雖然簡單，但是這個寫法沒有過濾掉，不重複計算同個人的重複瀏覽，所以直覺也是用子查詢才能解決這個問題。
Continue reading…