我一直在为一个用例探索几个选项，在这个用例中，我们必须跟踪作为 TMS 的一部分生成的工单的多个状态更新。一张工单(父工单)可以关联子工单(如子元素)，只有当所有子工单的状态都已关闭时，父工单才会被视为已关闭。工单的状态可以有 4 种不同的状态选项，例如(新打开、关闭、待处理)。
Ex:- ParentTicket No -1234(parent) 在此之下我们还有 4 个子票，每个子票都有一个来自列表的状态{new, open, closed, pending} 作为 子票 1 号 - 1234_2345.1 子票 2 号 - 1234_5543.2 SubTicket3 编号 - 1234_4567.3 SubTicket4 否 - 1234_9876.4
所以最终的结构是这样的:
ParentTicket No -1234 "Status = Open"
-SubTicket1 否 - 1234_2345.1“状态 = 新”
-SubTicket2 否 - 1234_5543.2“状态 = 已关闭”
-SubTicket3 否 - 1234_4567.3“状态 = 待处理”
-SubTicket4 否 - 1234_9876.4“状态 = 新”
我们需要在一天内管理大约 250,000 张这样的(父)票证，为期 1 年。票据的典型生命周期可以在 1 分钟到 1 年之间。这看起来有点糟糕，但是是的，这是要求。当然，我们可以在一段时间后销毁那些已关闭状态的门票。
为了解决这个问题，我正在考虑使用 REDIS，使用散列作为父票号，并将 SubticketNos 作为键存储在其中，值 = status。我知道有更多的方法可以解决这个问题，如果可以提供一些关于此的指示，我将不胜感激。
在此先感谢冠军们!
最佳答案
在我个人看来，例如，redis 非常适合管理 session ，但最后，如果这些数据由于某些奇怪的原因而被破坏，那么这些数据就不那么重要了。
在您的情况下，您需要在不破坏“关系”(例如关系数据库)的情况下获得良好的性能，因此，我建议保持良好的读取、插入和事务比率可以是 Orient DB。 Orient DB 是一个非常酷的存储系统，可用于您的案例(内部是一个图形数据库，但您将把它作为文档数据库来管理，如 mongo db):http://orientdb.com/
关于redis - Redis 是管理票证状态更新用例的好选择吗，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32597708/