寻找有关将数据从 SQL Server 加载到 Elasticsearch 或任何其他数据存储中的建议。目标是实时提供交易数据以用于报告。
除了 SSRS 之外，我们目前还使用第三方工具进行数据分析。数据传输是使用每日批处理作业完成的，因此存在 24 小时的数据延迟。
我们正在寻求构建一些能够更实时地提供数据的东西，类似于 SSRS，以便我们的客户进行报告。我们需要确保这不会对我们的 SQL Server 数据库产生影响。
我最初的想法是在周末进行数据的完整转储，并在工作日实时写入。
谢谢。
ElasticSearch的主要用例是在基于非结构化大型文本的数据之上提供搜索类型功能。例如，如果您每天将大量电子邮件提取到数据存储中，ElasticSearch 是一个很好的工具，可以根据您设置的规则解析这些电子邮件的各个部分，以启用搜索（以及某种程度上的查询）功能这些电子邮件。
如果您的数据已经在 SQL Server 中，听起来它已经结构化，因此在可报告性和可用性方面从 ElasticSearch 获得的收益并不多。相反，您可能会给数据工作流程带来额外的复杂性。
如果您已经在 SQL Server 中拥有结构化数据，并且直接从其生成报告时遇到问题，则应该考虑构建 数据仓库 来处理您的报告。 SQL Server 附带了许多开箱即用的功能，可帮助您为此目的复制数据。您可以研究实现此目的的三个主要功能是AlwaysOn 可用性组、复制或SSIS。
上面的每个选项（除了 SQL Server 的其他开箱即用功能之外）都有不同的优点和缺点。例如，AlwaysOn 可用性组 非常易于设置，并且能够在主服务器发生故障时自动进行故障转移，但它们会将整个数据库克隆到副本。 复制让您可以更精细地选择仅复制特定的表和视图，但如果您的主服务器出现故障，您将无法轻松进行故障转移。因此，您应该阅读所有三个选项并了解它们的差异。
此外，如果您在尝试从主数据库报告时遇到特定的性能问题，您可能需要首先深入研究这些问题的根本原因，然后再考虑复制数据作为报告的解决方案（尽管这是相当常见的）解决方案）。您可能会发现简单的架构更改（例如在正确的表上使用列存储索引）将极大地提高您的报告能力。
对于结构化数据和非结构化大文本数据，我已经使用上述所有三个主要数据同步功能实现了ElasticSearch和数据仓库的两条路径，并且体验了这两种方法的正确用例。我过去管理过的一个数据仓库有包含数十亿行的表（每个表有 TB 大），并且它在 AWS 中相当普通的硬件上报告性能很高（我们甚至没有使用 红移）。
您可以使用elasticsearch连接器从MSSQl或任何其他来源提取数据并定期摄取到弹性索引中。这是参考https://www.elastic.co/guide/en/enterprise-search/current/连接器-ms-sql.html