我最近加入了一家仍处于成长阶段的金融科技初创公司。我们管理的平台基本上是投资组合管理。
我们考虑来自用户银行的账户交易、汇率、资产价格（来自路透社等第三方），并计算投资组合估值和业绩。
所以流程可以概括为：
security transactions -> asset units -> prices -> exchange rates -> portfolio value
问题是关于这个平台中具有 SOA 的旧的核心微服务。它有几个性能问题，原因有几个，但主要瓶颈是 DB。
目前生产中的数据库大小为 400 GB。设计中使用的方法是，在处理的任何阶段，服务都会计算每天的值并将它们存储在数据库中。
回答：
可以根据业务用例和客户需求将数据分类为不同的类别，然后从存储角度决定需要什么策略。
例如：提到的用例可以分为以下几类：
- SoR 数据
- 历史数据
- 计算数据（分析、趋势等）
在此分类之后，您可以考虑将主数据库用于 SoR，将只读副本或 nosql 用于历史数据，将时间序列数据库 etx 用于计算数据。
总体思路是分而治之的数据管理方法。
大小真的不重要... 将事务数据保持在应用程序的正常形式中。如果您需要报告功能，请独立解决。