我正在开发在线圣经搜索程序。圣经是一本相当大的书，以纯文本占用了近5MB的空间。我计划在该计划中实施API，并允许其他网站包含他们自己的圣经搜索窗口小部件和程序，而无需开发搜索查询或将自己的圣经存储在自己的服务器上。存储大量可搜索文本文件的最佳方式
考虑到这一点，我预计最终我会有一个适度的查询流程通过该程序。另外，对于那些不熟悉圣经的人，它有两种格式化文本的方法。它可以包含红色文本和斜体。我需要一种方式来存储圣经以及红色和斜体格式，但允许搜索查询忽略格式。
它还需要尽可能快速和高效（内存和CPU使用率）。只要查询可以忽略格式化，任何存储格式都将被考虑（MySQL，JSON或XML文本文件等）。文件大小和数量并不重要，因此将书籍或甚至章节分成单独的文件对我来说是很好的。
要记住的另一个重要的事情是，我想有一种搜索方法可以搜索多个经文。因此，寻找“，但有上帝的永生不送他的儿子”将返回约翰3：16,17。感谢所有想法！
有很多不同的开源文档搜索引擎，它们都是为您正在尝试做的。 Solr，Elastic Search，Xapian，Whoosh，Haystack（为Django制作）等。 S.O上还有其他的帖子。以及其他地方都会使用一个vs另一个的好处，但是您的要求很简单，它们中的任何一个都不会很好（如果项目起飞，只需很小的工作量即可轻松进行扩展，这总是很好理解）。所以看看他们的例子，看看哪一个对你来说最直观--Solr可以说是最受欢迎的，也是我一直使用的唯一一个，但Elastic Search使用相同流行的Lucene后端，显然更容易起来和跑步，所以我会从那里开始。
至于实际的实现，如果单个经文（或者只是经文编号）是你想要返回的东西，你会希望将每一节作为一个单独的“文档”编入索引。搜索引擎根据相关性处理结果的排名（通常使用tf/idf算法，以防您感兴趣）。
我处理斜体和红色文本的方式是在文本中包含某种标记（即将单个星号包裹为斜体，将双星号包裹为红色），然后告诉分析器忽略这些字符 - 尽管如此，在你最终选择的框架中可能会有一种更简单的方法，那就是用一粒盐。跨越多节经文需求的查询更加复杂，但答案可能涉及将每章作为一个文档而不是（或者除了？我不得不考虑更多）每个诗节。
请谨慎使用 - 如果您对搜索索引不熟悉，即使设计为即插即用的类似Elastic Search的设置可能仍需要一些时间和精力来设置，因此如果您绝对需要需要可以快速启动并运行，并且您已经熟悉MySQL，我认为它可以工作（它确实可以进行全文搜索）。但是这绝对不是工作的最佳工具，所以如果这是一个你投资的项目，那么稍后如果你投入一点工作去学习这些搜索框架，你会感谢你自己。正如其他人指出的那样，在处理文本的数量方面可能会有些过头，但在如何搜索那些看起来像是你想要的文本方面会非常灵活。例如，稍后添加其他要求将非常简单（例如，您可以让用户将搜索范围限制为红色文本中的唯一匹配项）。
我不知道圣经有格式。它是干什么用的？如果是用于诗句，我建议你将每一节经文存储在数据库中。在高度规范化的形式中，你得到了一张带有书本的桌子，一张带有章节的桌子和一张带有诗句的桌子。每节经文包括一个经文编号和一节经文。
现在，我认为章节没有标题，所以它们实际上只是一个数字。在这种情况下，将它们分开存放是非常愚蠢的，所以你只有你的书桌和一张经文，其中每个经文都有一个章节号码，一个经文编号和一个经文文本。那个文本我认为是纯文本，不是吗？
如果经文是纯文本，您可以通过将它存储在MySQL中并为其创建一个FULLTEXT索引来轻松地将其搜索到。这样，您可以非常有效地进行搜索，甚至可以使用通配符等。
如果这节经文是格式化的，你可以选择创建两列，一列用纯文本搜索，一列用格式化文本显示，但我怀疑你会需要这样做。
PS：5 MB的文本并不真实。如果您有专用程序，可以将其保存在内存中，并使用strpos或类似函数查找文本。你使用什么语言，数据库和平台？
我正在使用LAMP服务器。我使用PHP进行编程，MySQL将是最好的数据库。您存储纯文本版本和格式化版本的想法会很好。我从来没有想过这样做。我所说的“格式化”是基督在红色的字样和在詹姆斯国王版中的斜体字。 –
你可以真正快速地使用grep进行搜索。你打算使用哪个平台？ – galchen