所以我的 API 甚至不查询数据库并返回文档数组
直接来自ES？
是的，当您对 Elasticsearch 进行查询时，您只会从 Elasticsearch 获得结果。另一种方法是，从 Elasticsearch 获取 id 并使用 id 从 MySQL 检索文档，但这可能会影响响应时间。
这被认为是好的做法吗？将整个表复制到
松紧带？那么表关系呢...如果我想过滤的话怎么办
嵌套表关系？...
这不是关于好的实践或坏的实践，而是关于您想要实现什么类型的功能和用例，以及基于该技术堆栈可以使用并且可以复制数据。有很多公司使用 Elasticsearch 作为secondary他们拥有重复数据的数据源只是因为他们的用例最适合 Elasticsearch 或其他 NoSQL 数据库。
Elasticsearch 是 NoSQL DB，它不维护数据之间的任何关系。因此，您需要在索引到 Elasticsearch 之前对数据进行标准化。你可以阅读this https://spoon-elastic.com/all-elastic-search-post/simple-elastic-usage/denormalize-index-elasticsearch/文章了解有关数据标准化以及为什么需要它的更多信息。
ElasticSearch提供Nested https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html and Join https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html父子关系的数据类型，但两者都有一些限制和性能影响。
以下是他们提到的内容join字段类型：
连接字段不应该像关系数据库中的连接那样使用。在
Elasticsearch 良好性能的关键是对数据进行非规范化
到文档中。每个连接字段，has_child or has_parent查询添加了一个
对您的查询性能产生重大影响。还可以触发全局
要构建的序数。
以下是他们提到的内容nested字段类型：
当摄取具有大量任意键集的键值对时，
您可以考虑将每个键值对建模为其自己的嵌套
文档与key and value字段。相反，请考虑使用flattened数据类型，它将整个对象映射为单个字段，并且
允许对其内容进行简单搜索。嵌套文档和
查询通常很昂贵，因此使用flattened数据类型为
这个用例是一个更好的选择。
我读过的大多数文章建议复制表记录（使用
Logstash 管道或其他方法）到弹性索引。
是的，您可以使用logstash或任何语言客户端喜欢java, python等，将数据从 DB 同步到 Elasticsearch。你可以检查this https://stackoverflow.com/a/37309866/5489276所以回答有关此的更多信息。
您的搜索要求
如果您继续使用 Elasticsearch 那么您可以使用N-Gram 分词器 https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-ngram-tokenizer.html or 正则表达式查询 https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-regexp-query.html并达到您的搜索要求。
