数据库 vs Solr vs Graph DB（Neo4j）

Question

我正在为我的问题考虑可能的解决方案（工具）。 有一个包含大量（超过 60 万个）元素的位置集合。位置有名称（用不同的语言）并以树结构表示：区域->国家->行政部门->城市->压缩。用户可以添加自定义位置，但我计划这些操作很少发生。应用程序应提供按位置名称、类型执行搜索、构建分层名称（例如“伦敦->英格兰->英国”）、构建位置子树（例如欧洲这些国家的所有国家和城市）的高效能力。

我考虑了三种解决方案。

1. 普通数据库：位置将保存在某些表中，主要构建逻辑将在 java 代码中实现。在这种解决方案的情况下，我担心性能，因为搜索、构建树和创建自定义位置可能涉及额外的表连接。

2. SOLR：乍一看，这个任务正是针对 solr：数据集很少更改，我们需要按名称搜索。但我担心 Solr 枢轴功能是否会满足树构建的需求。另外我不确定 Solr 搜索是否会比普通 DB 好得多，因为搜索并不那么困难（只需通过短字符串的名称进行搜索）。

3. graph db Neo4j：它似乎对构建树和子树很有用。但是我不确定搜索性能（看来我应该使用社区版，它没有一些有用的性能功能，如缓存等）

Answer 1

数据库是个大问题。因为 RDBMS 没有针对基于关系的查询进行优化。例如，向我展示在我所在的同一家餐厅用餐并且属于我所在的同一地区的人。或者为了使其更复杂，数据库查询可能是计算关系级别的杀手。就像我可以成为你的第二级朋友一样，你的一个或多个朋友是/是我的朋友。

SOLR：Solr 是一个不错的选择，但您必须看到它对性能的影响。有这么多行要索引，它可能是一个内存杀手。在实现 SOLR 之前先完成这些。 http://wiki.apache.org/solr/SolrPerformanceProblems

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

SOLR 对于更多的逻辑搜索也不是一个好的解决方案，因为你必须在开始之前学习它。

Neo4J（或任何其他图形数据库）是完美的解决方案。我自己实现了所有这三种技术，根据我的经验，我发现 Neo4J 最适合这种要求。

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

一切顺利。