根据我从你的问题中了解到的情况，我相信cassandra应该很容易适合你的用例。
关于您的要求：
持久性：cassandra不仅能持久化数据，而且能以最小的配置覆盖冗余；
快速写入：这是cassandra最擅长的，而准确的吞吐量取决于许多因素，一般来说，cassandra将管理以千/秒/核心为单位的写入；而且，最终的写入次数并不是真正相关的，因为cassandra可以线性扩展而没有实际的惩罚，所以5k、10k、100k或更多都是可行的；
适应性：cassandra拥有最常见语言（python、c系列、nodejs、java、ruby、php、scala）的官方驱动程序，以及更多语言的社区开发驱动程序（多样性列表）；
可部署的：在云中部署非常容易。您可以选择在独立示例上手动部署它，也可以使用托管cassandra集群（aws有一个，称为“aws keyspaces”，datastax（推动cassandra大部分开发的公司）有一个，称为“astra”，还有更多可能的解决方案。考虑到cassandra是大数据存储领域的主要参与者之一，在云计算中为您找到一个位置应该很容易。
我只提到了5项要求中的4项。这是因为当谈论阅读时，事情变得更复杂，需要更大的讨论。
500-100读/秒，假设每秒有2k以上的写操作，这似乎符合cassandra针对写密集型任务进行优化的总体思路。在cassandra中，您对表进行建模的方式将决定事情的工作效果。对于你所描述的任务，我的第一个想法是：
每天对每只股票进行bucket=>得到一个分区，大约有30000行（每8个交易小时更新1次），大小在0.2mb以下（30k*4b）。这将在推荐值范围内，并明显处于最坏情况下；
当您需要聚合数据时，有2个选项：
第二章。您可以按原样读取分区，并在应用程序端聚合它（我建议这样做）；
第2b条。您在数据库上实现了一个“用户定义聚合”函数，该函数将执行工作（docs）。这应该是可行的，尽管我不能保证。除了很难实现之外，问题在于，考虑到明显的用例，将这种额外的工作负载放到db上可能不是您想要的。让我来解释一下：我希望你的阅读量在某些时段（交易时间之前、交易时间期间和交易时间之后）最活跃，而在负载较轻的时段。根据您的体系结构，您可以在高峰时段增加多个应用程序示例，然后在非高峰时段缩小它们以降低成本。而应用程序可以在aws和gc等云提供商上轻松地进行伸缩。cassanadra不能像这样放大和缩小（早上5个节点，晚上3个节点，以此类推）（它可以，但它不是设计成这样的，这将是一个可怕的决定）。因此，将尽可能多的非恒定工作负载转移到应用程序似乎是最好的主意；
（可选）让一名工作人员在一天/交易日结束时汇总每只股票的价值，并将其保存到另一个表中，以便查看历史数据时更容易。根据聚合数据占用的空间大小，这些数据甚至可以按周、月甚至年进行压缩。
您还可以在casandra前面添加spark和kafka，以获得更强大的实时聚合方法，但我们不应该偏离手头的问题太多。
Cassandra是非常强大的与正确的建模和正确的架构。乍一看，你所需要的似乎是一个很好的适合Cassandra，但它可能是强大的，因为它可以得到坏，如果你使用它的方式不是设计的。我希望这个答案能让你做出正确的决定。
干杯。