问题标签 [in-memory]

我目前正在实现一个 grails web-app，它有几个复杂的表单，只要实体或顶级域对象不是，关联图上的修改应该在“内存中”（即 http 会话）进行管理保存。

例如

从上到下：文档 -> 类别 -> 子类别 ...

要求：对文档/类别/子类别的修改仅应在保存文档时保存，不得在其他情况下保存。

我的第一种方法是将关联 ID 存储在 http 会话中，但这最终会在我的 DocumentController.update 操作中产生很多线索代码，这些代码将会话状态与当前持久状态同步

当涉及到实际修改数据（例如类别）时，线索代码变得更加糟糕，这意味着在保存顶级实体时必须分离/重新附加/合并修改后的类别对象。

我会对你对如此长跨度的作品单元的想法非常感兴趣。

所以我最近了解到JDK 1.6 中提供了新的JavaCompiler API 。这使得直接从运行代码编译String到文件变得非常简单：.class

您可以JavaSourceFromString从Javadoc获取源代码。

这将非常方便地编译sourceCode到Foo.class当前工作目录中。

我的问题是：是否可以直接编译为byte[]数组，并避免完全处理FileI/O 的混乱？

我在内存中有一个excel字符串（我构建的）；代码看起来像这样：

只有当我物理保存文件时，我才能将文件打开为 excel 表；但是有没有其他方法可以将内存中的 xml 字符串作为 excel 表打开？

我有一个导入数据表的 csv 文件。此外，我创建了一个带有多个查询的 TableAdapter。是否有可能直接在“内存中”DataTable 上执行与 TableAdapter 关联的查询（似乎不是这样），还是我总是必须先将导入的 DataTable 写入数据库，然后在上执行 TableAdapter 查询持久化数据？我想直接使用数据表，因为它是一个小项目，不值得将数据从值对象来回转换为数据表或使用 OR 映射器。

提前致谢！

此致，

安德烈亚斯

PS：只是数据量很小，所以对内存的影响应该不会那么大。

如何在内存中将 HTML 字符串转换为 MHT (MHTML)。我根本不想使用本地文件系统？我正在使用 C#。

我有一个内存表，其中填充了自定义格式文件中的数据。我想将其用作数据的存储库，而不会将其复制到其他地方。每条记录都有一个特殊的标签字段，可以是 1..30。我想创建最多 30 个可以提供给 DBGrid 或 DBChart 的虚拟“表”，它们看起来每个都包含与我的标记字段对应的相关记录集。我是数据库工作的新手，但对 Delphi 了解很多，所以我可以自己动手做一个解决方案，并使用简单的迭代过程创建更多的内存表。我宁愿有一些更具可扩展性的东西。我看到有一个 SQL 选择语句，但是在快速的小提琴（使用 TQuery）上，我看不出这将如何在内存表（来自 DevExpress）上工作。

我在内存中有几个中型数据集，我需要能够快速过滤和查找信息。数据集足够小，我不想在每次需要条目时都访问数据库，但又足够大，以至于我真的需要以某种方式索引数据。

目前，我正在使用带有一个或多个字典的 POCO 对象进行索引。当我需要通过特定键查找某些内容时，这非常有用，但有时情况并非如此。例如，我经常需要在特定日期时间范围内查找条目。有时我需要最低价格的条目。大多数情况下，查询会同时查看几个简单的键和一两个其他字段。

是否有任何工具、产品、库（针对 .NET 框架）可以帮助我解决这个问题？还是我需要拿起那本尘土飞扬的旧算法书并开始查看搜索树？

一个例子：

旅行

• 出发代码
• 目的地代码
• 酒店代码
• 房号
• 日期
• 价格

我需要查询类似于“让我在 2010 年 3 月 9 日到 2010 年 3 月 12 日之间进行最便宜的旅行，其中 DepartureCode=LAX DestinationCode=NYC”

为了防止 SQLite 内存数据库被清理，必须使用相同的连接来访问数据库。但是，使用相同的连接会导致 SQLite 同步对数据库的访问。因此，如果我有许多线程对内存数据库执行读取操作，那么在多核机器上运行的速度比针对文件支持的数据库运行完全相同的代码要慢。

有什么办法可以两全其美？也就是说，允许对数据库进行多次并发调用的内存数据库？

我正在寻找有关具有 C++ 接口或用 C++ 编写的内存中键值存储引擎或库的建议。

我正在寻找可以毫无问题地扩展到大约 100mill 键值对并且在 linux 和 win32/64 上兼容/可编译的解决方案

I currently have a data solution in RDBMS. The load on the server will grow by 10x, and I do not believe it will scale.

I believe what I need is a data store that can provide fault tolerant, scalable and that can retrieve data extremely fast.

The primary purpose of the data store is retrieve data very fast. The queries that will access this data will have conditions across many different columns (30 columns and probably many more). I hope this is enough info.

I have read about many different types of data stores that include NoSQL, In-Memory, Distributed Hashed, Key-Value, Information Retrieval Library, Document Store, Structured Storage, Distributed Database, Tabular and others. And then there are over 2 dozen products that implement these database types. This is a lot of stuff to digest and figure out which would provide the best solution.

It would be preferred that the solution run on Windows and is compatible with Microsoft .NET.

Base on the information above, does any one have any suggestions and why?

Thanks