Является ли NoSQL лучшим вариантом для решения этой конкретной проблемы с базой данных? - PullRequest
Новая
       6

Является ли NoSQL лучшим вариантом для решения этой конкретной проблемы с базой данных?

2 голосов
/ 04 января 2011

У меня проблема, и я думаю, что решение NoSQL - это ответ, но я не уверен.Кроме того, я не уверен, какой тип NoSQL DB (объект, документ, график, ключ и т. Д.) Лучше всего подходит для решения этой проблемы.

Проблема:

У меня есть две коллекции.CollectionA содержит 2K + строки (доменные имена).CollectionB намного больше и выглядит (псевдо) следующим образом: 

{
    "To" : "address1@address1.com,address2@address2.com,there_could_be_100@more_address.com",  
    "Bcc" : "address1@address1.com,address2@address2.com,there_could_be_100@more_address.com",  
 "From" : "address1@address1.com,address2@address2.com,there_could_be_100@more_address.com", 
 "Subject" : "Email Subject", 
 "Unknown" : "NumberOfFields", 
 "N" : "PlusOneExtraFields", 
}

Известные:

  1. В списке «Кому» может быть 100 человеки из строк.
  2. У меня нет хорошего способа взорвать поля «Кому, От», «Скрытая копия».
  3. Без способа взорвать поля «Кому, От, Скрытая копия», я вынужден искать строки.
  4. Есть несколько известных полей, но много неизвестных полей.
  5. Требования в настоящее время не требуют поиска по неизвестным полям.
  6. Механизм базы данных должен работать на рабочем столе Windows.

Текущее мышление:

Использование решения NoSQL и возможно динамическое ключевое слово C #?

Нечеткое

  1. Эта проблема легко решается с помощью базы данных документов?

  2. Является ли поиск / сравнение по структуре данных этого типа чем-то, что для Map / Reduce?

Ответы [ 4 ]

1 голос
/ 04 января 2011

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

@ chx предложение Сфинкса кажется правдоподобным, по крайней мере, в ускорении последнего. Но для этого маршрута есть скрытые издержки - вам нужно связывать, устанавливать, управлять, исправлять, обновлять и т. Д. Чужую службу вместе с вашим программным обеспечением.

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

Я бы начал с любой базовой файловой системы - с использованием объектов файловой системы для представления ваших денормализованных данных. Или, если представление и выполнение ваших запросов кажется слишком сложным, посмотрите на простые библиотеки встроенных таблиц, такие как SQLite или SQL Compact edition, прежде чем пытаться использовать более экзотические продукты, ориентированные на сервер, на рабочий стол.

Отличное сравнение SQLite и SQL Compact Edition здесь:

http://www.tech -archive.net / Архив / DotNet / microsoft.public.dotnet.framework.compactframework / 2005-12 / msg00019.html

SQLite также может создавать произвольные текстовые индексы, которые будут охватывать некоторые из ваших сценариев "неизвестного поля" в будущем.

Что касается карты-сокращения, то ее стратегия действительна для домена, к которому вы приближаетесь.

0 голосов
/ 04 января 2011

Нет, это не так. Это кандидат для полнотекстовой поисковой системы, которая не имеет ничего общего с "nosql", что бы это ни было.

Полнотекстовые поисковые системы часто используют SQL или какой-либо его вариант. Например, Сфинкс или Люцен. Вы также можете использовать Microsoft (но я не знаю, удовлетворит ли это ваши требования, вам нужно проверить).

0 голосов
/ 04 января 2011

Мне кажется, что это правильный кандидат на Apache lucene.net .

Вы можете создать документ lucene для указанной выше структуры, например, 

         Lucene.Net.Documents.Document doc = new Lucene.Net.Documents.Document();

         doc.Add( new Lucene.Net.Documents.Field(
             "To",
             ToData,
             Lucene.Net.Documents.Field.Store.YES,
             Lucene.Net.Documents.Field.Index.ANALYZED,
             Lucene.Net.Documents.Field.TermVector.WITH_POSITIONS_OFFSETS));


         doc.Add(new Lucene.Net.Documents.Field(
             "From",
             FromData,
             Lucene.Net.Documents.Field.Store.YES,
              Lucene.Net.Documents.Field.Index.ANALYZED,
             Lucene.Net.Documents.Field.TermVector.WITH_POSITIONS_OFFSETS));

         doc.Add(new Lucene.Net.Documents.Field(
            "BCC",
            BCCData,
            Lucene.Net.Documents.Field.Store.YES,
            Lucene.Net.Documents.Field.Index.ANALYZED,
             Lucene.Net.Documents.Field.TermVector.WITH_POSITIONS_OFFSETS));

    // Since you dont want Unknown field to be indexed, you can make it Index.NO.
        doc.Add(new Lucene.Net.Documents.Field(
            "Unknown",
            BCCData,
           Lucene.Net.Documents.Field.Store.YES,
             Lucene.Net.Documents.Field.Index.NO));

Но проблема с lucene в том, что вы не можете добавить новое поле или изменить существующую структуру поля позднее.Поэтому вы должны удалить документы и создать новые из scracth.

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

0 голосов
/ 04 января 2011

Хранить в XML и искать с помощью sphinx. Используйте xmlpipe2, чтобы пропустить sphinx через что-то вроде grep, чтобы пропустить в него только известные поля. Как только вам нужно будет искать больше, добавьте эти поля в свой фильтр, а также в схему и переиндексацию. Сфинкс может индексировать на таких скоростях, что не представляет реальной проблемы. Может быть распространен тоже.

Вы призываете к текстовому поиску, ну, это означает, что это solr или sphinx, а между двумя сфинксами это проще сделать на рабочем столе Windows.

...