我正在开发一个每个月都会发送大量电子邮件的系统。该系统的核心功能之一是它需要能够跟踪电子邮件将发生的各种状态变化(已处理、已发送、已打开、已转换)。这些事件中的每一个几乎都是一个状态、时间戳,也许还有一小部分非结构化元数据。
我正在尝试找出对此进行数据建模的最佳方式。由于以下几个原因,标准的关系数据库似乎不是最合适的:
- 不需要太多关系 - 很少有查询会依赖于其他表/文档
- 数据量巨大(每月轻松 100 万条记录)
- 记录很快变得不重要(几个月后,很少查询特定文档,尽管聚合指标很重要)
就数据模型而言,该系统中存在三样东西:
- “电子邮件作业”- 一批发送的许多电子邮件的顶级分组
- 邮件记录
- 这些电子邮件记录的状态更新
我需要执行以下类型的查询:
- Email X 目前的状态如何?
- 电子邮件 X 的状态历史记录是什么(每个状态事件发生的时间)?
- Email Job Y 中的每种状态有多少封邮件?
对建模的最佳方式有什么想法吗?对于这个用例,关系数据库听起来很昂贵且性能不佳......这是 NoSQL/Mongo/DynamoDB 解决方案有意义的罕见地方之一吗?
最佳答案
我同意您问题下的评论:RDBMS 可以为您提供高效的解决方案。
根据这些信息,我将尝试为您提供一个可能的解决方案,但我会自由地做出一些断言:
- 您不需要数据库中的邮件内容,只需对其进行外部引用即可
- 邮件可以通过其 ID、外部 ID 或 [发送者、接收者、发送日期] 的组合进行搜索
- 系统不负责任何用户管理
这个架构应该可以解决问题。
你需要一些索引:
- 所有情况下的 BTREE 索引
- 邮件(external_id)
- 邮件(加急员、收件人、发射日期描述)
- Mail_has_Mail_Status(日期描述)
如果你想保持谨慎:
- 可以对 mail 和 mail_has_mail_status 进行分区。甚至在 mail_has_mail_status 表中进行子分区(如果您只想存档或删除旧数据,维护起来会更容易)(pg_partman)
- 在不同的表空间(热数据、冷数据、索引)上做事
剩下的就是在你的集群上同时访问的问题,以及你有多少钱购买这些 Material 。但是:
- SSD 当时很便宜,在很多情况下可以为您省钱。
- 如果要 RAID:物理卡并避免 RAID 5 系列。
- 如果您需要高可用性:https://register.gotowebinar.com/register/3553182172805148419?source=blog
- 高频处理器(核心数不是那么重要。很多情况下4个就够了)
- 高频内存。如果您在此数据库中没有邮件核心,则不会那么多。
有了这些数据,您可以轻松地对您的架构进行基准测试。
当然,要真正完成您需要的架构工作,您需要更精确的分析和更多的时间来使您的架构符合您的实际需求。当然,在那之后进行基准测试。
关于postgresql - 电子邮件跟踪数据建模,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57936082/