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

    通常来说，内存数据库并不适合用来作为交易系统的后台数据库，因为就像它的名称一样，数据是存储在内存当中的。如果我们在内存当中运行一个标准的交易型数据库，那么当系统出现故障或者机房突然断电了，那么就很有可能所有交易都丢失。也就是说它缺少交易系统中所必需的持久性，而持久性也是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列的数据。不要忘了，内存数据库往往自带数据压缩功能，而数据压缩比也会根据数据自身的情况而有所不同。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。