我们正在寻找一个可以支持索引的内存数据库中的开源。
用例是我们有很多项目会大量增长。 每个项目都有一些我们需要查询的字段。 目前，我们将数据存储在应用程序的内存中。但是随着数据的增加，我们必须考虑分发/分片数据库。
我们已经看了几个选项
Redis群集 ，但它没有概念 索引或类似SQL的查询。
Apache Ignite 既可以在内存中，也可以分发并提供 SQL查询。然而，问题是点燃所有火 查询所有主节点，以便最终结果 比这些查询中最慢的慢。这似乎是一个问题 因为多个节点中的非执行/慢节点可以 真的让应用程序变慢了很多。进一步点燃，读取是 没有使用主人和奴隶，所以它是 难以扩展查询。增加节点将有 负面影响因为查询的数量会增加而且会增加 甚至更慢。
我们对其他解决方案持开放态度，但想知道多个查询是否会成为一个问题（如淡褐色）。
我们用例的理想解决方案是内存数据库，其索引可以通过增加从站的数量来读取。使其分布/分片将导致多个查询，我们不愿意，因为一个错误的节点可能会降低整个系统的速度。
答案 0 :(得分：11)
Hazelcast支持索引（已排序和未排序）以及重要的内容 Hazelcast没有多重查询问题。
Hazelcast支持PartitionPredicate，它将查询的执行限制为一个节点，该节点是传递给PartitionPredicate构造函数的密钥的primaryReplica。因此，如果您知道数据所在的位置，则只需查询此节点即可。因此，无需修复或实现任何支持它，您可以立即使用它。
一直使用它可能是不合理的。取决于你的用例。
对于扫描大量数据但返回较小结果的复杂查询，最好在内存中使用OBJECT。您应该获得出色的执行时间和较低的延迟。
答案 1 :(得分：9)
免责声明：我是GridGain员工和Apache Ignite提交者。
关于您的担忧的几条评论：
1）慢节点几乎会导致任何集群环境出现问题，因此我不认为这是一个缺点。这是你应该拥抱和接受的现实。有必要了解为什么它很慢并修复/升级它。
2）Ignite能够执行从常规缓存操作[1]和通过REPLICATED缓存执行的SQL查询的从属读取。事实上，使用REPLICATED缓存作为参考数据是Ignite能够顺利扩展的最重要的功能之一。
3）正如您所正确提到的，当前查询被广播到所有数据节点。我们将改进它。首先，我们将允许用户指定分区来执行[2]的查询。其次，我们将改进我们的优化器，以便它会提前尝试计算目标数据节点以避免广播[3]，[4]。两项改进都将很快公布。
4）最后，但并非最不重要 - 持久层将在几个月内发布[5]，这意味着Ignite将成为具有内存和持久性功能的分布式数据库。
[2] https://issues.apache.org/jira/browse/IGNITE-4523
[3] https://issues.apache.org/jira/browse/IGNITE-4509
答案 2 :(得分：1)
我可以对cassandra发表意见。每个节点的表的最大大小是可配置和可调的，因此它取决于您愿意支付的内存量。分区内置于cassandra中，因此cassandra基本上为您管理它。做分区比较简单。基本上，主键语法的第一部分是分区键，它确定数据集群中的哪个节点。
但我也猜你知道这个，因为你提到每个节点有多个查询。我猜周围没有好办法。
只是一个轻微的评论，cassandra没有主奴隶。每个节点都是相同的。基本上客户端询问集群中的任何节点，然后该节点成为协调节点，并且由于它获得了分区密钥，因此它知道要向数据请求的节点，然后将其提供给客户端。
除此之外，我猜你已经读了足够的cassandra（从我在你的问题中看到的）
基本上，它归结为访问模式，如果您知道如何访问数据，那么它就是最佳选择。但其他数据库也相当不错。
使用cassandra进行索引通常会隐藏一些潜在的性能问题。通常人们会避免它，因为在cassandra中必须为整个集群中的每条记录构建索引，并且每个节点完成它。这并没有真正扩展。基本上你总是要先查询，无论ypu如何用cassandra。
另外内存似乎是DSE cassandra的一部分。不是开源或社区的。你也必须考虑到这一点。