数据库vs Solr vs图形数据库（Neo4j）

我在想我的问题可能的解决方案（工具）。有一大堆地点（超过600 000）元素的集合。位置具有不同的语言名称，并以树形结构表示：区域 - >国家 - >管理部门 - >城市 - >邮编。用户可以添加自定义位置，但我计划这些操作很少发生。应用程序应提供有效的能力，以按位置名称，类型执行搜索，以构建分层名称（如“伦敦 - >英格兰 - >英国”），建立位置子树（即欧洲所有国家和城市）。数据库vs Solr vs图形数据库（Neo4j）

我已经考虑过三种解决方案。

平原数据库：位置将持有一些表和主楼逻辑将用Java代码来实现。在这种解决方案的情况下，我担心性能，因为搜索，构建树和创建自定义位置可能会涉及到额外的表连接。
SOLR：乍一看这个任务正好适用于solr：数据集很少变化，我们需要按名称搜索。但我担心如果Solr支点功能将满足树木建设需求。此外，我不确定Solr搜索是否会比普通DB好得多，因为搜索并不困难（只需使用短字符串名称搜索）。
graph db Neo4j：它似乎对构建树和子树有用。但我不知道搜索性能（看来我应该使用的社区版，它不具备一些有用的性能功能，如高速缓存等）

来源

2014-05-08 Vladimir Zenkevich

这实在是一个基于意见的问题。您可以使用任意数量的数据库类型解决您的问题。没有单一的正确答案，还有许多其他因素需要考虑，例如HA，数据摄取率，数据读取率等。 –

数据库是一个很大的NO。因为RDBMS并未针对基于关系的查询进行优化。例如，让我看看那些在我所在的同一家餐厅吃饭的人，这些人也属于我所在的地区。或者使它更复杂，一个数据库查询可能是一个杀手级别的关系要计算。就像我可以成为你的二级朋友，你的一个或多个朋友是我的朋友。

SOLR：Solr是一个不错的选择，但你必须看到它的性能影响。有这么多的行索引它可以是一个记忆杀手。在实施SOLR之前先通过这些。 http://wiki.apache.org/solr/SolrPerformanceProblems

http://wiki.apache.org/solr/SolrPerformanceFactors

SOLR也没有更多的逻辑搜索一个很好的解决方案与往常一样去为它来学习这一切。

Neo4J（或任何其他图形DB）是完美的解决方案。我自己实现了所有这三种技术，并且凭借我的经验，我发现Neo4J最适合这种需求。

但是，您必须了解如何备份数据库以及如何在发生崩溃时进行恢复。

一切顺利。

来源

2014-05-08 12:31:06

OP应该真正指出这些相对类型的查询执行的频率。层次结构的遍历肯定是neo4j的理想选择，但是通过位置名称进行搜索处于SOLR甚至RDBMS的最佳位置。另外，如果OP的层次结构只有3深（最大），那么RDBMS在那里可能并不那么糟糕。如果OP的层次结构很庞大，那么与neo4j的差异将占主导地位。但目前尚不清楚neo4j在这里是否最好;如果80％的工作负载是按名称搜索的，并且层次结构永远不会超过3深，那么RDBMS或SOLR可能会更好*总体*。 – FrobberOfBits

而......这个答案就是为什么这个问题应该以*基于意见为基础来关闭。*这个答案纯粹是基于意见的，但是被陈述为事实/绝对。 –

数据库vs Solr vs图形数据库（Neo4j）

回答

相关问题