注：本案例來自mongodb官方教程ppt，也是乙個非常典型的case，故此翻譯，並結合當前mongodb版本做了一些內容上的更新。
本案例非常適合與iot場景的資料採集，結合mongodb的sharding能力，文件資料結構等優點，可以非常好的解決物聯網使用場景。
案例背景是來自真實的業務，美國州際公路的流量統計。資料庫需要提供的能力：
可以部署在常見的硬體平台上
,
ts: isodate("2013-10-16t22
:07:00.000-0500")
}
,
ts: isodate("2013-10-16t22
:00:00.000-0500")
}
進一步優化下：
,
...,
59:
}ts: isodate("2013-10-16t22:00:00.000-0500")
}
從寫入上看：後者每次修改的資料量要小很多，並且在wiredtiger引擎下，同乙個文件的修改一定時間視窗下是可以在記憶體中合併的；
從讀取上看：查詢乙個小時的資料，前者需要返回3600個文件，而後者只需要返回60個文件，效率上的差異顯而易見；
從索引上看：同樣，因為穩定數量的大幅度減少，索引尺寸也是同比例降低的，並且segid，ts這樣的冗餘資料也會減少冗餘。容量的降低意味著記憶體命中率的上公升，也就是效能的提高；
從寫入上看：因為wiredtiger是每分鐘進行一次刷盤，所以每小時乙個文件的方案，在這乙個小時內要被反覆的load到pagecache中，再刷盤；所以，綜合來看後者相對更合理；
從讀取上看：前者的資料資訊量較大，正常的業務請求未必需要這麼多的資料，有很大一部分是浪費的；
從索引上看：前者的索引更小，記憶體利用率更高；
那麼到底選擇哪個方案更合理呢？從理論分析上可以看出，不管是小時儲存，還是分鐘儲存，都是利用了mongodb的資訊聚合的能力。
落實到現實的業務上，哪種是最優的？最好的解決方案就是根據自己的業務情況進行效能測試，以上的分析只是「理論」基礎，給出「實踐」的方向，但千萬不可以此論斷。
說到時序儲存需求，大家一定還會想到非常厲害的influxdb，influxdb針對時序資料做了很多特定的優化，但mongodb採用聚合設計模式同樣也可以大幅度較少資料尺寸。根據最新的測試報告，讀取效能基本相當，壓縮能力上influxdb領先mongodb。但mongodb的優勢在於可以儲存更豐富的資訊，比如地理座標，文字描述等等其他屬性，業務場景上支援更廣泛。
另外，mongodb的shardin**平擴充套件能力，aggragation功能，spark connector等等特性，對iot來說，生態優勢明顯。
MongoDB資料建模小案例 朋友圈評論內容管理
點讚列表，點讚使用者的暱稱，頭像 資料查詢則相對簡單 跟據上面的內容，先來乙個非常非常 樸素 的設計 100011 100012 comment list 100013 100014 comment ref obj 100014 可以看到，comment ref obj與praise ref obj...
vuex小案例 元件共用資料
將state中的資料做一些集中處理，用map遍歷陣列中每乙個資料做處理 將state作為引數傳入，可以直接使用遍歷等 getters return saleproducts payload作為引數被傳入使用的元件，items.price payload payload傳幾就減幾 mutations ...
把CRUD 案例改為MongoDB 資料庫版本
之前基於express寫的案例是檔案格式，現在連線mongodb 資料庫 對原案例進行修改。主要就是student.js 修改如下 ar mongoose require mongoose mongoose.connect mongodb localhost itcast var schema mo...