我有一个使用Postgresql的Rails应用程序。
文本被添加到应用程序中（大小从几个单词到5,000个单词不等）。
首先自动解析文本，然后进行一些手动修订，以将文本中的每个单词/位置与特定信息（动词/名词/等，基本单词（运行==>运行），definition_id，语法标记相关联）
给定引理（基本词，例如“ run”）或词性（动词/名词）或语法标签，或definition_id（或组合词），我需要能够找到所有其他词数据库中包含相同信息的文本位置。
我无法进行全文搜索，因为例如，如果我单击“我离开了纳什维尔”上的“左”，我就不想出现“向左转”。交通灯。我只希望“ Leave”作为动词，以及其他形式的“ Leave”作为动词。
此外，我可能只希望带有特定definition_id的“左派”（例如，“左派”用作“政党”，而不用作“右派的对立”）。
简而言之，我正在寻找以下3条路线中哪条路线的建议（或者是否有我未考虑的第4条或第5条路线）。
我可以想到三个选项：
选项1：TextPosition
一个TextPosition表，用于存储每个单词的位置，并带有上述每个属性的列。
这将使搜索非常容易，但是会有很多记录（每个位置1个），但这也许不是问题吗？出于某些特定原因，存储如此数量的票证不是一个好主意吗？
选项2：文本对象上的JSON
Text对象上的JSON列，用于将所有单词位置存储在大量哈希或哈希哈希中。
这将添加零条记录，但是，a）建立查询以搜索具有某些信息的所有文本可能很困难，b）该查询可能会很慢，并且c）它可能比单独的表占用更多的存储空间（TextPosition）。
选项3：两个JSON列：一个在Text对象上，一个在每个字典对象上
每个文本对象中的JSON，如选项2所示，但仅用于呈现文本（不进行搜索），其中包含有关同一文本中每个位置的所有信息。
每个“字典对象”中的另一个JSON（定义，基本词，语法概念，语法标记），仅用于搜索（不呈现文本）。该列将跟踪所有文本中该特定对象的匹配项。这将是一个哈希数组，其中每个哈希将为{text_id：x，text_index：y}。
使用此选项，搜索会“更轻松”，但仍不理想：要找到包含某个属性的所有文本位置，我将必须执行以下操作：
如果是我要查找的属性的组合，则必须对每个属性执行这4个步骤，然后找到每个属性的匹配集之间的交集（最终只包含包含两者）。
此外，在更新职位时（例如，如果某人指示某个属性被错误地关联并且实际上应该是另一个属性，则我必须更新两个JSON。
而且，存储2个JSON列实际上会比TextPosition表带来任何明显的好处吗？与使用TextPosition表相比，它可能会占用更多的存储空间，这有什么好处？
总而言之，我正在寻找关于应遵循的这3条路线中哪些路线的建议。我希望答案是“选项1”，但如果是这样，我很想知道以后有大量条目时会出现哪些弊端/障碍。
谢谢，迈克尔·金
文本解析和搜索使我的大脑受伤。但是，无论何时我遇到您所谈论的事情的复杂性，ElasticSearch都是我的首选工具。您可以执行一些非常复杂的索引编制和搜索。
所以我的答案是4）ElasticSearch。