Как можно было бы использовать Lucene.NET, чтобы помочь реализовать поиск на сайте как Переполнение стека?

Я задал simlar вопрос на Переполнении стека Meta, но это имеет дело конкретно с тем, используется ли Lucene.NET на Переполнении стека.

Целью вопроса здесь является больше гипотетического, относительно того, какие подходы можно было бы сделать, если бы они должны были использовать Lucene.NET в качестве основания для поиска в сайте и других факторов в сайте как Переполнение стека [SO].

Согласно записи на блоге Переполнения стека, названном "проблемы SQL 2008 Полнотекстового поиска" был верный признак, что Lucene.NET рассматривали в какой-то момент, но кажется, что это - определенно не случай согласно комментарию Geoff Dalgas 19-го февраля 2010:

Lucene.NET не используется для Переполнения стека - мы используем Полнотекстовое индексирование SQL Server. Поиск является областью, где мы продолжаем делать незначительные тонкие настройки.

Таким образом, мой вопрос, как можно было бы использовать Lucene.NET в сайт, который имеет ту же семантику Переполнения стека?

Вот некоторый фон и о чем я делал/думал до сих пор (да, я реализовывал большую часть из этого, и поиск является последним аспектом, который я должен завершить):

Технологии:

• ASP.NET MVC
• SQL Server 2008
• .NET 3.5
• C# 3.0

И конечно, звезда шоу, Lucene.NET.

Намерение состоит в том, чтобы также переместиться в.NET/C# 4.0 ASAP. В то время как я не думаю, что это - переломный момент, это должно быть отмечено.

Перед вхождением в аспекты Lucene.NET важно указать на SQL Server 2 008 аспектов его, а также включенные модели.

Модели

Эта система имеет больше чем один основной тип модели по сравнению с Переполнением стека. Некоторые примеры этих моделей:

• Вопросы: Это вопросы, которые могут задать люди. Люди могут ответить на вопросы, точно так же, как на Переполнении стека.
• Примечания: Это односторонние проекции, поэтому как настроенные против вопроса, Вы делаете оператор о содержании. Люди не могут отправить ответы на это.
• События: Это - данные о событии в реальном времени. Это имеет информацию о местоположении, информацию о дате/времени.

Важная вещь отметить об этих моделях:

• У них всех есть Имя/Заголовок (текст) свойство, и свойство Body (HTML) (форматы не важны, поскольку содержание будет проанализировано соответственно для анализа).
• Каждый экземпляр модели имеет уникальный URL на сайте

Затем существуют вещи, которые обеспечивает Переполнение стека, какой IMO, декораторы к моделям. У этих декораторов может быть различная кардинальность, или быть непосредственным или one-many:

• Голоса: Включенный пользователь
• Ответы: Дополнительный, как пример, посмотрите случай Примечаний выше
• Favorited: модель перечислена как фаворит пользователя?
• Комментарии: (дополнительно)
• Ассоциации тега: Теги находятся в отдельной таблице, чтобы не копировать тег для каждой модели. Существует ссылка между моделью и таблицей ассоциаций тега, и затем от таблицы ассоциаций тега до таблицы тегов.

И там поддерживают счета, которые в себе являются непосредственными декораторами к моделям, которые адресуются им таким же образом (обычно образцовым идентификационным типом и образцовым идентификатором):

• Результаты голосования: Общие положительные, отрицательные голоса, интервал Счета Wilson (это важно, это собирается определить доверительный уровень на основе голосов за запись, по большей части, принять нижнюю границу интервала Wilson).

Ответы (ответы) являются моделями, которые имеют большинство декораторов, которых имеет большинство моделей, у них просто нет заголовка или URL, и имеет ли модель ответ, является дополнительным. Если ответы позволяются, это - конечно, связь "один ко многим".

SQL Server 2008

Таблицы в значительной степени следуют за расположением моделей выше, с отдельными таблицами для декораторов, а также некоторыми таблицами поддержки и представлениями, хранимыми процедурами, и т.д.

Нужно отметить, что решение не использовать полнотекстовый поиск базируется, прежде всего, на том, что это не нормализует очки как Lucene.NET. Я открыт для предложений о том, как использовать основанный на тексте поиск, но я должен буду выполнить поиски через типы многоуровневой модели, поэтому имейте в виду, что я испытываю необходимость для нормализации счета так или иначе.

Lucene.NET

Это - то, где большой вопросительный знак. Вот мои мысли до сих пор о функциональности Переполнения стека, а также как и что я уже сделал.

Индексация

Вопросы/Модели

Я полагаю, что каждая модель должна иметь собственный индекс, содержащий уникальный идентификатор для быстрого поиска его на основе экземпляра Термина того идентификатора (индексированный, не проанализированный).

В этой области я рассмотрел наличие, Lucene.NET анализирует каждый вопрос/модель и каждый ответ индивидуально. Таким образом, если бы был один вопрос и пять ответов, то вопрос и каждый из ответов были бы индексированы как одна единица отдельно.

Идея здесь состоит в том, что счет уместности, который возвраты Lucene.NET были бы легче сравнить между моделями, что проект по-разному (говорят, что-то без ответов).

Как пример, вопрос устанавливает предмет, и затем ответ уточняет предмет.

Для примечания, которое не имеет ответов, это занимается вопросом представления предмета и затем разработки на нем.

Я полагаю, что это поможет с созданием очков уместности, более относящихся друг к другу.

Теги

Первоначально, я думал, что они должны быть сохранены в отдельном индексе с несколькими полями, которые имеют идентификаторы к документам в соответствующем образцовом индексе. Или, если это является слишком большим, существует индекс только с тегами и другой индекс, который поддерживает отношения между индексом тегов и вопросами, к ним относятся. Этот путь при нажатии на тег (или используют структуру URL), легко видеть прогрессивным способом, что только необходимо "вложиться в", если Вы успешно выполняетесь:

• Если тег существует
• Который подвергает сомнению теги, связаны с
• Сами вопросы

Однако на практике выполнение запроса всех объектов на основе тегов (как нажатие на тег в Переполнении стека) чрезвычайно легко с SQL Server 2008. На основе модели выше, это просто требует запроса, такого как:

select
     m.Name, m.Body
from
    Models as m
        left outer join TagAssociations as ta on
            ta.ModelTypeId =  and
            ta.ModelId = m.Id
        left outer join Tags as t on t.Id = ta.TagId
where
    t.Name = 

И так как определенные свойства совместно используются через все модели, достаточно легко сделать a UNION между различными образцовыми типами/таблицами и производят непротиворечивое множество результатов.

Это было бы analagous к a TermQuery в Lucene.NET (я ссылаюсь на документацию Java, так как это всесторонне, и Lucene.NET, предназначен, чтобы быть линию за линией перевод Lucene, таким образом, вся документация является тем же).

Проблемой, которая придумывает использование Lucene.NET здесь, является проблема порядка сортировки. Счет уместности к TermQuery когда дело доходит до тегов не важен. Это или 1 или 0 (это или имеет его, или это не делает).

На данном этапе счет уверенности (интервал счета Wilson) играет роль для упорядочивания результатов.

Этот счет мог быть сохранен в Lucene.NET, но для сортировки результатов на этом поле, он будет полагаться на значения, сохраненные в полевом кэше, который является чем-то я действительно, действительно хотят избежать. Для большого количества документов полевой кэш может стать очень большим (счет Wilson является двойным, и Вам было бы нужно одно двойное для каждого документа, который может быть одним большим массивом).

Учитывая, что я могу измениться, SQL-оператор для упорядочивания на основе Wilson выигрывают интервал как это:

select
     m.Name, m.Body
from
    Models as m
        left outer join TagAssociations as ta on
            ta.ModelTypeId =  and
            ta.ModelId = m.Id
        left outer join Tags as t on t.Id = ta.TagId
        left outer join VoteTallyStatistics as s on
            s.ModelTypeId = ta.ModelTypeId and
            s.ModelId = ta.ModelId
where
    t.Name = 
order by
    --- Use Id to break ties.
    s.WilsonIntervalLowerBound desc, m.Id

Это походит на легкий выбор использовать, это для обработки части функциональности Переполнения стека "получает все объекты, отмеченные с <тегом>".

Ответы

Первоначально, я думал, что это находится в отдельном собственном индексе с ключом назад в индекс Вопросов.

Я думаю, что должна быть комбинация каждой модели и каждого ответа (если существует один) так, чтобы очки уместности через различные модели были более "равными" друг по сравнению с другом.

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

Или, есть ли способ сохранить, говорят, модели и ответы как отдельные документы в Lucene.NET и затем берут обоих и смочь получить счет уместности к запросу, рассматривающему оба документа как один? Если так, затем это было бы идеально.

Существует, конечно, вопрос того, какие поля были бы сохранены, индексированы, проанализированы (все операции могут быть отдельными операциями, или смешивать-и-соответствовать)? Сколько можно было бы индексировать?

Что относительно того, чтобы использовать специальные стеммеры/носильщиков для орфографических ошибок (использующий Метафон), а также синонимы (существует терминология в сообществе, которое я обслужу, который имеет свой собственный сленг/терминологию для определенных вещей, который имеет несколько представлений)?

Повышение

Это связано с индексацией, конечно, но я думаю, что она заслуживает свой собственный раздел.

Вы повышаете поля и/или документы? Если так, как Вы повышаете их? Действительно ли повышение является постоянным для определенных полей? Или повторно вычисляется для полей, где данные голоса/представления/фаворита/внешнего применимы.

Например, в документе, заголовок получает повышение по телу? Если так, какие факторы повышения Вы думаете работа хорошо? Что относительно тегов?

Взгляды здесь совпадают с ним, вроде Переполнения стека. Условия в документе имеют уместность, но если документ отмечен с термином, или это находится в заголовке, затем это должно быть повышено.

Кора Shashikant предлагает структуру документа как это:

• Заголовок
• Вопрос
• Принятый Ответ (Или высоко проголосовавший ответ, если нет никакого принятого ответа),
• Все ответы объединены

И затем с помощью повышения, но не на основе необработанного значения голосования. Я полагаю, что мне покрыли это интервалом Счета Wilson.

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

Поиск теговых объектов

Я первоначально думал, что при запросах для тега (путем специфического нажатия один или использования структуры URL для поиска тегового содержания), это - простой TermQuery против индекса тега для тега, затем в индексе ассоциаций (при необходимости) затем обратно к вопросам, Lucene.NET обрабатывает это действительно быстро.

Однако данный указания выше оценки, как легкий это должно сделать это в SQL Server, я выбрал тот маршрут когда дело доходит до поиска теговых объектов.

Общий поиск

Таким образом, теперь наиболее нерешенный вопрос при выполнении общей фразы или поиска термина против содержания, какой и как Вы интегрируете другую информацию (такую как голоса) для определения результатов в надлежащем порядке? Например, при выполнении этого поиска на ASP.NET MVC на Переполнении стека, это счета для лучших пяти результатов (при использовании вкладки уместности):

    q votes answers accepted answer votes asp.net highlights mvc highlights
    ------- ------- --------------------- ------------------ --------------
         21      26                    51                  2              2
         58      23                    70                  2              5
         29      24                    40                  3              4
         37      15                    25                  1              2
         59      23                    47                  2              2

Обратите внимание, что выделения находятся только в заголовке и кратком обзоре на странице результатов и являются только незначительными индикаторами относительно того, что истинная частотность термина находится в документе, заголовке, теге, ответ (однако, они применяются, который является другим хорошим вопросом).

Как все это объединено?

На данном этапе я знаю, что Lucene.NET возвратит нормализованный счет уместности, и данные голосования дадут мне интервал счета Wilson, который я могу использовать для определения счета уверенности.

Как я должен посмотреть на объединение этих двух очков для указания на порядок сортировки набора результатов на основе уместности и уверенности?

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

Мои начальные мысли - то, если счет уместности является beween 0 и 1, и счет уверенности между 0 и 1, то я мог сделать что-то вроде этого:

1 / ((e ^ cs) * (e ^ rs))

Таким образом, каждый получает нормализованное значение, которое приближается 0 более соответствующее и уверенное, которое результат, и он может быть отсортирован на этом.

Основной вопрос с этим - то, что, если повышение выполняется на теге и или поле заголовка, затем счет уместности вне границ от 0 до 1 (верхний конец становится неограниченным затем, и я не знаю, как иметь дело с этим).

Кроме того, я полагаю, что должен буду скорректировать счет уверенности для составления результатов голосования, которые абсолютно отрицательны. Так как результаты голосования, которые являются абсолютно отрицательным результатом в интервале счета Wilson с нижней границей 0, что-то с-500 голосами, имеют тот же счет уверенности как что-то с-1 голосованием или 0 голосами.

К счастью, верхняя граница уменьшается с 1 до 0, когда отрицательные результаты голосования повышаются. Я мог изменить счет уверенности, чтобы быть диапазоном от-1 до 1, как так:

confidence score = votetally < 0 ? 
    -(1 - wilson score interval upper bound) :
    wilson score interval lower bound

Проблема с этим, это включающее 0 в уравнение оценит все объекты с нулевыми голосами ниже тех, которые имеют отрицательные результаты голосования.

С этой целью я думаю, будет ли счет уверенности используемым в возвратном уравнении как вышеупомянутый (я обеспокоен переполнением, очевидно), затем это должно быть переделано, чтобы всегда быть положительным. Один способ достигнуть этого:

confidence score = 0.5 + 
    (votetally < 0 ? 
        -(1 - wilson score interval upper bound) :
        wilson score interval lower bound) / 2

Мои другие проблемы - то, как на самом деле выполнить вычисление, данное Lucene.NET и SQL Server. Я не решаюсь помещать счет уверенности в индекс Lucene, потому что он требует использования полевого кэша, который может оказать огромное влияние на потребление памяти (как упомянуто прежде).

Идея, которую я имел, состояла в том, чтобы заставить счет уместности от Lucene.NET и затем использования табличного параметра передавать счет потоком к SQL Server (наряду с идентификаторами объектов для выбора), в которой точке я выполню вычисление со счетом уверенности и затем возвращу данные правильно ordred.

Как указано прежде, существует много других вопросов, которые я имею об этом, и ответы начали структурировать вещи и продолжат подробно останавливаться на вещах как на вопросе и развитых ответах.