请问什么样的应用更合适内存数据库？

通常来说，内存数据库并不适合用来作为交易系统的后台数据库，因为就像它的名称一样，数据是存储在内存当中的。如果我们在内存当中运行一个标准的交易型数据库，那么当系统出现故障或者机房突然断电了，那么就很有可能所有交易都丢失。也就是说它缺少交易系统中所必需的持久性，而持久性也是ACID标准中非常重要的一环。

然而这样的情况正在发生变化，越来越多新的内存技术开始支持ACID，比如微软就刚刚推出了SQL Server 2014内存OLTP功能，甲骨文于去年宣布将推出Oracle 12c内存数据库选件，而SAP的HANA内存数据库声称将支持OLTP以及OLAP。

然而，我们看到的大量内存数据库还是用来跑分析应用，因为交易数据都存储在传统磁盘当中，而内存数据库中运行都只是原始数据的副本。

更具体来说，内存数据库最佳的应用场景是相对小型数据集的分析负载，因为尽管硬件的价格在不断下降，但内存设备还是要比传统磁盘但价格贵上很多。

请记住，“相对小型的数据集”只是代表着你可以负担得起的数据规模，这些数据是要存放在内存设备当中的。事实上，相对小的概念有时会让你大吃一惊。举个例子，我最近为一家软件厂商做了一个算术题，让他们了解到相对小究竟有多大。

为了尽量直观一些，我们假定你想要分析一个单独存储20列数据的表。其中一半的列都是文本（平均长度7个字符），有5列是日期数据，3列是整型而剩下的是实际数字。

像这样拥有150万行数据的CSV表大概是236 MB大小，也就是说1/4的GB。如果我们把表的大小再翻一倍，也就是说有300万行数据，40列数据，那么它也不过只有4GB而已。而现在大部分的笔记本电脑就已经拥有8GB内存以上了，所以即使在没有压缩的情况下，像这种规模的数据集也属于小数据的范畴，完全可以使用内存数据库来进行分析。

服务器的内存肯定比个人笔记本电脑的内存要大得多，而32GB的内存就可以分析5000万行，80列的数据。不要忘了，内存数据库往往自带数据压缩功能，而数据压缩比也会根据数据自身的情况而有所不同。