我们有一个应用程序可以获取实时数据并将其插入数据库。它每天在线4.5小时。我们在17个表中逐秒插入数据。用户可以随时向任何表查询最新的第二个数据和历史记录中的一些记录......
使用C＃控制台应用程序处理Feed和插入...
处理用户请求是通过WCF服务完成的......
我们发现插入是我们的瓶颈;大部分时间都在那里。我们投入大量时间试图微调表格和差异但结果并不令人满意
假设我们有足够的内存，将数据插入内存而不是拥有数据库的最佳做法是什么。目前，我们正在使用每秒更新和插入的数据表 我们的同事在feed-handler和WCF user-requests-handler之间建议了另一个WCF服务而不是数据库。 WCF中间层应该是基于TCP的，它将数据保存在自己的内存中。有人可能会说饲料处理程序可能会处理用户请求，而不是在两个进程之间有一个中间层，但是我们想分开一些事情，所以如果feed-handler崩溃我们仍希望能够为用户提供当前记录
我们时间有限，我们想在短时间内把所有东西都搬到记忆中。在2个进程中有一个WCF做坏事吗？我知道这些请求增加了一些开销，但所有这三个进程（feed-handler，内存数据库（WCF），用户请求处理程序（WCF）都将在同一台机器上，带宽不会那么多一个问题。
请协助！
答案 0 :(得分：2)
我会考虑创建数据缓存（这样您也可以减少数据库选择），并在将数据写入数据库后使缓存中的数据无效。这样，您可以批量调用以执行更大的插入而不是更小的插入，但将数据保留在内存中以便读者可以读取它。实际上，如果您知道数据何时过时，您可以避免完全读取数据库并将其用作后备存储 - 这样，数据库性能只会影响缓存的大小。
缓存中的数据失效将取决于它是写入数据库还是已经过时，而不是第一次 last 。
缓存层不需要复杂，但它应该是多线程的，以托管数据并将其保存在后台。该层将位于WCF服务，连接介质和WCF服务的后面，应该改进以包含控制台应用程序的逻辑+批处理的想法。然后控制台应用程序可以只连接到WCF并向其投掷结果。
更新：唯一要说的是投资分析器，看看您是否在代码中引入任何性能问题。另外，配置数据库。你提到你需要快速插入和选择 - 不幸的是，它们通常会互相折衷......
答案 1 :(得分：0)
您使用的是哪种数据库？ MySQL有一个存储引擎MEMORY，似乎适合这类事情。
答案 2 :(得分：0)
您是否正在将DataTable与DataAdapter一起使用？如果是这样，我建议你完全放弃它们。使用DBCommand直接插入记录。当用户请求报告时，使用DataReader读取数据，或使用DataTable.Load（IDataReader）填充DataTable对象。
内存中的故事数据可能会在发生崩溃或电源故障时丢失数据。