mongodb實作exists去重

Question

db.getCollection('user').save({"uid":"1123", "logTime":ISODate('2016-05-23 11:11:23')});
db.getCollection('user').save({"uid":"1124", "logTime":ISODate('2016-05-23 05:11:23')});
db.getCollection('user').save({"uid":"1125", "logTime":ISODate('2016-05-23 08:11:23')});
db.getCollection('user').save({"uid":"1126", "logTime":ISODate('2016-05-23 09:12:23')});
db.getCollection('user').save({"uid":"1127", "logTime":ISODate('2016-05-23 11:23:23')});
db.getCollection('user').save({"uid":"1134", "logTime":ISODate('2016-05-23 11:11:23')});
db.getCollection('user').save({"uid":"1123", "logTime":ISODate('2016-05-21 11:11:23')});
db.getCollection('user').save({"uid":"1125", "logTime":ISODate('2016-05-22 11:11:23')});
db.getCollection('user').save({"uid":"2343", "logTime":ISODate('2016-04-23 11:11:23')});
db.getCollection('user').save({"uid":"9873", "logTime":ISODate('2016-04-23 11:11:23')});
db.getCollection('user').save({"uid":"4321", "logTime":ISODate('2016-04-20 11:11:23')});

上面模擬一些資料生產一個user集合來表示使用者登入狀況. 現在我想查詢2016-05-23的新使用者數(5-23號登入的使用者但是在小於5-23號的記錄中不存在) 例如第一筆記錄uid='1123'在5-21也登入那麼uid='1123'就不算在5-23登入的用戶數中

Answer 1

mongodb不支持支持join,下面這種方式可以達到你的目的

var list = [];
db.getCollection('user').find({'logTime': {'$lt': ISODate('2016-05-23')}}, {'_id': 0, 'uid': 1}).forEach(function(item){
    list.push(item['uid']);
});

db.getCollection('user').find({'logTime': {'$gte': ISODate('2016-05-23')}, 'uid': {'$nin': list}});

Answer 2

5-23號登入的使用者但是在小於5-23號的記錄中不存在

首先這種設計是有明顯的缺陷的。

1. 性能缺陷：小於23號的記錄多了去了，1年、2年、10年前都算小於5月23號，你要往前掃多久？剛開始只有幾天的資料可能還好，慢慢隨著日誌增多，你的程式就會跑得越來越吃力。而且這個過程會進行得很快。這時候你就會想到刪除舊日誌，於是出現下面的問題。

2. 不易維護：登入日誌這種東西，量大而且對一般人來說又沒太大用處，很少有人永久保存。可想而知當你刪除一年前的日誌後，一批不新的新用戶就誕生了，因為他們首次登入的日誌可能被你刪除了。

另外一般所指的新用戶不就是新註冊的用戶嗎，哪天註冊算哪天，有什麼特殊的理由一定要用這種演算法來找新用戶？
如果一定要把第一次登入這天算作新用戶時間，那建議重新設計。例如以用戶表為基礎，找出還沒登入過的用戶，然後定期查找他們的登入日誌，一旦找到則把首次登入日期記錄到用戶表中。這樣理論上不管過多久，註冊過但是沒有登入的用戶的量不會有太大變化（並不是不會有變化，確實存在註冊過但是從來不登入的用戶，但是畢竟少），你的程序就不會隨著時間推移性能變得很差。

並沒有直接回答你的問題，因為我一慣的經驗告訴我要從根本上解決問題，不要在一個錯誤基礎上打補丁，只會把情況變得越來越糟。

PS：你的最後一句話邏輯是不是有問題？