在索引的内存数据库中寻找一个开源

Question

我们正在寻找一个可以支持索引的内存数据库中的开源.

用例是我们有很多项目会在很大程度上增长.每个项目都有一些我们需要查询的字段.目前,我们将数据存储在应用程序的内存中.但是随着数据的增加,我们必须考虑分发/分片数据库.

我们已经看了几个选项

1. 可以使用 Redis集群,但它没有索引或SQL查询等概念.

2. Apache Ignite既可以在内存中,也可以分发,也可以提供SQL查询.但是,问题是ignite会将所有查询激活到所有主节点,因此最终结果将比这些查询中最慢的结果慢.这似乎是一个问题,因为许多节点中的非执行/慢节点可能会真正减慢应用程序的速度.进一步点燃,从主服务器完成读取并且不使用从服务器,因此难以扩展查询.增加节点将产生负面影响,因为查询的数量将增加,甚至会更慢.

3. Cassandra - 可以使用cassandra中的内存中选项,但似乎每个节点的表的最大大小可以是1 GB.如果我们的表超过1 GB,我们将不得不求助于分区,这将导致cassandra进行多次查询(每个节点一个),这是一个问题(与点燃相同).不确定是否可以通过增加从属数量来扩展cassandra内存表中的读取.

我们对其他解决方案持开放态度,但想知道多查询是否会成为一个问题(如hazelcast).

对于我们的用例,理想的解决方案是内存数据库,其索引可以通过增加从站的数量来读取.使其分布/分片将导致多个查询,我们不情愿,因为一个错误的节点可能会降低整个系统的速度.

Answer 1

Hazelcast支持索引(排序和未排序)以及重要的是Hazelcast没有Multi-Query问题.

Hazelcast支持将PartitionPredicate查询的执行限制为一个节点,该节点是传递给该构造函数的密钥的primaryReplica PartitionPredicate.因此,如果您知道数据所在的位置,则只需查询此节点即可.因此,无需修复或实现任何支持它,您可以立即使用它.一直使用它可能是不合理的.取决于您的用例.

对于扫描大量数据但返回小结果的复杂查询,最好使用OBJECTinMemoryFormat.您应该获得出色的执行时间和较低的延迟.

Answer 2

免责声明:我是GridGain员工和Apache Ignite提交者.

关于您的担忧的一些评论:

1)慢节点几乎会在任何集群环境中导致问题,因此我不认为这是一个缺点.这是你应该拥抱和接受的现实.有必要了解为什么它很慢并修复/升级它.

2)Ignite能够执行从常规缓存操作[1]和通过REPLICATED缓存执行的SQL查询的从属读取.实际上,使用REPLICATED缓存作为参考数据是允许Ignite顺利扩展的最重要功能之一.

3)正如您所正确提到的,当前查询被广播到所有数据节点.我们将改进它.首先,我们将允许用户指定分区来执行[2]的查询.其次,我们将改进我们的优化器,以便它会提前尝试计算目标数据节点以避免广播[3],[4].两项改进都将很快公布.

4)最后,但并非最不重要 - 持久层将在几个月内发布[5],这意味着Ignite将成为具有内存和持久性功能的分布式数据库.

[1] https://ignite.apache.org/releases/mobile/org/apache/ignite/configuration/CacheConfiguration.html#isReadFromBackup()

[2] https://issues.apache.org/jira/browse/IGNITE-4523

[3] https://issues.apache.org/jira/browse/IGNITE-4509

[4] https://issues.apache.org/jira/browse/IGNITE-4510

[5] http://apache-ignite-developers.2346864.n4.nabble.com/GridGain-Donates-Persistent-Distributed-Store-To-ASF-Apache-Ignite-tc16788.html