我正在开发基于JAVA的Web应用程序。主要目标是在多个名为渠道的网站上销售产品库存。我们将担任所有这些渠道的经理。 我们需要的是：
我正在寻找的解决方案是postgres（我们的db直到现在处于同步复制模式），NoSQL解决方案，如Cassandra，Redis，CouchDB和MongoDB。
我的约束是：
我愿意接受任何建议。提前谢谢。
答案 0 :(得分：9)
- 排队管理每个频道的广告资源更新。
这不一定是数据库问题。你可能最好看一下消息系统（例如RabbitMQ）
- 库存表，其中包含每个渠道的正确分配快照。
- 将会话ID和其他快速访问数据保存在缓存中。
会话数据应该放在一个更适合该任务的单独数据库中（例如memcached，redis等） 没有一个适合所有人的DB
- 提供类似Facebook的信息中心（XMPP）以尽快更新卖家。
我的约束是： 1.库存更新不会丢失。
有三种方法可以回答这个问题：
此功能必须由您的应用程序提供。数据库可以保证拒绝和回滚坏记录，但不保证每个查询都会被输入。 应用程序必须足够智能，以便在发生错误时进行识别，然后重试。
某些DB将记录存储在内存中，然后在内核上将内存刷新到磁盘，这可能会导致数据在电源故障时丢失。 （例如Mongo默认以这种方式工作，除非您启用日记功能.CouchDB总是附加到记录中（即使删除是附加到记录的标志，因此数据丢失非常困难））
有些数据库的设计非常可靠，即使地震，飓风或其他自然灾害发生，它们仍然耐用。这些包括Cassandra，Hbase，Riak，Hadoop等
您指的是哪种类型的耐久性？
- 作业队列应该按顺序执行，最好不要丢失。
大多数noSQL解决方案都喜欢并行运行。所以你有两个选择。 1.使用一个DB来锁定每个查询的整个表（较慢） 2.构建您的应用程序以使其更智能或更安全（客户端顺序排队）
通常，您会发现SQL的开发速度更快，但更改可能更难实现 noSQL可能需要更多的规划，但更容易进行即席查询或模式更改。
- 简单/快速开发和未来维护。
您可能需要问自己的问题更像是：
“我是否需要对Map / Reduce更适合的强烈查询或深入分析？”
“我是否需要经常更改我的架构？
“我的数据是高度关系的？以什么方式？”
“我所选择的数据库背后的供应商是否有足够的经验在我需要时帮助我？”
“我需要特殊功能，例如地理空间索引，全文搜索等吗？”
“我需要我的数据有多接近实时？如果我在1秒后看到最新的记录显示在我的查询中会不会受到影响？可以接受什么级别的延迟？”
“在故障转移方面我真正需要什么”
“我的数据有多大？它是否适合内存？它是否适合一台计算机？每个单独的记录是大还是小？
“我的数据会多久更改一次？这是一个存档吗？”
如果您将拥有多个客户（渠道？），每个客户都有自己的库存模式，基于文档的数据库可能具有优势。我记得有一次我看了一个带库存的电子商务系统，它有近235张桌子！ 再说一次，如果你有某些关系数据，SQL解决方案也可以带来一些优势。
我当然可以看到如何使用给定约束的mongo，couch，riak或orientdb构建解决方案。但至于哪个是最好的？我会尝试直接与DB供应商交谈，也许可以观看nosql磁带
答案 1 :(得分：4)
解决你的约束：
大多数NoSQL解决方案为您提供了一致性与性能的可配置权衡。例如，在MongoDB中，您可以决定写入的持久性。如果您愿意，可以强制在所有副本集服务器上进行写入fsync。另一方面，您可以选择发送命令，甚至不等待服务器的响应。
按顺序执行作业队列似乎是应用程序代码问题。我会说db中的时间戳和order by类型的查询应该对大多数应用程序都有效。如果您有多个应用程序服务器并且您的队列需要完美，那么您必须使用提供排序的truly distributed algorithm，但这不是典型的要求，而且确实非常棘手。
我们一直在使用MongoDB已经有一段时间了，我相信这会让你的应用程序开发速度真正提升。维护方面没有太大区别，维护数据无论如何都是一种痛苦。没有架构可以增加灵活性（延迟迁移），但它更复杂，需要一些小心。
总之，我会说你可以双管齐下。 NoSQL更多地是代码驱动的，事务和关系完整性主要由代码管理。如果您对此感到不舒服，请选择关系数据库。
但是，如果您的数据变得越来越大，您将不得不手动编写一些此逻辑代码，因为您可能不希望在10B行数据库上进行实时连接。不过，您也可以使用SQL实现它。
查找不同数据库边界的一种好方法是考虑可以缓存的内容。可以随时缓存和重建的数据是开始引入新图层的好方法，因为那里没有大的风险。此外，缓存数据通常不会保持任何关系，因此您不会在此处牺牲任何一致性。
答案 2 :(得分：3)
此应用程序的NoSQL不正确。
我的意思是，您可以肯定地使用它，但最终会重新实现SQL为您提供的大量内容。例如，我在那里看到很多关系。你也想要ACID（虽然有些NoSQL解决方案可以提供）。
没有理由不能同时使用两者 - 保留关系数据库中的关系数据，以及键/值存储中的非关系数据。