我正在開發基於JAVA的Web應用程序。主要目標是爲多個被稱爲渠道的網站上銷售的產品提供庫存。我們將擔任所有這些渠道的經理。 我們需要的是：SQL vs NoSQL庫存管理系統
我在看的解決方案是postgres（我們的db直到現在處於同步複製模式），像Cassandra，Redis，CouchDB和MongoDB這樣的NoSQL解決方案。
我的約束是：
我接受任何建議。提前致謝。
NoSQL不適用於此應用程序。
我的意思是，你可以肯定地使用它，但最終你會重新實現SQL爲你提供的很多東西。例如，我在那裏看到很多關係。你也希望ACID（儘管一些NoSQL解決方案確實提供了）。
沒有理由不能同時使用 - 保留關係數據庫中的關係數據和關鍵/值存儲中的非關係數據。
解決您的約束：
大多數NoSQL的解決方案，讓您對性能的一致性的配置權衡。例如，在MongoDB中，您可以決定寫入應該有多持久。如果你願意，你可以強制在所有的副本集服務器上寫入fsync。另一方面，您可以選擇發送命令，甚至不等待服務器的響應。
按順序執行作業隊列似乎是應用程序代碼問題。我會說db中的時間戳和一個查詢類型應該爲大多數應用程序執行。如果你有多個應用程序服務器並且你的隊列需要完美，你必須使用truly distributed algorithm來提供排序，但這不是一個典型的要求，而且確實非常棘手。
我們已經使用MongoDB一段時間了，我相信這會讓您的應用程序開發速度大幅提升。維護沒有太大的區別，維護數據是一種痛苦。沒有模式可以增加靈活性（懶惰遷移），但它更加精細，需要一定的關注。
總之，我會說你可以做到這一點。NoSQL更多是由代碼驅動的，並且事務和關係完整性大部分由您的代碼管理。如果你對此感到不舒服，那就去關係型數據庫。但是，如果數據量增長巨大，則必須手動編寫一些邏輯，因爲您可能不想在10B行數據庫上進行實時連接。不過，你也可以用SQL來實現它。
查找不同數據庫的邊界的一個好方法是考慮可以緩存的內容。隨時可以緩存和重建的數據是開始引入新圖層的好方法，因爲這裏沒有大的風險。而且，緩存的數據通常不會保留任何關係，因此您不會犧牲任何一致性。
- 排隊管理每個渠道的庫存更新。
這不一定是數據庫問題。你可能會更好看一個消息系統（例如RabbitMQ的），其中有分配的每個通道上的一個正確的快照
- 庫存表。
- 將會話ID和其他快速訪問數據保存在緩存中。
會話數據或許應該被放在一個單獨的數據庫更適合的任務（如memcached的，Redis的，等等） 沒有一個放之四海而皆準的所有DB
- 提供一個類似facebook的儀表板（XMPP），以儘快讓賣家更新。
我的約束是： 1.庫存更新不會丟失。
有3種方法來回答這個問題：
此功能必須由應用程序來提供。數據庫可以保證壞記錄被拒絕並回滾，但不能保證每個查詢都會被輸入。 該應用必須足夠聰明才能識別錯誤何時發生，然後重試。
某些DB將記錄存儲在內存中，然後將內存刷新到磁盤，這可能會導致數據在電源故障時丟失。 （例如Mongo默認以這種方式工作，除非啓用日誌功能，CouchDB總是附加到記錄上（即使刪除是附加到記錄上的標誌，所以數據丟失也非常困難））
某些數據庫被設計爲非常可靠的，即使地震，颶風或其他自然災害發生，它們仍然是持久的。這些包括Cassandra，Hbase，Riak，Hadoop等。
您指的是哪種類型的耐久性？
- 作業隊列應按順序執行，最好不要丟失。
大多數noSQL解決方案都傾向於並行運行。所以你在這裏有兩個選擇。 1.使用鎖定整個表的每一個查詢DB（慢） 2.構建您的應用程序更聰明或事件觸發（客戶端順序排隊）
- 容易/快速的發展和日後的維護。
通常，你會發現，SQL是更快地開發在第一，但變化也很難實現 NOSQL可能需要更多一點的規劃，但更容易做即席查詢或架構更改。
你可能要問自己的問題是更喜歡：
「請問我需要有強烈的查詢或深入的分析，一個的Map/Reduce是更適合？」
「我需要我改變我的架構頻繁？
」是我的數據高度的關係？以什麼樣的方式？「
‘確實選擇了DB我背後的供應商有足夠的經驗來幫助我，當我需要它嗎？’
」我需要特殊的功能，如地理空間索引，全文檢索，等等？「
」我需要我的數據的實時時間有多近？如果直到1秒後纔看到最新的記錄顯示在我的查詢中，會不會傷害？什麼級別的延遲是可以接受的？「
‘什麼纔是我真正需要的條件故障轉移’
」有多大是我的數據？它會適合內存嗎？它會適合一臺電腦嗎？每個單獨的記錄是大還是小？
「我的數據多久變化一次？這是一個檔案嗎？」
如果您打算讓多個客戶（渠道？）各自擁有自己的庫存模式，那麼基於文檔的數據庫可能具有優勢。我記得有一次我看了一個有庫存的電子商務系統，它有近235張桌子！ 然後，如果你有一定的關係數據，一個SQL解決方案也可以有一些優勢。
我當然可以看到我可以使用mongo，沙發，riak或orientdb與給定的約束條件來構建解決方案。但至於哪個最好？我會嘗試直接與數據庫供應商談話，也許看nosql磁帶
這就是我現在正在傾向（關係+ nosql），但放置邊界的地方？我可以將一些關係業務邏輯遷移到NoSQL域，以便可擴展性內置嗎？我處於開發模式，所以如果改變是值得的，我可以接受。 – gladiator
等待 - 您是否在嘗試NoSQL的可擴展性？這是使用它的錯誤原因！您可以同時縮放SQL和NoSQL。將SQL遷移到NoSQL非常困難。反過來很容易。 – Ariel
這不是技術，而是功能：如果您嘗試在巨大的桌子上執行復雜的連接，速度不夠快。這項工作沒有銀彈。 – mnemosyn