重写Web应用程序的数据库设计

接受“一切都是信息,数据库是备份”的新概念。当您有东西要存储时,创建一个消息并使用xmpp将它发送到一个黑盒(如ejabberd)。让blackbox按照自己的计划更新数据库。像twitter这样的网站就是这样运作的。

看看这个幻灯片: http://www.slideshare.net/kellan/beyond-rest

如果您不需要实时知道是否存在现有记录(即记录在其中很重要,但您不需要向用户报告它是新的还是现有的),您可以以允许极快写入时间的方式构建数据库,而不需要内存中的数据库,因为内存中的数据库承载了大量如果服务器停机或工作进程重新启动,则可能出现问题。

在数据库中为每个与此写重流相关的表创建两个表。一个表应该是您的“活动”表,并且应该尽可能地进行写优化(即,没有索引,除非移动到读取表,否则永远不会从中读取)。您的另一个表应该是您的读优化表-根据任何报告注意事项等进行索引。

无论何时,当您正在写入活动表时,忽略与记录是新记录还是现有记录有关的任何事情,或者与将数据尽可能快地放入表并从数据库中取出无关的任何事情。设置一个计划作业,将记录从活动表移到读取优化表中,并担心在该表中匹配现有记录。理想情况下,这将在非高峰时间完成,但否则,您可能需要考虑第三个临时表,以便在任何时候都不会对活动表产生争用。

与编程无关,但肯定会有帮助:获得一些新的固态磁盘。

是的,它们的大小是昂贵的,但由于磁盘IO是瓶颈,将当前的HDD换成某些SSD将大大提高性能。

这里有一个奇怪的想法:不要使用数据库进行初始捕获。设计两三个快速索引文件,其格式不需要经常更改。捕获这些文件中的数据。

编写一些适当触发的软件,将捕获的数据复制到数据库中,但不会延迟交互式用户。标记复制的数据以防止复制,并回收文件中的空间。

现在,您可以使用在多个用途之间共享数据的思想来设计数据库,而不是使用跟上捕获过程的思想。毕竟,共享数据才是数据库真正的亮点。

SQLite有一个 in memory 操作模式。如果在页面点击处理程序后面有一个持久的服务器进程,那么这就可以工作。

否则,常规的基于文件的DBS会被愚弄到将其文件写入内存文件系统,比如 tmpfs .

在我看来,您应该能够使用一个RDBMS来适应您的工作负载,该RDBMS具有用户大小的缓存。我看到的是每秒10000个索引记录的顺序,一个简单的C++可调用的RDBMS和普通的硬件。包括提交到磁盘。此外,由于您可能只查看一个记录中的一个小字段,因此请查找一个面向列的数据库——一个沿着列存储数据的数据库。如果你只对一个领域感兴趣,那么阅读整行没有意义。

正如许多其他人提到的,优化数据库模式以进行写入而不是读取是您的第一个调用点,尽管我猜您已经到了那里。

在研究内存数据库之前,您可能需要查看一些可用的ORM,特别是NHibernate。

nhibernate将一些数据保存在内存中,并允许您控制何时从内存中“刷新”数据更新并与数据库同步。

你可能觉得值得一看。

编辑:严格关注磁盘I/O…

1. 尽可能多地删除不必要的索引。指数不是免费的——空间或时间。
2. 撕掉任何你不需要的特殊触发器或约束。
3. 删除任何不是绝对关键的实体关系/关系完整性操作符。
4. 如果您当前的DBMS支持它,请将事务表分为多个磁盘(例如,循环)。
5. 考虑到添加更多相互独立的数据库服务器(即不涉及复制);为此,您需要一个调度程序来决定哪个服务器将接受事务,以及一个合并事务的方案/单独进程。

将数据库逻辑的数量最小化,并从侧面添加服务器(而不是使用边缘服务器技术),这基本上是易趣采用的方法。

我不知道您提到的数据库,但是如果数据库的内容(或者至少重要的表)适合内存,Oracle就能够将其固定在缓存中,所以它基本上就像内存中的数据库一样。

我还将检查数据库的隔离级别设置。如果你能放松这些,你就可以减少锁定。

最后考虑删除唯一约束,或者在高峰时间禁用它们。