我已经查看了很多论坛条目。
我的用例是以非规范化架构从SQL Server向Solr提取大量数据，并能够快速搜索。
我们当前的UI定期更新SQL服务器上的数据以进行操作，但搜索速度非常慢。我们希望能够将所有数据最初从数据库中提取到Solr中，然后才能进行在批量（尽可能频繁）的常规进口中进行delta进口，以保持数据尽可能接近实时。我还没有做过任何测试，并试图根据其他人的经验提出架构用。
我听说索引会减慢查询/搜索的速度，我想避免使用它来解决问题。我已经获得了10-30分钟的延迟，因为它能够跟踪用例中的包裹 - 这意味着能够在30分钟内对三角洲进行索引。
虽然有多个表连接，但有效负载很重，但这只是用于检索它并将其转储到Solr端的非规范化模式。这个想法是真正加速从非规范化Solr模式中搜索和检索数据。
我更担心的是数据会在全球范围内定期更新，并且需要通过一些脚本以3-5分钟的间隔通过delta-imports进行同步。我不希望这个delta索引过程完全影响搜索操作。
10毫升行 - ＆gt;非规范化 - ＆gt;索引大小 - ＆gt; 30万行
1000次更新/分钟
5000次/分钟
使用 SolrCloud方法，我可以使用主/从方法与Leader（作为索引发生的主人）和 副本（搜索发生的位置） - 确切地说？我们的前端代码将访问Solr REST API。 我还将收集别名方法视为另一种选择，但是必须以某种方式将UI定期指向一组新的集合。
由于索引确实需要时间将数据从RDBMS提取到Solr索引，因此我正在努力争取处理NRT数据。 添加softCommits似乎有自己的一套需要注意的问题。
感谢任何帮助，
维杰
答案 0 :(得分：1)
使用SolrCloud 4.3版建立了类似的系统来索引数据（约10亿条目），我认为您应该考虑以下设计挑战：
<强> 1。索引数据的分发：文档使用复合路由器在分片上自动分发，基于在文档的唯一键上计算的哈希。每个碎片都有一个领导者和许多复制品。您必须认真考虑分片数量，因为创建群集后，此数字是固定的。从版本4.4开始，Solr允许分片分割但是如果每个分片没有被相同因子分割，则群集将不会平衡。在我们测试此功能时，实现仍然不稳定。一旦获得了分片数量和每个分片的潜在大小，您现在可以使用estimator mentionned by buddy86来确定solr实例的大小。
<强> 2。索引数据：在我看来，直接使用前端访问Solr REST API并不是一个好的开始。您应该使用SolrJ，solr java客户端，并使用CloudSolrServer索引您的数据。此实现符合您表达的每个要求：更新直接发送到分片的领导者，搜索查询在副本之间进行负载平衡（循环）。将文档编入索引后，将使用HTTP自动将其分派给副本。为了避免陷入陷阱，请求只使用commitWithins选项（约1分钟）。要扩大搜索容量，您只需添加更多副本。
我们的系统中没有使用随Solr提供的ETL工具，因为我们需要动态地对后端RDMBS进行索引更新（您的用例似乎是相同的），最终但不常见，我们需要同时重新索引整个数据库以进行恢复。 ETL工具对于这些任务来说太简单了，但它们可以匹配您的用例。
答案 1 :(得分：0)
根据您的要求，首先您需要一个非常有效的SolrCloud结构。它应该包括CPU和RAM方面的好机器。按solr size estimator估算您的要求。
我建议你使用一些 ETL （Extract Transform Load）工具进行Solr索引。它将从您的RDBMS中提取数据并将其索引到Solr。因为它将成为Solr索引的单独实例，所以它将减少您的应用程序负载。