Search
［2017年就說要賣你，三年後，2020年才準備要交貨？］
（摘自內文）
我國在2017年6月獲美國川普政府批准出售反制偵蒐雷達的「AGM-88B」空射反輻射飛彈，合約總值1.38億美金，而美國洛克希德馬丁公司對內容進行修改，將為台灣F-16戰機提供改良後的「AGM-88E」飛彈。
（解讀新聞）
電子戰，背景資料庫及敵電磁輻射資料庫，是決定電子戰成敗的關鍵。即使同樣的裝備，在不同的場域，因為經緯度及地形等因素，電磁輻射的表現，也會不同。
用了三年時間，建立精準資料庫及反輻射運算法則，安裝在目前還在生產且可支援所需功能的硬體上，是賣方負責任的基本款。
（延伸閱讀）
AGM-88E飛彈功能強大！ 王定宇：甚至可攻擊已關機雷達
https://news.ltn.com.tw/news/politics/breakingnews/3514388
現在大家使用 Funliday-旅遊規劃 在「景點瀏覽」輸入城市，或者是移動地圖出現的推薦景點，應該都是即時出現，也是最近花了一些時間的成果。下面先筆記一下推薦景點開發的歷程，之後如果有機會應該可以到 PostgreSQL.TW 分享一下完整的內容。
簡單來說，就是一個從 70000ms 的 response time，提升到 200ms 的 response time 過程。
---
## 2019/02 推薦景點第一版
https://www.facebook.com/kewang.information/posts/2268138753462486
## 2019/09 late 加上使用者查詢的 poi history 到推薦景點
1. 如果該 city 最近 30 天的 poi history 景點超過 10 個，則直接使用
2. 如果該 city 最近 30 天的 poi history 景點小於等於 10 個，則加上 KNN+rating 算法所取出的 poi 一起回傳給使用者
3. 使用網路上找到的 uniq，將 poi history 的景點及 KNN+rating 算法的景點去除重覆資料
4. 會將計算後取出的 poi id 存入 Redis，TTL 為 1 天
## 2020/06 late 加快查詢速度
1. 將原本要從 poi_data (超過 2500 萬筆的 POI) 取得 city 的 bbox，改從 city_data (約 200 萬筆的 city) 取得，加快查詢速度
## 2020/07 late 刪除不正確的 poi
1. 刪除該 city 經過 poi history 計算後 count 為 0 的 poi
2. 刪除部分不該出現在推薦景點上的景點類型，如：飲水機、球場、停車場...等
3. 將 KNN+rating 的景點 TTL 設定為 14 天，而從 poi history 計算出來的景點 TTL 一樣為 1 天
## 2020/09 late 重構推薦景點功能，並加上 L2, L3 cache
### 2020/09/22 late 重構推薦景點功能
1. 先從 Redis 取出確認該 city 是否有 cache，有的話就直接回傳，沒有的話寫入 refresh = true 的 flag 到 city_data table，表示該 city 資料必須更新
2. 從 DB 取出確認該 city 是否有 cache，有的話就直接回傳，沒有的話就必須即時計算該 city 的推薦景點
3. 推薦景點的算法與之前相同，包括了 poi history 及 KNN+rating，但移除 uniq，改用 Set 的寫法去除重覆資料
4. 計算完該 city 的推薦景點之後，直接將資料存回 Redis 及 DB，並且回傳計算完的推薦景點
5. 期望這樣跑下來後，之後使用者就算在 Redis 找不到 cache (因為過期)，也可以從 DB 找到 cache (因為不會消失)
6. 每天固定跑 scheduler，掃出 refresh flag 為 true 的 city，在 background job 將最新的推薦景點寫回 Redis 及 DB，並將 refresh flag 設定為 false
### 2020/09/23 early 加快預熱 cache 到 DB 的速度
1. 因為目前在 Redis 還有部分 city 的 cache，如果要等一天 (TTL) 之後這些 cache 失效後才能啟動 L2 cache 機制會有點浪費
2. 所以增加若在 Redis 確認該 city 有 cache 且 DB 沒 cache 的話，就將該 cache 寫回 DB，並且回傳
### 2020/09/23 middle 確認是否有最佳化空間
1. 延長 city Redis cache 的 TTL 從 1 天增加到 14 天，避免部分活動過於熱門，導致該區域的推薦景點都被該活動洗掉
### 2020/09/24 early 加上 new relic
1. 加上 new relic 的 custom attributes，記錄該 city 的 IO 相關讀取時間
### 2020/09/24 middle 加上 local cache
1. 因為從 Redis 或 DB 取回來的 id 要再經過一次 DB 查詢，才能組合完整的 response 回傳
2. 所以加上 city id 及使用者語言做為 local cache key，加快同 city id 且同語言的資料回傳速度
3. 如果 city id 或使用者語言在該 cache 找不到，再回 DB 查詢
4. 加上 new relic 的 custom segment，方便判讀 request 的瓶頸是在哪一段
### 2020/09/24 late 調整 poi history 的執行速度
1. 將原本使用 where + group 取得最近 30 的 poi history 語法，改為先做 where，再做 group，將原本放在同一個 CTE 的 query 拆成兩個 CTE 執行
2. 速度從原本的 40 ~ 50 秒，甚至到 70 秒，下降到約 10 秒左右
### 2020/09/25 early 移除不必要的 middleware
1. 在整整一年前將 poi recommend 及 search 拆開成不同檔案的時候，沒有仔細確認，所以每次 request 都要到 Redis 做兩次的 auth check
2. 所以將其中一個 auth check 拿掉，加快約 1ms
### 2020/09/27 early 再次檢視 poi history 計算方式是否有最佳化空間
1. 原本在使用經緯度計算是哪個 city 時，查詢速度大約都 400ms 左右，加上 GiST index 之後，查詢速度提升 1000x，變成只要 0.4ms 就能算出來
2. 整整一年前導入 poi history 到推薦景點時，資料量還沒這麼大，所以在計算時速度都蠻快的
3. 但 poi history 現在資料筆數已經超過 2500 萬筆，都變成 Seq Scan，雖然 planner 會判斷成 Parallel Seq Scan，但速度還是很慢
4. 因為是使用近 30 天的資料做計算，所以將 created_at 加入 index，速度從 10 秒左右降到 1 秒左右
#postgresql #newrelic #redis
很實用的座標定位APP，最新測試版本發佈，Android用戶可以下載體驗看看，用心的團隊就給推～
#小編很雞婆的重新排版了一下貼文
#重點也有幫大家標出來了
=================================
[台灣大地羅盤 2.6 Beta 測試版] 發佈囉！ 🎉🎉🎉
立即加入測試計畫搶先體驗:
https://play.google.com/apps/testing/com.ubiris.twdcompass
近日整合了登山界朋友的意見，小改款之後推出這次的版本。主要回應部份山友對於多元定位機制可能拿到非GPS座標的疑慮，加入了 "定位方式" 的設定選項。
除此之外，也藉這次機會將原先的 "最佳位置" 演算法改為最新的 "融合式定位"。原先我們採用的演算法是基於早期 Google 釋出的範例程式，但後來 Google 便不再維護並另行開發融合式定位 (fused location) 演算法。事實上，iPhone 平台的座標取得也一直是採用類似融合式定位的演算法。而不管是哪個平台，其演算法都已經過歐美法規驗證，並成為目前先進國家AML緊急通話自動定位的基礎技術(可惜台灣八字還沒一撇)
然而我們還是要再強調一次：
《座標是一個圓不是一個點》
經緯度是圓心，準確度是半徑，演算法不是重點，#重點是回報前要確認準確度_回報時要提供準確度。這也是使用大地羅盤傳送位置時，我們一定會帶上準確度的原因。一般來說，#50公尺的準確度對於戶外緊急救援就已經足夠了。
另外對於仍然無法信任此類演算法的朋友，可以將 "定位方式" 修改為 "僅使用GPS位置"。#但切勿在手機訊號不佳或電力不足的情況下開啟飛航模式來強迫手機使用GPS位置。因為這樣可能會延長定位時間_因為AGPS無用武之地，還會重新搜尋訊號消耗電力，最壞的情況是無法再找回手機訊號。
其它部份, 就請大家參考以下改版公告了：
[羅盤]
1. 新增定位方式設定選項：融合式定位(新預設機制)、僅使用GPS、最佳位置(原機制)。
2. 由於加入了 "融合式定位"，若分享準確度不及50公尺的位置時會以對話窗提示用戶。(原先僅就網路或基地台座標進行提示)
3. 由於加入了 "僅使用GPS"，保持螢幕開啟選項由預設不啟用改為預設啟用(但不影響現有用戶)，以避免GPS在冷啟動的狀態下，會有定位完成前螢幕就被鎖定的狀況。
4. 座標詳細資訊加入 "衛星定位初始化時間" (TTFF)。
5. 可於選單中強制重新取得定位。
6. 以 "準確度" 取代原本的 "精確度" 或 "誤差" 以統一用語並貼近原文 (accuracy)。
7. 加入香港(HK)及中國(CN)地區語言檔。
8. 修正左下衛星訊號圖示會閃爍的問題。
[轉換工具]
1. 加入說明以提示可用於 DD/DMM/DMS 互相轉換。
所以参考了一下原文中的算法，使用JAVA进行了实现。 实现原理也是很相似的，先算出该点周围的矩形的四个点，然后使用经纬度去直接匹配数据库中 ... ... <看更多>
請問各位網友:WGS 84座標有(X,Y)與(經緯度)的兩種表示方法,請問有可以轉換的軟體,或是計算的公式嗎?例如:WGS 84 座標(X.Y) X：120.396480 ... ... <看更多>
經緯度算法 在 已知经纬度计算两点间地理距离 的推薦與評價
本文参考比利时天文学家Jean Meeus (1991)的《天文算法》81-86页的公式，给出相应的R代码。 2.1 将经纬度的度、分、秒转换为十进制. 定义函数deg2dec ... ... <看更多>