database-design - 大量写入 Web 应用程序的数据库设计

Question

我们向客户提供的许多 LOB 应用程序都具有营销/促销性质(抽奖、事件注册等)。大多数应用程序虽然很简单，但对数据库的要求很高。例如，想象一个“注册”类型的网站作为在 super 碗期间播放的商业广告的支持(是的，我们有几个)。

尽管我们已经非常擅长优化我们的 Web 应用程序代码，但数据库仍然是一个问题，尽管应用程序相对简单。流程通常类似于:

从数据库读取以检测现有记录

如果记录是新记录，则写入数据库

在许多情况下，这就是我们的应用程序需要执行的所有数据访问。然而，考虑到它是应用程序的唯一目的，对这个简单的过程进行大幅度优化是非常重要的。

出于这个问题的目的，我们有一个服务器运行一个用于数据文件的 raid 5 磁盘阵列，另一个运行用于日志的 raid 5 阵列。此时操作系统为Windows 2003标准32位，服务器内存为4GB。一些应用程序使用 SQL 2005 标准，而其他应用程序使用 MySQL 5.1。我是 非常清楚某些操作系统和硬件优化在这里是可能的，但我希望首先从软件方面解决我的需求。广泛的分析告诉我们 磁盘IO一般是主要瓶颈 .

说了这么多，并且知道缓存不会有太大帮助，因为大多数读取都是唯一的并且返回的数据很少(通常只有一点表示记录是否存在)，我正在考虑进入 in 领域-memory 数据库作为对真实数据库的一种写缓存层。鉴于我们的大部分高流量本质上都是零星的，并且不会持续几个小时，这似乎很合适。此外，在大多数情况下，由于服务器崩溃而导致的几分钟数据潜在丢失是可以接受的。

以最简单的形式，我将修改一个典型的注册应用程序以执行以下操作:

查询现有记录的磁盘 DB 和内存 DB

如果没有，则将数据写入内存DB并返回

定期将内存 DB 刷新到磁盘 DB

我的问题是 :对于这个中间内存数据库，我有哪些选择？我已经尝试了内存中的哈希表、数据表等，但我正在寻找其他选项，甚至是完全不同方法的建议。

Answer 1

如果您不需要实时知道是否有现有记录(即记录进入那里很重要，但您不需要向用户报告它是新的还是现有的)，您可以以允许极快写入时间的方式构建数据库，而无需内存数据库，如果服务器关闭或工作进程重新启动，内存数据库会带来许多潜在问题。

在您的数据库中为与此写入繁重的流相关的每个表创建两个表。一张表应该是你的“事件”表，并且应该尽可能地进行写优化(即没有索引，除非移动到读取表时，否则永远不会被读取)。您的另一个表应该是您的读取优化表 - 根据任何报告考虑等进行适当的索引。

每当您写入实时表时，请忽略与记录是新记录还是现有记录有关的任何事情，或者除了尽快将该数据放入表中并从数据库中取出之外的任何事情。设置一个计划作业，将记录从事件表移动到读取优化表，并担心匹配那里的现有记录。理想情况下，这将在非高峰时间完成，但否则您可能需要考虑第三个临时表，以便在任何时候都没有对实时表的争用。