0

我目前正在计划主要使用 sql server 2012 后端构建的电子邮件存储和传递系统的新设计。

大多数架构都是为电子邮件的实际创建而设置的，但我仍然不确定一个设计元素

在哪里存储已发送电子邮件的存档？

我应该将它们作为 nvarchar(max) 存储在 sql 数据库中吗

或者实际上将它们作为文件存储在文件系统本身中（例如 .htm 文件），然后只需链接到存储在数据库中的文件

与我目前存储照片的方式非常相似。

4

3 回答 3

5

我会提倡使用文件系统。

几年前我建立了一个电子邮件引擎，当时它每小时发送一百万条消息（当时这是一个相当大的问题）。虽然通过数据库日志记录等进行可追溯性是有价值的，但我发现使用文件系统更容易日常管理。

我构建了一个半 RESTful 结构，如下所示：

  • 客户（一）
    • 年
      • 月
        • 天
          • 电子邮件主题
            • 消息.html
            • 消息.txt
              • 图片
              • 等等。
除了是一个简单的文件结构之外，它还可以更轻松地管理其他文件依赖项。电子邮件通常包括图像、文件附件等，并且将这些文件捆绑在同一个电子邮件资源文件夹中降低了复杂性。

我的emails表仍然需要参考电子邮件的路径，但这很容易根据 [scheduled] 电子邮件传递日期计算出来。

为了专门解决您的 SQL Server 建议，我可以说我也尝试完全按照您的建议存储电子邮件。最后，对于我的特定技术堆栈，无论如何我都需要将我的文件写入磁盘以获得“在线版本”。当你有这样写的动态电子邮件时：

亲爱的[约翰史密斯]，

感谢您对 [XYZ] 的关注。

当文件可供您的后端（.NET、Java、Rails 等）提供服务时，只需提供一个 ID，处理变量替换就变得非常容易。

http://myclient.emailserver.com/2013/10/29/the-most-brilliant-subject-line-ever?id=1234

最后但同样重要的是，您必须权衡将这些电子邮件保存在数据库中的额外成本。SQL Server 是一款漂亮的软件——就我个人而言，我认为它是微软有史以来最好的产品——但这些电子邮件是存档材料，它们只是在你的系统中增加了大量的内容。我不知道您正在尝试构建的系统的规模，但即使有一亿封电子邮件（这并不难产生），您也在谈论很多周长。

希望这可以帮助。

干杯!

于 2013-10-29T21:42:19.147 回答
2

SMTP 服务器通常已经将它们存储为文件.eml格式。您可以选择以这种方式保留它们并使用您的数据库对它们进行编目和索引，或者您可以将所有内容存储在数据库中，但我个人认为这样做很危险，原因如下：

  1. 您的数据库会迅速增加大小，因为单个消息可以超过 10MB，而 NVARCHAR 使用 UNICODE，因此实际上是 20MB。存储方面，这是一个非常低效的解决方案；

  2. 没有数据库服务器可以很好地处理可变长度数据，即使您删除内容，您也可能会遇到性能问题和数据库文件不断增长的大小；

  3. Afaik 每个表都有 8TB 的限制，这可能取决于您的情况；

  4. 典型的备份会生成可能有数 TB 的巨大文件。您必须创建一个自定义备份解决方案来管理它；

  5. 当存储大量数据时，要考虑硬盘错误。如果某些扇区损坏，您可能会丢失一个随机的电子邮件文件，这通常没问题。如果数据库文件损坏，这将是一个灾难性的问题。较小的数据库占用的磁盘空间较小，扇区损坏的风险也较小。

于 2013-10-29T21:25:22.050 回答
1

您不想在 sql 中存储大量 blob 的原因之一是备份花费的时间越来越长，并且无法轻松拆分为可以与 SQL 服务器备份同时运行的单独文件服务器（或服务器）——当您将 SQL 用作文件存储时，仅此因素就会引起很多麻烦

于 2013-10-29T21:29:55.523 回答