Rentea db Spec

Data model:

  • Raw House

    • 從租屋網站取得的每一筆租屋資料
    • 裡面可能有多筆資料都指向同一個租屋位置
    • 例如 591 網站: 因為其推銷機制，爬蟲會取得多筆重複的租屋資料

  • Unique House

    • 將 Raw House 的資料做整理，去除重複的租屋資料
    • 重複的定義方式: 兩筆租屋資料中每一個欄位都擁有相同的內容
    • 重複的實作方式: 在 SELECT query 的 WHERE 後面加入所有比較的欄位，看看是否能找出一筆資料，如果有就代表重複

  • House Meta

    • 需求: 因為網站上的租屋資料可能和實際看屋情況不同，所以讓使用者能夠 feed back 描述實際的租屋、看屋情況

  • Filtered House

    • 需求: 使用者透過分類功能，搜尋所有擁有相同分類的租屋資料
    • 實作: 可能在後端去除重複資料之後，將資料新增到 Unique House 時也要根據分類新增到 Filtered House。

  • Search Filter

    • 需求: 列舉所有分類項目，Filtered House 中的分類項目來自於這個資料表
    • 疑問: 分類是由誰來新增? 或是我們自己決定有幾種分類項目?

  • User

    • 需求: 讓使用者登入並且使用相關功能，例如提供租屋資訊回饋
    • 實作:
      • 使用電子郵件登入，需要電子郵件驗證
      • 使用社群網站登入
      • 帳號密碼登入
      • 忘記密碼

API

Internal API (For Crawler)

Public API (For Client)

Goal:

  1. 處裡 Raw House/Unique House 在 Insert/Update/Delete 之間的交互邏輯
  2. 讓 crawler、api server(future work) 有共同的介面可以重用
    • crawler 用 rentea-db 塞資料、更新資料
    • api server 用 rentea-db 撈資料（？）

ddio 表示在 https://github.com/g0v/tw-rental-house-data 處裡過在更新時，比對不同欄位、確定新增 unique house 的邏輯

rentea-db 這一邊就抄起來，再補齊刪除的部分

  • 然後決定要用哪種 DB!
    • MySQL:
      • 一開始線上聚會討論的結果，想要穩定的話是比較好的選擇
    • PostgreSQL 一票！
    • Elasticsearch:
      • 雖然擁有儲存功能，但是本質上還是一個搜尋引擎，沒有保證 ACID 中的 Durability 所以會有掉資料的問題。有詢問過 ddio 並表示，雖然爬蟲每天都會撈租屋資料回來，但還是無法接受會遺失的情況，每次遺失都只能等到明天後再將資料補回，這樣可能太慢了。
    • 混用:
      • 資料庫使用 MySQL，配合 Elasticsearch 輔助搜尋
    • 其他:
      • 前端有一個需求是在地圖上畫圈，然後搜尋圈內所有租屋資料。所以希望資料庫支援多邊形(Polygon)搜尋

High Level Tasks