NoSQL数据库性能

Question

我一直在为NoSQL技术设计和开发一个C#.Net数据库引擎(使用C#.Net)。与可用的NoSQL数据库类似，我以JSON格式存储所有文档，并将所有相关文档记录(即Album1、Album2、Album3)保存在一个文件中。

我一直在测试该解决方案，以查看它在实际场景中的实际性能，并且使用Visual测试框架，我的解决方案在大约12秒内成功地查询和搜索了2,000,000个文档。

我的第一个问题是，如果这是一个好的结果，它的表现有多好？

其次，由于所有记录最终都保存在文件中，所以我实现了一种单例设计模式，它缓冲内存中的所有物理文档，以避免并发文件处理的需要。假设有10个文档类别(专辑、流派、艺术家、.)这将消耗超过8GB的RAM，这是不好的。另一方面，如果我禁用缓冲，并使所有查询依赖于搜索物理文件，假设我获得100个并发请求，每个请求需要12秒才能完成，那么这100个请求可能需要1200秒才能完成--我认为这是很糟糕的。

第二个问题是，如何优化这个问题？我的意思是，与SQL数据库不同的是，NoSQL数据库的目的是保存大量数据，而这样的海量数据不能在内存中完全缓冲，也不能在磁盘上反复搜索。从理论上讲，应该如何实现这一点？

Answer 1

每秒100,000 ish记录听起来不像一个标题数字那么糟糕。然而，如果没有背景，它就毫无意义。存储阵列上的规格是什么？你是否接近了制造商的IOPS和带宽号码？它与磁盘性能测试工具的报告值相比如何？当分析重载下的应用程序时，所花费的时间在哪里？系统IO或CPU绑定吗？

一些高端服务器确实有大量的内存。64 is是我见过的最大的。但你是对的，把所有东西都保存在记忆里在一般情况下是行不通的。有一套工作的概念。这些是当前用户正在读取和写入的行。系统将它们保存在内存中，并不时地将它们同步到磁盘上。当用户继续进行新的工作时，系统通过从RAM中清除最近使用最少的数据来腾出空间。

要找到特定的记录，您需要索引。这些交易额外的磁盘和预处理时间，以减少查找时间。有许多不同的索引算法，每一个都有优缺点。

对于大型OLAP工作，您可能只需读取磁盘上的所有数据才能执行查询。可以通过预处理获得摘要值(多维数据集和类似值)。

这是一项巨大的事业。整个职业生涯都在努力做到这一点。你有一个工作的产品是令人印象深刻的。