用于库存管理系统的 SQL 与 NoSQL答案

【问题标题】：SQL vs NoSQL for an inventory management system用于库存管理系统的 SQL 与 NoSQL
【发布时间】：2012-01-09 11:41:25
【问题描述】：

我正在开发一个基于 JAVA 的 Web 应用程序。主要目的是为在多个称为渠道的网站上销售的产品提供库存。我们将担任所有这些渠道的经理。我们需要的是：

我正在研究的解决方案是 postgres（我们的数据库到目前为止处于同步复制模式），NoSQL 解决方案，如 Cassandra、Redis、CouchDB 和 MongoDB。

我的限制是：

我愿意接受任何建议。提前致谢。

【问题讨论】：

【解决方案1】：

用于管理每个渠道的库存更新的队列。

这不一定是数据库问题。您可能最好查看消息系统（例如 RabbitMQ）

具有每个通道上分配的正确快照的库存表。

将会话 ID 和其他快速访问数据保存在缓存中。

会话数据可能应该放在更适合任务的单独数据库中（例如 memcached、redis 等）没有万能的数据库

提供类似 Facebook 的仪表板 (XMPP) 以让卖家尽快更新。

我的限制是： 1. 库存更新不能丢失。

有3种方法可以回答这个问题：

此功能必须由您的应用程序提供。数据库可以保证拒绝和回滚坏记录，但不能保证每个查询都会被输入。该应用必须足够智能，才能识别何时发生错误并重试。
有些 DB 将记录存储在内存中，然后定期将内存刷新到磁盘，这可能会在断电的情况下导致数据丢失。（例如，除非您启用日记功能，否则 Mongo 默认以这种方式工作。CouchDB 始终附加到记录（即使删除也是附加到记录的标志，因此数据丢失非常困难））
有些 DB 设计得非常可靠，即使发生地震、飓风或其他自然灾害，它们也能保持耐用。其中包括 Cassandra、Hbase、Riak、Hadoop 等

您指的是哪种类型的耐用性？

作业队列应按顺序执行，最好不要丢失。

大多数 noSQL 解决方案更喜欢并行运行。所以你有两个选择。 1.使用为每个查询锁定整个表的数据库（较慢） 2. 将您的应用程序构建为更智能或事件（客户端顺序队列）

易于/快速的开发和未来的维护。

通常，您会发现 SQL 一开始开发速度更快，但更改可能更难实现 noSQL 可能需要更多计划，但更容易进行临时查询或架构更改。

您可能需要问自己的问题更像是：

如果您要拥有多个客户（渠道？），每个客户都有自己的库存模式，那么基于文档的数据库可能具有它的优势。我记得有一次我查看了一个有库存的电子商务系统，它有近 235 张桌子！话又说回来，如果你有一定的关系数据，SQL 解决方案也确实有一些优势。

我当然可以看到如何在给定的约束条件下使用 mongo、couch、riak 或 orientdb 构建解决方案。但至于哪个最好？我会尝试直接与数据库供应商交谈，也许会观看 nosql 磁带

【讨论】：

【解决方案2】：

解决您的约束：

大多数 NoSQL 解决方案为您提供了可配置的一致性与性能权衡。例如，在 MongoDB 中，您可以决定写入的持久性。如果您愿意，您可以强制在所有副本集服务器上进行 fsync 写入。在另一个极端，您可以选择发送命令，甚至不等待服务器的响应。
按顺序执行作业队列似乎是应用程序代码问题。我想说数据库中的时间戳和order by 类型的查询应该适用于大多数应用程序。如果您有多个应用程序服务器并且您的队列需要完美，则必须使用提供排序的truly distributed algorithm，但这不是典型的要求，而且确实非常棘手。
我们使用 MongoDB 已有一段时间了，我相信这会真正提高您的应用程序开发速度。维护没有太大区别，无论哪种方式维护数据都是一种痛苦。没有架构可以增加灵活性（延迟迁移），但它更复杂，需要小心。

总而言之，我想说你可以同时做到这一点。 NoSQL 更多的是代码驱动，事务和关系完整性主要由您的代码管理。如果您对此感到不舒服，请使用关系数据库。

但是，如果您的数据变得庞大，您将不得不手动编写其中的一些逻辑代码，因为您可能不想在 10B 行数据库上进行实时连接。不过，您也可以使用 SQL 来实现。

找到不同数据库边界的一个好方法是考虑可以缓存的内容。可以随时缓存和重建的数据是开始引入新层的好方法，因为那里没有大风险。此外，缓存数据通常不会保留任何关系，因此您不会在这里牺牲任何一致性。

【讨论】：

【解决方案3】：

NoSQL 不适用于此应用程序。

我的意思是，您当然可以使用它，但您最终会重新实现 SQL 为您提供的许多功能。例如，我在那里看到了很多关系。您还需要 ACID（尽管一些 NoSQL 解决方案确实提供了）。

没有理由不能同时使用两者 - 将关系数据保存在关系数据库中，将非关系数据保存在键/值存储中。

【讨论】：

这就是我现在所倾向于的（关系+ nosql），但是在哪里放置边界？我可以将我的一些关系业务逻辑迁移到 NoSQL 域，以便内置可扩展性吗？我处于开发模式，所以如果值得，我可以接受改变。
等一下 - 您是否正在尝试使用 NoSQL 来实现可扩展性？那是使用它的错误理由！您可以同时扩展 SQL 和 NoSQL。将 SQL 迁移到 NoSQL 非常困难。反过来很容易。
这不是技术，而是功能：如果您尝试在巨大的表上执行复杂的连接，它就不够快。没有灵丹妙药可以完成这项工作。