Articolo
03/03/2015

Il presente articolo è stato tradotto automaticamente.

.NET Framework

Sviluppo della ricerca aziendale per .NET

L'emersione del cloud computing negli ultimi anni è stata una manna per organizzazioni e utenti. Le organizzazioni possono sapere loro clienti come mai prima e loro target con comunicazioni personalizzate. Gli utenti possono ottenere ai loro dati da quasi ovunque, che lo rende molto più accessibile e utile. Datacenter enormi sono state costruite intorno al mondo per memorizzare tutti i dati. Ma Big Data conduce alle grandi sfide.

La ben nota citazione di John Naisbitt, "stiamo affogando nei dati ma di fame per informazioni," nel suo libro, "Megatrends: Dieci nuove direzioni trasformando la nostra vita"(Warner Books, 1982), descrive perfettamente la situazione attuale del mercato Big Data. Le aziende sono in grado di memorizzare petabyte di dati, ma riuscire a dare un senso che i dati e renderlo ricercabile, è molto più difficile, soprattutto perché la maggior parte dei data warehouse archiviano i dati in modo non strutturato (NoSQL) in più raccolte all'interno di archivi di dati Big particolare o anche in una forma distribuita tra magazzini diversi. Inoltre, ci sono una varietà di formati di dati, ad esempio documenti JSON, Microsoft Office file e così via. Ricerca attraverso una singola raccolta non strutturata in genere non è un problema, ma è molto più difficile di cercare tutti i dati non strutturati in più raccolte per trovare solo un piccolo sottoinsieme particolare di risultati quando l'utente non ha idea di dove potrebbe essere. Questo è dove la ricerca aziendale entra in gioco.

Enterprise Search

Ecco la sfida fondamentale della ricerca aziendale: Come una grande organizzazione con un sacco di fonti dati può fornire agli utenti interni ed esterni con la capacità di cercare tutte le fonti di dati azienda pubblica attraverso un'unica interfaccia? Tale interfaccia singola potrebbe essere un'API, un sito Web aziendale o anche una semplice casella di testo con funzionalità di completamento automatico implementato sotto il cofano. Non importa quale interfaccia sceglie una società, deve fornire la capacità di ricerca attraverso il suo universo intero dati, che potrebbe includere i database strutturati e non strutturati, documenti intranet in formati diversi, altre API e altri tipi di origini dati.

Perché la ricerca attraverso più DataSet è abbastanza complessa, ci sono solo alcune soluzioni di ricerca aziendale riconosciuto — e la barra è alta. Una soluzione di ricerca aziendale deve includere le seguenti caratteristiche:

Consapevolezza del contenuto: Sapere dove particolari tipi di dati possono essere trovati.
Indicizzazione in tempo reale: Mantenere tutti i dati indicizzati.
Elaborazione dei contenuti: Le diverse origini di dati accessibili.

Una delle più popolari soluzioni enterprise search è l'open source Elasticsearch (elasticsearch.org). Questo Java-based server incorporato di Apache Lucene (lucene.apache.org) fornisce scalabile, testo completo della ricerca su fonti di dati multiple, con supporto JSON interfaccia Web del resto, come pure un'elevata disponibilità, gestione dei conflitti e analitica in tempo reale. Visitare bit.ly/1vzoUrR per vedere la sua piena funzionalità impostata.

Da un alto livello, il modo che ElasticSearch memorizza i dati è molto semplice. L'elemento più alto della struttura all'interno di un server è denominato un indice, e indici multipli possono esistere nello stesso archivio dati. L'indice stesso è solo un contenitore per documenti (uno o molti), e ogni documento è una raccolta di uno o più campi (con nessuna strutture definite). Ogni indice può contenere dati aggregati in unità chiamate tipi che rappresentano i gruppi logici dei dati all'interno di un determinato indice.

Potrebbe essere utile pensare Elasticsearch come simile a un tavolo dal mondo dei database relazionali. La stessa correlazione esiste tra le righe di una tabella e le colonne e un indice documenti e campi, dove un documento corrisponde a una riga e un campo a una colonna. Tuttavia, con Elasticsearch, non c'è alcuno schema di database o la struttura di dati fissi.

Come ho notato, gli sviluppatori possono comunicare con il server Elasticsearch tramite un'interfaccia Web di resto. Questo significa che si può eseguire una query indici, tipi, dati o altre informazioni di sistema solo con l'invio di richieste Web del resto da un browser o qualsiasi altro tipo di client Web. Ecco alcuni esempi di richieste GET:

Query per tutti gli indici:
http://localhost:9200/_cat/indici /? v
Query per i metadati dell'indice:
http://localhost:9200/clienti/_stats
Query per tutti i dati di indice:
http://localhost:9200/client/_search? q = *: *
Ricerca per un valore di campo specifico all'interno dell'indice:
http://localhost:9200/client/_search? q = valore del campo:
Ottenere tutti i dati all'interno del tipo di mappatura di indice:
http://localhost:9200/clienti/ordini/_search? q = *: *

Creazione di una ricerca

Per illustrare come creare un semplice, soluzione multi-source, vado a utilizzare Elasticsearch 1.3.4 con JSON documenti, documenti PDF e un database SQL Server . Per iniziare, mi descrivono brevemente Elasticsearch installazione e quindi dimostrare come plug-in ogni origine dati per rendere i dati ricercabili. Per mantenere le cose semplici, presento un esempio di vicino-a-vita reale che utilizza fonti dati ben noti della società Contoso.

Io uso un database SQL Server 2014 con più tabelle in esso, anche se sarò solo con uno, dbo.Ordini. Come la tabella suggerisce il nome, memorizza record circa gli ordini del cliente dell'azienda — un enorme numero di record, ma facile da gestire:

CREATE TABLE [dbo].[Orders]
(
  [Id] [int] IDENTITY(1,1) NOT NULL primary key,
  [Date] [datetime] NOT NULL,
  [ProductName] [nvarchar](100) NOT NULL,
  [Amount] [int] NOT NULL,
  [UnitPrice] [money] NOT NULL
);

Hanno anche una rete di condividere con più documenti aziendali organizzati in una gerarchia di cartelle. I documenti sono legati a campagne di marketing di prodotto diverse società organizzate in passato e è memorizzata in diversi formati, quali PDF e Microsoft Office Word. La dimensione media del documento è circa 1MB.

Infine, ho un'azienda interna API che espone le informazioni di cliente dell'azienda in formato JSON; perché so che la struttura della risposta, sono in grado di deserializzarla facilmente a un oggetto del cliente tipo. Il mio obiettivo è di rendere tutte le origini dati ricercabili tramite il motore di Elasticsearch. Inoltre, voglio creare un servizio Web basato su Web API 2 che, sotto il cofano, eseguirà una query impresa attraverso tutti gli indici di una singola chiamata al server Elasticsearch. (Maggiori informazioni su Web API 2 a bit.ly/1ae6uya.) Il servizio Web restituirà i risultati come un elenco di suggerimenti con potenziali suggerimenti all'utente finale; tale elenco può essere consumato dopo un completamento automatico di controllo incorporato nell'applicazione MVC ASP.NET , o qualsiasi altro tipo di sito Web.

Impostazione di

La prima cosa che devi fare è installare il server di Elasticsearch. Per Windows, è possibile farlo automaticamente o manualmente, con lo stesso risultato — un servizio di Windows in esecuzione che ospita il server di Elasticsearch. L'installazione automatica è molto semplice e veloce; tutto quello che dovete fare è scaricare ed eseguire il programma di installazione MSI Elasticsearch (bit.ly/12RkHDz). Purtroppo, non non c'è nessun modo per scegliere una versione di Java o, molto più importante, una versione di Elasticsearch. Il processo di installazione manuale, al contrario, richiede un piccolo sforzo in più, ma permette molto più controllo sopra i componenti quindi è più adatto in questo caso.

Impostare Elasticsearch come un servizio Windows manualmente richiede i seguenti passaggi:

Scaricare e installare la più recente di Java SE Runtime Environment (bit.ly/1m1oKlp).
Aggiungere la variabile di ambiente JAVA_HOME di chiamata. Suo valore sarà il percorso della cartella che hai installato Java in (per esempio, C:\Program Files\Java\jre7), come indicato nel Figura 1.
Scarica il file Elasticsearch (bit.ly/1upadla) e decomprimerlo.
Spostare sorgenti decompressi in Program Files | ElasticSearch (opzionale).
Eseguire il prompt dei comandi come amministratore ed eseguire service.bat con il parametro di installazione:
C:\Program Files\Elasticsearch\elasticsearch-1.3.4\bin>service.bat installare

Figura 1 la variabile di ambiente Java_Home

Questo è tutto quello che serve per ottenere il servizio di Windows up e funzionante, con Elasticsearch server accessibile su localhost, sulla porta 9200. Ora posso fare una richiesta Web all'URL http://localhost:9200 / tramite qualsiasi Web browser e mi arriva una risposta che assomiglia a questo:

{
  "status" : 200,
  "name" : "Washout",
  "version" : {
    "number" : "1.3.4",
    "build_hash" : "a70f3ccb52200f8f2c87e9c370c6597448eb3e45",
    "build_timestamp" : "2014-09-30T09:07:17Z",
    "build_snapshot" : false,
    "lucene_version" : "4.9"
  },
  "tagline" : "You Know, for Search"
}

Ora la mia istanza locale di Elasticsearch è pronto ad andare; Tuttavia, la versione grezza non mi dà la possibilità di connettersi al SQL Server o eseguire una ricerca full-text attraverso i file di dati. Per rendere disponibili queste funzionalità, devo installare anche numerosi plug-in.

Estensione Elasticsearch

Come accennato, la versione grezza di Elasticsearch non ti lascia indice di un'origine dati esterna come SQL Server, Office o anche un PDF. Per rendere ricercabili tutte queste fonti di dati ho bisogno di installare alcuni plug-in, che è abbastanza facile.

Il mio primo obiettivo è quello di fornire supporto di ricerca full-text per gli allegati. Di attaccamento, cioe ' un base64 -codificato rappresentazione del file di origine che è stata caricata su un archivio di dati Elasticsearch come documento JSON. (Vedere bit.ly/12RGmvg per informazioni sul tipo di allegato.) Il plug-in ho bisogno per questo scopo è il tipo di allegati Mapper per Elasticsearch versione 2.3.2, disponibile presso bit.ly/1Alj8sy. Questa è l'estensione di Elasticsearch che consente una ricerca full-text per i documenti, e si basa sul progetto Apache Tika (tika.apache.org), che rileva ed estrae i metadati e testo di contenuto da vari tipi di documenti e fornisce il supporto per i formati di file elencati presso bit.ly/1qEyVmr.

Come con la maggior parte dei plug-in per Elasticsearch, questa installazione è estremamente semplice e tutto quello dovete fare è eseguire il prompt dei comandi come amministratore ed eseguire il seguente comando:

bin>plugin --install elasticsearch/elasticsearch-mapper-attachments/2.3.2

Dopo il download e l'estrazione del plug-in, è necessario riavviare il servizio Elasticsearch Windows.

Quando questo è fatto, ho bisogno di configurare il supporto di SQL Server . Naturalmente, c'è anche un plug-in per questo. Si chiama fiume JDBC (bit.ly/12CK8Zu) e consente il recupero di dati da una fonte di JDBC, come SQL Server, per l'indicizzazione in Elasticsearch. Il plug-in viene facilmente installato e configurato, anche se il processo di installazione ha tre fasi che devono essere completati.

In primo luogo, installare Microsoft JDBC Driver 4.0, un Java-base per SQL Server che può essere scaricato da bit.ly/1maiM2j. La cosa importante da ricordare è che ho bisogno di estrarre il contenuto del file scaricato nella cartella denominata Microsoft JDBC Driver 4.0 per SQL Server (che deve essere creata se non esiste), direttamente sotto la cartella programmi, quindi il tracciato risultante assomiglia: C:\Program Files\Microsoft Driver JDBC 4.0 per SQL Server.
Quindi, installare il plug-in utilizzando il seguente comando:
bin> plugin-- installare
JDBC - url "http://xbib.org/repository/org/xbib/elasticsearch/plugin/elasticsearch-river-jdbc/1.3.4.4/elasticsearch-river-jdbc-1.3.4.4-plugin.zip"
Infine, copiare sqljdbc4. jar file estratto nel primo passaggio (C:\Program Files\Microsoft JDBC DRIVER 4.0 per SQL Server\sqljdbc_4.0\enu\SQLJDBC4.jar) nella cartella lib nella directory Elasticsearch (C:\Program Files\Elasticsearch\lib). Quando ho finito, ho bisogno di ricordare di riavviare il servizio Windows.

Ora tutti i plug-in richiesto installati. Tuttavia, per verificare gli impianti finiti correttamente, è necessario inviare il seguente comando come una richiesta HTTP GET:

http://localhost:9200/_nodes/_all/plugins

Nella risposta, mi aspetto di vedere sia installato il plug-in elencati, come mostrato Figura 2.

Figura 2 il Plug-in installati

Configurare il SQL Server

Per utilizzare JDBC fiume con SQL Server, l'istanza del SQL Server deve essere accessibile tramite TCP/IP, che, per impostazione predefinita, è disattivato. Tuttavia, abilitandola è semplice e tutto quello dovete fare è aprire il SQL Server Configuration Manager e, sotto la configurazione di rete del SQL Server , per l'istanza del SQL Server voglio collegare per, cambiare il valore dello stato di Enable per protocollo TCP/IP, come mostrato Figura 3. Dopo aver fatto questo, dovrei essere in grado di accedere al mio SQL Server istanza tramite Management Studio utilizzando localhost 1433 nel nome del Server (porta 1433 è la porta predefinita per l'accesso al SQL Server via TCP/IP).

Figura 3 Abilitazione TCP/IP per l'istanza del SQL Server

Rendere ricercabili fonti

Tutti richiesto plug-in sono stati installati, così ora ha tempo per caricare i dati. Come accennato in precedenza, ho tre origini di dati diverse (JSON documenti, file e una tabella di ordine da un database SQL Server ) che desidero sono indicizzati su Elasticsearch. Io posso indicizzare tali origini dati in diversi modi, ma voglio dimostrare quanto sia facile è utilizzando un.Applicazione basata su rete che ho implementato. Quindi, come una pre-condizione per l'indicizzazione, ho bisogno di installare una libreria esterna chiamata nido (bit.ly/1vZjtCf) per il mio progetto, che non è altro che un wrapper gestito per un interfaccia Elasticsearch Web. Perché questa libreria è disponibile su NuGet, rendendola parte del mio progetto è semplice come un singolo comando in esecuzione nella Console di Gestione pacchetti :

PM> Install-Package NEST

Ora, con la libreria nido disponibile nella mia soluzione, posso creare un nuovo progetto libreria di classi denominato ElasticSearchRepository. Ho usato questo nome perché ho deciso di tenere separato dal resto della soluzione di tutte le chiamate di funzione dalla classe ElasticClient (che fa parte della libreria di nido). In tal modo, il progetto diventa simile al modello di progettazione di repository ampiamente applicato nel Entity Framework-basato su applicazioni, quindi dovrebbe essere facile da capire. Inoltre, in questo progetto ho solo tre classi: la classe BaseRepository, che inizializza ed espone le classi ereditate e l'istanza della ElasticClient, e altre due classi di repository:

IndexRepository — una classe di lettura/scrittura utilizzerò per manipolare gli indici, impostare i mapping e caricare documenti.
DiscoveryRepository — una classe sola lettura utilizzerò durante le operazioni di ricerca basata su API.

Figura 4 Mostra la struttura della classe BaseRepository con una proprietà protetta di tipo ElasticClient. Questo tipo, fornito come parte della libreria nido, centralizza la comunicazione tra l'applicazione client e server Elasticsearch. Per creare un'istanza di essa, posso passare un URL per il server di Elasticsearch, che passare come parametro del costruttore di classe opzionale. Se il parametro è null, verrà utilizzato il valore predefinito di http://localhost:9200.

Figura 4 la classe BaseRepository

namespace ElasticSearchRepository
{
  using System;
  using Nest;
  public class BaseRepository
  {
    protected ElasticClient client;
    public BaseRepository(Uri elastiSearchServerUrl = null)
    {
      this.client = elastiSearchServerUrl != null ?
        new ElasticClient(new ConnectionSettings(elastiSearchServerUrl)) :
        : new ElasticClient();
    }
  }
}

Con il client è pronto, prima potrai indicizzare i dati del cliente; Questo è lo scenario più semplice perché nessun plug-in addizionali sono necessari:

public class Client
{
  public int Id { get; set; }
  public string Name { get; set; }
  public string Surname { get; set; }
  public string Email { get; set; }
}

Per questo tipo di dati di indice, io chiamo l'istanza del mio cliente Elasticsearch, così come l'indice<T> funzione, dove T è il tipo della mia classe Client, che rappresenta serializzata i dati restituiti dall'API. Questa funzione generica accetta tre parametri: l'istanza della classe oggetto T, un nome di indice di destinazione e un nome di mappatura all'interno dell'indice:

public bool IndexData<T>(T data, string indexName =
  null, string mappingType = null)
  where T : class, new()
  {
    if (client == null)
    {
      throw new ArgumentNullException("data");
    }
    var result = this.client.Index<T>(data,
      c => c.Index(indexName).Type(mappingType));
    return result.IsValid;
  }

Gli ultimi due parametri sono facoltativi perché nido verrà applicata la logica predefinita per la creazione di un nome di indice di destinazione sulla base del tipo generico.

Ora voglio indicizzare i documenti di marketing, che sono collegati con i prodotti dell'azienda. Come ho questi file archiviati in una condivisione di rete, io posso avvolgere informazioni su ciascun documento particolare in una semplice classe di MarketingDocument. Vale la pena notare qui che se voglio un documento per essere indicizzati in Elasticsearch, ho bisogno di caricarlo come una stringa con codifica Base64:

public class MarketingDocument
{
  public int Id { get; set; }
  public string Title { get; set; }
  public string ProductName { get; set; }
  // Base64-encoded file content.
  public string Document { get; set; }
}

La classe è pronta, così posso usare il ElasticClient per contrassegnare un campo particolare nella mia classe MarketingDocument come allegato. Io posso raggiungere questo obiettivo attraverso la creazione di un nuovo indice denominato "prodotti" e l'aggiunta di un nuovo mapping di marketing (per semplicità, il nome della classe sarà il nome di mappatura):

private void CreateMarketingIndex()
  {
    client.CreateIndex("products", c =>
      c.AddMapping<Marketing>
      (m => m.Properties(ps =>ps.Attachment(a =>
            a.Name(o =>o.Document).TitleField(t =>
            t.Name(x => x.Name)
            TermVector(TermVectorOption.WithPositionsOffsets)
        )))));
  }

Ora che ho il tipo .NET e il mapping per i dati di marketing, così come la definizione per un allegato, posso iniziare il mio file di indicizzazione allo stesso modo che indicizzati i dati del cliente:

var documents = GetMarketingDocumentsMock();
documents.ForEach((document) =>
{
  indexRepository.IndexData<MarketingDocument>(document, "marketing");
});

Il passo finale è l'installazione JDBC fiume su Elasticsearch. Purtroppo, il nido non supporta JDBC fiume ancora. In teoria, posso creare una mappatura JDBC fiume utilizzando una funzione Raw per inviare una richiesta con JSON raw, ma non voglio overcomplicate cose. Quindi, per completare il processo di creazione di mapping, vado a specificare i seguenti parametri:

Una stringa di connessione al database del SQL Server
Una query SQL che verrà utilizzata per eseguire query per dati
Programma di aggiornamento
Nome di indice di destinazione e il tipo (opzionale)

(Troverete un elenco completo dei parametri configurabili al bit.ly/12CK8Zu.)

Per creare un nuovo mapping di fiume di JDBC, è necessario inviare una richiesta PUT con un corpo di richiesta specificato in esso al seguente URL:

http://localhost:9200/_river/{river_name}/_meta

Nell'esempio in Figura 5, ho messo un corpo della richiesta per creare un nuovo mapping di JDBC River, che si connette al database Contoso ospitato nell'istanza locale del SQL Server , che è accessibile sulla porta 1433 via TCP/IP.

Figura 5 HTTP metti richiesta per creare un nuovo Mapping di fiume JDBC

PUT http://localhost:9200/_river/orders_river/_meta
{
"type":"jdbc",
"jdbc":
  {
  "driver": "com.microsoft.sqlserver.jdbc.SQLServerDriver",
  "url":"jdbc:sqlserver://127.0.0.1:1433;databaseName=Contoso",
  "user":"elastic",
  "password":"asd",
  "sql":"SELECT *  FROM dbo.Orders",
  "index" : "clients",
  "type" : "orders",
  "schedule": "0/30 0-59 0-23 ? * *"
  }
}

Utilizza l'account di accesso "elastica" e la password "asd" per autenticare l'utente ed eseguire il seguente comando SQL:

SELECT * FROM dbo.Orders

Ogni riga di dati restituiti dalla query SQL verrà indicizzato sotto l'indice di clienti negli ordini tipo di mappatura e l'indicizzazione si svolgerà ogni 30 secondi (vedere rappresentato nella notazione Cron, bit.ly/1hCcmnN per ulteriori informazioni).

Al termine di questo processo, si dovrebbe vedere le informazioni di file (/logs/ elasticsearch.log) registro Elasticsearch analogo al seguente:

[2014-10-2418:39:52,190][INFO][river.jdbc.RiverMetrics]
pipeline org.xbib.elasticsearch.plugin.jdbc.RiverPipeline@70f0a80d
complete: river jdbc/orders_river metrics: 34553 rows, 6.229481683638776 mean, 
  (0.0 0.0 0.0), ingest metrics: elapsed 2 seconds, 
  364432.0 bytes bytes, 1438.0 bytes avg, 0.1 MB/s

Se c'è qualcosa di sbagliato con la configurazione di fiume, il messaggio di errore sarà anche nel log.

I dati di ricerca

Una volta che tutti i dati è stato indicizzato nel motore Elasticsearch, posso iniziare l'esecuzione di query. Naturalmente, allo stesso tempo posso inviare semplici richieste al server Elasticsearch per query uno o più indici e tipi di mappatura, ma voglio costruire qualcosa di più utile e più vicini a uno scenario di vita reale. Così ho intenzione di dividere il mio progetto in tre diverse componenti. La prima componente, che già presentato, è Elasticsearch, che è disponibile via http://localhost:9200 /. La seconda componente è un'API che ho intenzione di costruire utilizzando la tecnologia Web API 2. L'ultimo componente è un'applicazione console che utilizzerò per impostare il mio indici su Elasticsearch, così come per alimentarlo con dati.

Per creare il mio nuovo progetto Web API 2, prima ho bisogno di creare un progetto di applicazione Web ASP.NET vuoto e quindi, dalla Console Gestione pacchetti , eseguire che il seguente installare il comando:

Install-Package Microsoft.AspNet.WebApi

Dopo aver creato il progetto, il passo successivo consiste nell'aggiungere un nuovo controller, che utilizzerò per elaborare query richieste dal client e passarli a Elasticsearch. L'aggiunta di un nuovo controller denominato DiscoveryController coinvolge niente di più che aggiungendo un nuovo elemento, una classe di istanza di Web API ApiController (v. 2.1). E ho bisogno di implementare una funzione di ricerca, che verrà esposta tramite l'URL: http://website/API/Discovery/search?searchterm=user_input:

[RoutePrefix("api/discovery")]
public class DiscoveryController : ApiController
{
  [HttpGet]
  [ActionName("search")]
  public IHttpActionResult Search(string searchTerm)
  {
    var discoveryRepository = new DiscoveryRepository();
    var result = discoveryRepository.Search(searchTerm);
    return this.Ok(result);
  }
}

Se il motore Web API 2 non è possibile serializzare una risposta a causa di un ciclo autoreferenziale, dovrete aggiungere la seguente nel file WebApiConfig.cs, che si trova nella cartella AppStart:

GlobalConfiguration.Configuration
.Formatters
.JsonFormatter
.SerializerSettings
.ReferenceLoopHandling =
      ReferenceLoopHandling.Ignore;

Come Figura 6 illustrato, nel corpo del controller che ho creato, creata un'istanza di una classe di tipo DiscoveryRepository, che è solo un wrapper per il tipo di ElasticClient dalla libreria nido. All'interno di questo repository non generico, sola lettura ho implementato due tipi di funzioni di ricerca e restituiscono entrambi li un tipo dinamico. Questa parte è importante perché così facendo in entrambi i corpi funzione, sto non limitare la mia query solo per un indice; invece, sto interrogare tutti gli indici e tutti i tipi allo stesso tempo. Questo significa che i miei risultati avrà una struttura diversa (saranno di diversi tipi). L'unica differenza tra le funzioni è il metodo di query. Nella prima funzione mi basta usare un metodo QueryString (bit.ly/1mQEEg7), che è una ricerca di corrispondenza esatta e nel secondo, un metodo Fuzzy (bit.ly/1uCk7Ba), che esegue una ricerca fuzzy attraverso indici.

Figura 6 implementazione di due tipi di ricerca

namespace ElasticSearchRepository
{
  using System;
  using System.Collections.Generic;
  using System.Linq;
  public class DiscoveryRepository : BaseRepository
  {
    public DiscoveryRepository(Uri elastiSearchServerUrl = null)
      : base(elastiSearchServerUrl)
    {
    }
    ///<summary>  
    public List<Tuple<string, string>> SearchAll(string queryTerm)
    {
      var queryResult=this.client.Search<dynamic>(d =>
        d.AllIndices()
        .AllTypes()
        .QueryString(queryTerm));
      return queryResult
        .Hits
        .Select(c => new Tuple<string, string>(
          c.Indexc.Source.Name.Value))
        .Distinct()
        .ToList();
     }
     ///<summary>  
     public dynamic FuzzySearch(string queryTerm)
     {
       return this.client.Search<dynamic>(d =>
         d.AllIndices()
         .AllTypes()
         .Query(q => q.Fuzzy(f =>
           f.Value(queryTerm))));
     }
  }
}

Ora quando mia API è pronto, posso eseguire e iniziare a testarlo solo inviando richieste GET a http://website:port/api / / ricerca di individuazione? searchTerm = user_input e passare l'input utente come valore del parametro di query searchTerm. Pertanto, Figura 7 Mostra i risultati che le mie API genera per il termine di ricerca "mischia". Come ho evidenziato nello screenshot, una funzione di ricerca eseguita una query su tutti gli indici in archivi di dati e restituito hits da indici multipli allo stesso tempo.

Figura 7 API risultati di ricerca per il termine "mischia"

Implementando il livello API ho creato la possibilità di implementare più client (come un sito Web o applicazione mobile), che sarà in grado di consumarlo. Questo fornisce la capacità di dare funzionalità di ricerca enterprise agli utenti finali. Potete trovare un esempio di implementazione del controllo di completamento automatico per un cliente di Web basata su MVC 4 ASP.NET sul mio blog a bit.ly/1yThHiZ.

Il confezionamento

Dati Big ha portato molto per il mercato della tecnologia, in termini di sfide e opportunità. Una delle sfide, che è anche potenzialmente una grande opportunità, è la possibilità di implementare la ricerca veloce attraverso petabyte di dati senza dover conoscere la posizione esatta dei dati dell'universo di dati. In questo articolo descritto come implementare la ricerca aziendale e ha dimostrato come farlo in .NET Framework in combinazione con le librerie Elasticsearch e nido.

Damian Zapart è responsabile dello sviluppo di Citigroup Inc. e si concentra principalmente sulle soluzioni enterprise. Allo stesso tempo egli è un geek programmazione interessato alle tecnologie all'avanguardia, design pattern e Big Data. Visitate il suo blog a bit.ly/1suoKN0 per saperne di più su di lui.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Evren Onem (doppie&B) e Bruno Terkaly (Microsoft)
Evren Onem (doppie&B) è un principio software engineer presso D&B. Suo compito è di progettare e costruire il resto massively scalable API. È inoltre ricercatore notturno su reti ad hoc radio cognitiva.

Bruno Terkaly è il principale software engineer presso Microsoft con l'obiettivo di consentire lo sviluppo di servizi e applicazioni leader di settore tra i dispositivi. Egli è responsabile della guida superiore cloud e mobile opportunità attraverso gli Stati Uniti e oltre dal punto di vista tecnologia-abilitazione. Egli aiuta i partner portano le loro applicazioni al mercato fornendo orientamento architettonico e tecnico profondo impegno durante l'ISV valutazione, sviluppo e distribuzione. Egli collabora inoltre con il cloud e mobile gruppi ingegneria, fornendo feedback e influenzando la tabella di marcia.