我正在开发基于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