我应该为我们的 Web 应用程序选择什么邮件存储？ IMAP、键值存储、rdbms、
我必须存储电子邮件以供我们的应用程序使用。我在关系数据库中拥有所有消息的“元数据”，但我不太愿意将消息内容（GB 和 TB 的电子邮件数据）保存在数据库中。我目前正在使用 IMAP 作为存储，但我怀疑我的选择是否正确。首先，存在 uidvalidity 问题以及如何在 IMAP 内保持对消息的永久引用。其次，我不确定这在备份/恢复策略、存储损坏、复制方面是否是最强大的解决方案......积极的一面是我可以使用标头查询 IMAP，因为数据大部分都已索引。
我不知道键值存储是否是更好的方法（Casandra、东京橱柜、redis）。他们如何处理存储 1KB 和 50MB 的数据。他们如何防止腐败以及当腐败或设备故障发生时我该如何修复商店。
I have to store e-mail messages for use with our application. I have "metadata" for all messages inside a relational database, but I don't feel comfortable keeping message content (gigabytes and terabytes of email data) inside a database. I'm currently using IMAP as a storage, but I have my doubts if I choose correctly. First of all there is a problem of uidvalidity and how to keep a permanent reference to message inside IMAP. Second, I'm not sure if this is the most robust solution in terms of backup/restore strategies, corruption of store, replication ... Positive side is that I can query IMAP using the headers because the data is mostly indexed.
I don't know if key-value stores are a better approach (Casandra, Tokyo cabinet, redis). How they handle storing 1KB and 50MB of data. How they prevent corruption and when corruption or device failure happens how can I repair the store.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用文件系统怎么样？数据库中的元数据可能指向实际消息的路径名（每个文件一条消息）。
如果您的消息量足够大，以至于您担心基于每个目录的文件数的性能，您可以将其拆分为 2 级（或更多）级目录层次结构（例如，通过对 messageid 进行哈希处理）。
使用标准文件系统意味着您可以使用所有现有技术进行日志记录、复制、备份等。
What about using the filesystem? Your metadata in the database could point to the pathname of the actual message (one message per file).
If your message volume is high enough that you're worried about performance based on # of files per directory, you can split things up into a 2-(or more) level directory hierarchy (e.g., by hashing on the messageid).
Using a standard filesystem means you can use all the existing technology for journaling, replication, backups, etc.