我使用Cassandra数据库作为最终存储，mongodb作为应用程序的临时存储。此数据库的工作流程是，数据将在mongodb中存储仅3天，数据将在mongodb中存储一天后存储在cassandra中。在此应用程序中，我尽可能使用upsert操作，并避免先读后写策略，因为考虑到数据库的最大性能可用性。该应用程序在短时间间隔内处理超过400000个数据，因此需要考虑数据库的性能和可用性。
让我描述一下要存储的数据的结构，它是一个消息传递应用程序，所以最近通过一些webhook传入的消息的状态和这些状态和消息应该存储在一个单独的表中。存储在一个单独的表中的目的并不是仅仅考虑数据访问的速度。注意，有时候状态会在从mongodb中删除它的消息后出现（3天后），并了解没有指示来识别是新消息还是旧消息的状态Cassandra数据库“created_datetime”被用作聚类关键字，并且该聚类关键字仅可用于不具有其状态的消息，这就是在这个应用程序中使用两个数据库的原因。消息有三种状态。
我在下面列出了执行基于此数据管理的应用程序的活动。消息详细信息upsert到mongodb的集合中。状态将被upsert到mongodb的相同集合中。这将在一段时间后发生。对于一些消息，可能需要超过三天的时间。数据在一天后复制到cassandra数据库中-（使用upsert操作）。状态出现延迟（一天后）的状态也应该在Cassandra数据库中更新。三天后的状态也应该在Cassandra数据库中更新。要在Cassandra数据库中更新这些状态，我希望首先从Cassandra数据库中读取消息详细信息，然后通过收集群集键来更新它们。但在这里我找不到其他的解决办法，也是这种状态（晚了三天左右）会少考虑其他状态。并在完成对cassandra数据库的更新后从mongodb中删除这些状态。从mongodb中删除三天前创建的所有消息。

• 此数据库管理的替代解决方案。
• 任何改进建议。