我正在考虑解决我的问题的可能解决方案（工具）。 有一系列位置具有大量（超过60万）元素。位置具有名称（使用不同语言）并以树形结构表示：region-＆gt; country-＆gt; admin division-＆gt; city-＆gt; zip。用户可以添加自定义位置，但我计划很少发生这些操作。应用程序应提供有效的能力，按位置名称，类型执行搜索，以建立分层名称（fe＆＃34;伦敦 - >英格兰 - >英国＆＃34;），建立位置子树（fe所有国家和城市）那些欧洲国家。）
我考虑了三种解决方案。
普通数据库：位置将保留在某些表中，主构建逻辑将在java代码中实现。在这个解决方案的情况下，我担心性能，因为搜索，构建树和创建自定义位置可能涉及额外的表连接。
SOLR ：乍一看这个任务完全适用于solr：数据集很少变化，我们需要按名称搜索。但我担心Solr的枢轴功能是否能满足树木的建造需求。此外，我不确定Solr搜索是否会比普通数据库好得多，因为搜索不是那么困难（只需搜索短字符串的名称）。
图db db Neo4j ：它似乎对构建树和子树很有用。但我不确定搜索性能（似乎我应该使用社区版，它没有一些有用的性能功能，如缓存等）。
答案 0 :(得分：2)
数据库是一个很大的NO 。因为RDBMS没有针对基于关系的查询进行优化。例如，向我展示在我所在的同一餐厅吃饭的人，也属于我所在的同一地区。或者为了使其更复杂，db查询可以成为计算关系级别的杀手。就像我可以成为你的二级朋友，你的一个或多个朋友是我的朋友。
SOLR ：Solr是一个不错的选择，但您必须看到它对性能的影响。有这么多行要索引它可能是一个内存杀手。在实施SOLR之前先完成这些操作。 http://wiki.apache.org/solr/SolrPerformanceProblems
http://wiki.apache.org/solr/SolrPerformanceFactors
SOLR 对于更多逻辑搜索也不是一个好的解决方案，因为您必须先学习它才能学习它。
Neo4J （或任何其他图表数据库）是完美的解决方案。我自己实现了所有这三种技术，根据我的经验，我发现Neo4J最适合这样的要求。
但是，您必须了解如何备份数据库以及如何在发生崩溃时恢复数据库。
一切顺利。