我們使用couchbase作爲我們的nosql存儲併爲其功能而熱愛它。 然而,我們正在通過查看歸類創建關聯 來解決問題。這可以被認爲類似於連接操作。 雖然我們的數據集是保密的,但我正在用這個模型來說明問題。查看Couchbase整理
數據量很大,因此無法在內存中處理。我們有冰淇淋,郵編和一天的平均溫度數據。 一種類型的文檔包含一個郵政編碼冰淇淋映射 和另一個有交易數據冰淇淋被出售在一個特定的郵編。 問題是要能夠確定一組特定日期的溫度下出售的頂級冰淇淋。
爲了發出兩個輸出,一個是郵編到溫度映射,另一個是代表郵遞區號的冰淇淋銷售,我們關注這個語料庫。 :
Key Value
[zip1] temp1
[zip1,ice_cream1] 1
[zip2,ice_cream2] 1
這裏的視圖排序規則是創建ice_cream銷售,拉鍊和平均溫度之間的關聯,即聯接的機構。
我們有一個約束條件,即溫度查詢在24小時內只發生一次,當拉鍊首次出現時,這是當天使用的有效平均溫度值 。例如查找發生在1月1日中午12:00,下一次查詢不會在1月2日中午12:00之前發生。 但是,第一次查找接受的平均溫度僅在1月1日有效,而第二次查找的平均溫度僅在1月2日 (包括上半天)有效。 現在事情變得複雜了,當我想用相關的時間組件做相同的查詢時,具體將當天的平均溫度與那天在該zip.eg中銷售的冰淇淋關聯起來。當這一天的平均氣溫爲70°F
Key Value
[y,m,d,zip1] temp1
[y,m,d,zip2,ice_cream2 ] 1
[y,m,d2,zip1,ice_cream1] 1
這對查詢一個有趣的衝擊X香草冰淇淋都賣了,說我查詢最近一天我不能讓冰淇淋和之間的任何關聯在第一次查找發生之前的溫度,因爲那是兩個鍵對齊時的溫度。最終效果是我在那天的溫度查詢 發生之前失去了那一天的冰激凌計數。我想知道你們中的任何一個人是否面臨過類似的問題,並且你是否知道某種模式或解決方案,以免丟失這些數字。
謝謝你@ rmayer06的回答和歡迎,我正在做你剛纔在#2中提到的[查看更多記錄...],它看起來像是一種笨拙的做事方式。數據的規模在數億記錄的範圍內。由於需要這種查找的數量,因此每次手動查找都不是一種選擇。 – hvd