mysql - elastic search + couchdb 或 sphinx + mysql .... 用于文档审查 SaaS

Question

我有:

作为“加载文件”提供的一组预处理办公文档(Word、Excel、PDF、电子邮件、Power Point 等)(每组约 2-4 TB)

“加载文件”包括:

1. 单页 pg tiffs(从办公文件打印.. 15 页的单词医生会有 15 次争吵)
2. 从 office 文档中提取的元数据显示在带分隔符的 .dat 文件中，其中包括全文。
3. .log 文件与 .tiff 和 .dat 相关联(.dat 和 .log 文件放在一起约占数据集大小的 7-10%)
4. 办公文件原件

通过浏览器的用户将:

1. 在 .dat 中找到的全文和元数据中进行各种关键字搜索
2. 查看 tiff 图像，偶尔查看原始 office 文档
3. 用一些用户定义的标签对每个文档进行分类，有时做笔记
4. 以多种方式对数据进行排序...例如发送日期、作者、主题等

尝试在以下两者之间做出决定:elastic search + couchdb 或 sphinx + mysql

我被告知搜索将是主要的工程问题，因此决定将其用作确定其他一切的基础。

考虑到 future 的发展，我想我会选择所有“云”。我输入了 Elasticsearch ，我读到它与 couchdb 很好地配对(除了宣传的与 ES 的紧密集成之外没有特别的原因)......以及 symfony2 + 学说(没有与这些结合，但读到它们与 ES 很好地配对)而不是 zend。

但后来有人评论说，数据看起来结构非常好，因此 sphinx/mysql 是一个更好的路径，因为 sphinx“开箱即用”按云节点拆分。

上下文:

我的主要目标是提高搜索速度和性能以及提供 tiff 图像。可扩展性是次要问题，因为用户数量可能会增长到数万……也许是 10 万，但不是“网络规模”(数千万)。然而，其中一些用户每天 8 小时都在使用该应用程序。

问题:

对于这个特定的应用程序，您是否觉得 Elasticsearch + nosql 是矫枉过正，因为它需要比我真正需要的更多的时间/复杂性/资源来配置，而没有显着的性能优势？或者 sphinx mysql 最终会成为更大数据集/更多用户的瓶颈吗？

Answer 1

旨在作为评论而不是答案......(虽然太长了)

我真的不能对 couchdb 发表评论，但我想我会分享我对 MySQL/Sphinx 的看法。

首先，即使使用复杂的标准，搜索速度也非常快。索引的某些方面需要存储在 RAM 中。如果您拥有庞大的数据集，则需要为 Sphinx 分配足够的资源才能获得这种性能。

Sphinx 的一个潜在缺点是，根据我的经验，“开箱即用的 sphinx”只会在您的要求相当简单时发生。如果您想在索引之前预处理文档(即在文档上运行正则表达式，替代论坛 bbcode 等)，那么它会变得更加复杂(在我的例子中，我必须使用 XMLPIPE2 进行索引，而不是 Sphinx 直接与 mysql 对话)。

Sphinx 的另一个潜在问题是，虽然有实时索引，但它们还不是 (IMO) 成熟的功能，并且也有一些限制。因此，您可能需要定期重新索引数据集(或者更可能的是，索引新的位，然后将它们合并到主索引中——称为 main + delta)。这不一定是个问题，但它又是一个动人的部分。

“我的主要目标是搜索的速度和性能”——Sphinx 在这里不会让您失望，而且它的扩展性很好。