эластичный поиск + couchdb ИЛИ sphinx + mysql .... для просмотра документов SaaS

Question

I ЕСТЬ:

Набор предварительно обработанных офисных документов (Word, Excel, PDF, электронные письма, Power Point и т. Д.), Представленных в виде «Загрузить файлы» (примерно 2-4 терабайта на комплект)

«ЗАГРУЗИТЬ ФАЙЛЫ» СОДЕРЖИТ:

1. Одиночные файлы pg (напечатанные из офисных документов ... документ из 15 страниц будет иметь 15 символов)
2. MetaДанные, извлеченные из офисных документов, представленных в файле .dat с разделителями, который включает в себя полный текст.
3. .log файл, который связывает файлы .tiff & .dat (вместе взятые файлы .dat & .log составляют около 7-10% от размера набора данных)
4. Оригинальные офисные документы

ПОЛЬЗОВАТЕЛИ VIA BROWSERS БУДУТ:

1. Выполнять поиск по ключевым словам в полном тексте &метаданные, найденные в .dat
2. Просмотр изображений в формате TIFF и иногда оригинального офисного документа
3. Классифицируйте каждый документ с помощью определенной пользователем метки и иногда делайте заметки
4. Сортируйте данныеразличными способами ... например, дата отправки, автор, тема и т. д.

ПОПЫТКА ДЛЯ РЕШЕНИЯ МЕЖДУ: упругий поиск + couchdb ИЛИ sphinx + mysql

Мне посоветовали, что поиск будет основной инженерной проблемой, поэтому решил использовать его в качестве основы дляопределяя все остальное.

Имея в виду будущий рост, я решил, что выберу все вещи "облаком".Я включил упругий поиск, который хорошо читал пары с помощью couchdb (без особых причин, кроме объявленной тесной интеграции с ES) ... вместе с доктриной symfony2 + (не женат на них, но читал, что они хорошо сочетаются с ES) вместо zend.

Но потом кто-то заметил, что данные кажутся очень хорошо структурированными, поэтому sphinx / mysql - это лучший путь со сфинксом "из коробки", разделенным по узлам для облака.

КОНТЕКСТ:

Моя главная цель - скорость и эффективность поиска и обработки изображений в формате TIFF.Масштабируемость является второстепенной проблемой, поскольку количество пользователей может вырасти до десятков тысяч ... возможно, до 100 тыс., Но не в масштабе сети (десятки миллионов).Однако некоторые из этих пользователей будут работать по 8 часов в день.

ВОПРОС:

Считаете ли вы, что для этого конкретного приложения упругий поиск + nosql - это излишне в том смысле, что для этого потребуется больше времени?/ сложность / ресурсы для настройки, чем то, что мне действительно нужно без существенного преимущества в производительности?Или sphinx mysql в конечном итоге станет узким местом с большими объемами данных / большим количеством пользователей?

Answer 1

Предназначен как комментарий, а не как ответ ... (хотя это было слишком долго)

Я не могу комментировать couchdb, но решил поделиться своими мыслями о MySQL / Sphinx.

Во-первых, поиск очень быстр, даже со сложными критериями. Некоторые аспекты индекса должны храниться в оперативной памяти. Если у вас огромный набор данных, вам нужно выделить достаточно ресурсов для Sphinx, чтобы получить такую ​​производительность.

Потенциальным недостатком Сфинкса является то, что по моему опыту «сфинкс из коробки» происходит только тогда, когда у вас достаточно простые требования. Если вы хотите предварительно обработать документы перед индексацией (то есть запустить regexp в документе, заменить bb-коды форума и т. Д.), То это станет намного сложнее (в моем случае я должен индексировать, используя XMLPIPE2, вместо того, чтобы Sphinx говорил напрямую с mysql).

Другая потенциальная проблема со Sphinx заключается в том, что, хотя существуют индексы в реальном времени, они еще не являются (IMO) зрелой функцией и также имеют некоторые ограничения. Следовательно, вам может понадобиться периодически переиндексировать набор данных (или, что более вероятно, проиндексировать новые биты, а затем объединить их с основным индексом - называемым main + delta). Это не обязательно проблема, но опять-таки еще одна движущаяся часть.

«Моя главная цель - скорость и эффективность поисков» - Sphinx вас здесь не разочарует, и будет очень хорошо масштабироваться.