背景
我们一直在努力尝试为“高性能”应用程序提供解决方案。该应用程序基本上是一个高吞吐量的内存管理器，具有同步回磁盘。 “读取”和“写入”非常高，每秒约3000次交易。我们尽可能地在内存中尝试做，但最终数据变得陈旧，需要刷新到磁盘，这就是一个巨大的“瓶颈”。该应用程序是多线程的，有大约50个线程。没有IPC（进程间通信）
尝试
我们最初是用Java编写的，它运行得很好，直到一定的负载，瓶颈被击中而且它无法跟上。 然后我们在C＃中尝试了它，并且达到了相同的瓶颈。 我们尝试使用非托管代码（C＃），虽然在初始测试中使用MMF（内存映射文件）非常快，但在生产中，读取速度很慢（正在使用视图）。 我们确实尝试过CouchBase，但我们偶然发现围绕高网络利用率的问题。这可能是我们的配置不佳！
额外信息：在我们的Java尝试（非MMF）中，我们带有需要刷新到磁盘的信息队列的线程构建到无法跟上“写入”的程度到磁盘。 在我们的C＃Memory-Map文件方法中，问题是READS非常慢，而且WRITES工作正常。出于某种原因，视图很慢！
问题
所以问题是，您打算传输大量数据的情况;有人可以协助一种可能有帮助的方法或建筑设计吗？我知道这似乎有点宽泛，但我认为高性能，高吞吐量的具体性质应该缩小答案范围。
有人可以保证在这样的级别使用Couchbase，MongoDB或Cassandra吗？其他想法或 解决方案将不胜感激。
答案 0 :(得分：2)
海量数据和磁盘访问。我们在谈论什么样的磁盘？如果您使用多个文件，HDD往往会花费大量时间来移动头部。 （但是，如果使用SSD，这应该不是问题。）此外，您应该利用内存映射文件以页面大小的块进行管理这一事实。如果可能，数据结构应与页面边界对齐。
但无论如何，你必须确保知道 瓶颈是什么。例如，如果由于线程同步而实际上失去了时间，那么优化数据结构将无济于事。如果您正在使用硬盘驱动器，页面对齐可能无助于将所有内容整合到单个文件中。因此，使用适当的工具来确定哪些制动器仍然阻碍您。
使用通用数据库实现可能无法帮助您。毕竟，它们是通用的。如果性能确实是一个很大的问题，那么考虑到您的需求的特殊实现可能会胜过这些更通用的实现。
答案 1 :(得分：-1)
如果你想尽可能快地避免持久性和队列的写入，并在读取时使用内存疮/缓存。
语言与它没什么关系。\