哪种NoSQL实现最合适？

Question

我是NoSQL的新手，正在努力寻找最适合我正在构建的应用程序的NoSQL实现方式。

我的Java应用程序需要一个内存中的哈希表，其中包含数百万到数十亿个条目，因为它模拟了一个单层神经网络。现在我们正在使用Trove，以便能够使用基元作为键和值来减小映射的大小并增加访问速度。该映射是一个映射的映射，其中外部映射的键是长整型，而内部映射具有长整型/浮点型键/值。

我们需要能够在应用程序启动时从磁盘读取保存的状态到映射的映射中。对映射的更改也需要连续或按照某个预定间隔保存到磁盘。

我最初被OrientDB的文档和对象数据库所吸引，但目前我仍不确定哪个更好。然后我发现了Redis，它是一个键值存储，并使用可转储到磁盘的内存数据集，包括主从复制。然而，它似乎不能将映射的值设置为非字符串类型。

我正在寻找解决方案，是否在正确的地方？目前，我喜欢Redis的内存和主从复制方面，但我喜欢OrientDB的对象/文档功能，因为我的数据结构比简单字符串复杂，并且使用Trove与基本键/值类型非常有优势。如果读取便宜而写入昂贵，则会更好。

你有什么想法？

- herrtim

Answer 1

为什么不直接将Trove数据结构序列化到磁盘上？ 根据文档(http://trove4j.sourceforge.net/javadocs/serialized-form.html)，似乎支持这种方式，但很难确定，因为它全部都是自动生成的乱七八糟而不是精心制作的教程。对于您的用例来说，仍然不明显为什么需要一个正确的数据库，也许KISS适用。

- John Zwinck

---

谢谢，我喜欢这个答案。我在文档中忽略了它，现在我将编写一些测试代码来尝试它。这可能最终会成为最佳解决方案。缺点是我必须编写自己的持久化代码，但最终我的应用程序将被优化。如果我试图把它塞进NoSQL框架中，我可能不得不做出丑陋的妥协。 - herrtim

Answer 2

OrientDB拥有最灵活的引擎，支持索引、图形、事务和复杂的JSON文档。为什么不试试呢？

- Lvca

Answer 3

请查看Java-Chronicle。它是一个低延迟持久化库。我认为你会发现它为这种类型的数据提供了出色的性能。

- Nicholas

---

这看起来相当令人印象深刻，特别是写入磁盘的速度。哇。不过文档和示例相当稀少，我也不确定如何使用它来实现我的映射表。 - herrtim

Answer 4

如果您想使用Redis来实现这个，最好选择ZSETs或HASHes作为底层结构（Redis支持结构而不仅仅是字符串值）。除非需要根据值/排序顺序来获取您的地图部分，否则HASHes可能是最佳选择（在内存和速度方面）。

因此，您可能希望使用long -> {long:float, ...}。也就是说，长整数映射到长/浮点地图。然后，您可以使用HGET获取地图中的单个条目，使用HMGET获取多个条目，或者使用HGETALL获取完整的映射。您可以查看命令参考http://redis.io/commands 在节省空间方面，根据期望的HASHes大小，您可以调整它们以使用更少的空间，而对性能的负面影响有限/无影响。

在持久性方面，您可以使用快照运行Redis，或者使用追加文件进行增量保存。您可以在这里查看持久性文档http://redis.io/topics/persistence。

如果您想提出更具针对性的问题，您应该转到邮件列表https://groups.google.com/forum/?fromgroups=#!topic/redis-db/33ZYReULius

- Josiah

---

感谢您提供如此详细的答案。我开始看到 Redis 可能真正适用于这个问题。为了让它与我的当前 Java 应用程序配合使用，我可以使用 Jedis 项目。看起来 Jedis 将通过端口与 Redis 进行通信。我需要进行一些基准测试，以比较纯 Java Trove 实现与 Jedis/Redis 实现，看看哪个更好。 - herrtim

Answer 5

Redis支持比简单字符串更复杂的数据结构，例如列表、(排序)集合或哈希表，这可能对您的领域模型有所帮助。另一方面，您的神经网络可以利用OrientDB丰富的图形能力，具体取决于其结构。

- yojimbo87