如何为内存处理建模数据[关闭]答案

【问题标题】：How to model data for in-memory processing [closed]如何为内存处理建模数据[关闭]
【发布时间】：2015-09-01 20:47:33
【问题描述】：

我有很多静态数据（即只读数据，不是事务性的），这些数据在几天内只更新一次。

我必须支持对该数据的搜索（api 调用，而不是 sql）。所以我想我只是将它加载到内存中，并偶尔刷新内存中的数据。 RAM 应该不是问题，因为我们使用的是 64 位...数据可以在 2 GB 到 50 GB 范围内。

我希望我可以比查询数据库（索引表）更快地处理对内存数据的搜索。

我可以采用某种“方法”来设计这个内存数据吗？

更新：

我的问题不在于使用什么 RDBMS / noSQLDB。当我不再受存储机制的约束时，我想知道如何在内存中构造数据。

【问题讨论】：

您可以使用内存中的关系数据库，例如HSQLDB。
这真的是最好的方法吗？
我会说这在很大程度上取决于数据类型以及您需要支持的搜索类型。图像搜索可能需要与纯文本数据上的简单子字符串匹配或结构化数据上的复杂关系查询不同的解决方案。您应该添加有关数据和查询类型的更多信息。
我正在研究一个关系数据库。类似于跟踪商店库存或存储公司员工信息的东西。我确实有几个具有日期时间组件的实体来跟踪发生的事件（以毫秒为单位）。所以是的，大多数查询将是“搜索 where something = "this" 或类似 "this%"
为什么不把它存入数据库呢？使用数据库进行查询搜索难道不合逻辑吗？

【解决方案1】：

我以前使用过 Redis (http://redis.io/)，它的内存存储速度非常快。作为一种方法，为您的数据创建键有助于优化任何搜索，redis 支持这一点。

如果您还需要任何类型的数据处理，您可以看看 Hadoop / HBase。

【讨论】：

1) Hadoop 是磁盘上的节点分布式系统，问题是关于内存中的，显然是单个服务器。 2) Hadoop 是关于处理数据，而不是搜索。够了。甚至 Spark/Elasticsearch/cassandra 在任何方面都更好，尽管 99% 的人认为它们也不能最好地解决实际 OP 的问题。
处理部分是对的 - Hadoop 只有在涉及数据处理时才值得一提。但他确实需要大量数据 ~ 50GB，因此内存存储可能并不是唯一的选择。
@leventov 如果正在设计数据，例如我有实体的键，然后将 key=> 实体记录存储在 redis/cassandra 之类的东西中，那么这与使用RDMS 并为每列创建一堆索引？

【解决方案2】：

几年前，我将prevayler 用于非数据库Web 应用程序。它非常快！它使用 POJO。易于理解和实施。

数据结构非常简单。将其视为具有默认节点的树。 Prevayler 知道树的根，然后您将数据添加到这棵树。您可以拍摄树的快照作为备份机制。您甚至可以使用 XML 快照。

Prevayler 是最早的此类产品之一。我相信还有其他图书馆。在决定使用哪一个之前，请先进行一些研究。

干杯。

【讨论】：

【解决方案3】：

您是否正在尝试学习如何构建哈希表？

继续阅读Binary Search Trees，阅读一些算法设计方面的书籍.. 可能阅读The art of computer programming。

或者使用您的特定语言使用的任何 Hashtable 实现。

许多人推荐数据库仅仅是因为，除非您的模型适合简单的哈希表模型，否则您最终将需要一个数据库（自己做索引和连接算法是愚蠢的）。这是In-Memory databases 的列表，它可能会帮助您选择路径。您选择的很多内容取决于您的平台，以及您是否想花钱。

【讨论】：

【解决方案4】：

这主要取决于您的访问模式以及您希望如何处理数据。

例如，如果您想要快速搜索并对部分数据进行排序，那么红黑树数据结构可能是一个很好的方法。或者如果你想要简单的键值，你可以使用哈希表。

但是实现这些数据结构可能会很棘手，而且很多人之前已经多次解决过这个问题。

强烈建议在内存数据库中使用 redis 或其他解决方案。只需干燥。

【讨论】：

【解决方案5】：

这完全取决于您使用的数据类型以及您想要对其执行的搜索类型。

例如，对于基于散列的结构，您不能支持部分单词搜索。

如果您的数据确实是关系型的（有很多列和关系），您可以选择内存中的关系型数据库。您可以索引所有可搜索的列。但是RDBMS是没有用的，如果你的数据只是一堆键值对或者只是一堆段落。

如果不了解您的要求，则无法在此处建议特定的 DS。

我建议您探索数据结构（如搜索树、尝试、哈希表）、数据库（如 redis）、搜索引擎（如 solr、lucene），以找出最适合您的需求。

【讨论】：

我读到的关于 Redis/Cassandra 等的东西越多。似乎它们真的只是带有抽象的键值存储。即使您建议为每个可搜索列建立索引，也意味着会有很多键值存储（即索引）。
我认为可以归结为： 1. 找出您想要精确匹配访问的数据（键需要与输入完全匹配），然后使用一些 HashTable 实现。 2.找出你想要“Like-Match Access”的数据（键可以是输入的子字符串），然后使用一些树实现。
想一想，即使是“树存储”……实际上也只是一个相互关联的大键值对。
感谢您的意见。特别是关于 Trie 和 Solr。
Tries 允许部分搜索与实际字符串开头匹配的子字符串。尝试还允许您实现“键入时建议”类型的功能。如果您希望实现完整的子字符串搜索，请探索后缀树。