{"id":6122,"date":"2023-08-04T09:00:00","date_gmt":"2023-08-04T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6122"},"modified":"2023-08-02T11:00:01","modified_gmt":"2023-08-02T09:00:01","slug":"opensearch-guida-completa-alla-configurazione-perfetta-e-al-suo-utilizzo-su-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/opensearch-guida-completa-alla-configurazione-perfetta-e-al-suo-utilizzo-su-aws\/","title":{"rendered":"OpenSearch: Guida completa alla configurazione perfetta e al suo utilizzo su AWS"},"content":{"rendered":"\n
In un mondo in cui avere un approccio basato sui dati<\/strong> sembra essere l’unica via per rimanere competitivi in un mercato in rapida evoluzione, la gestione efficace e l’elaborazione real-time di grandi quantit\u00e0 di dati, insieme a sistemi efficaci di visualizzazione sono sempre pi\u00f9 una priorit\u00e0 per le aziende di ogni settore e dimensione.<\/p>\n\n\n\n In questo contesto, la scelta dello strumento che meglio soddisfa le esigenze aziendali sulla base di quantit\u00e0 e tipologia di informazioni da analizzare \u00e8 spesso meno semplice di quanto sembri.<\/p>\n\n\n\n In questo articolo, presentiamo OpenSearch, un set di strumenti altamente scalabile in grado di fornire accesso rapido a grandi volumi di dati.<\/p>\n\n\n\n Cominciamo!<\/p>\n\n\n\n OpenSearch \u00e8 una suite di ricerca e analisi open source utilizzata per eseguire query su grandi volumi di dati utilizzando chiamate API o un dashboard integrata. OpenSearch offre funzionalit\u00e0 come query full-text, completamento automatico, ricerca a scorrimento, punteggio e classificazione personalizzabili, ricerca fuzzy<\/em>, corrispondenza di frasi e altro ancora. Le risposte possono essere restituite in formato jdbc, csv, raw o JSON.<\/p>\n\n\n\n Facciamo una breve descrizione dei componenti fondamentali di un cluster OpenSearch:<\/p>\n\n\n\n Per cercare i dati \u00e8 necessario organizzarli in indici<\/strong>. Gli indici memorizzano i documenti (insiemi di campi con coppie chiave-valore) e li ottimizzano. L’ottimizzazione \u00e8 possibile perch\u00e9 ogni campo ha un tipo specifico. \u00c8 possibile specificare i tipi di campo. Se questo non avviene, sar\u00e0 OpenSearch a tentare di determinare automaticamente il tipo.<\/p>\n\n\n\n Un’altra forma di ottimizzazione \u00e8 la suddivisione dell’indice in diversi shards<\/strong>. Ciascun frammento contiene un sottoinsieme dei documenti all’interno dell’indice. Quando si cercano dei dati, le query vengono eseguite su diversi shard in parallelo se ogni shard si trova su un nodo diverso. La dimensione degli shard dovrebbe essere di circa 10-30 GB per carichi di lavoro che richiedono una bassa latenza di ricerca e 30-50 GB per carichi di lavoro pesanti in scrittura come l’archiviazione dei log.<\/p>\n\n\n\n Le istanze di OpenSearch sono chiamate nodi<\/strong>. OpenSearch pu\u00f2 funzionare come un cluster a nodo singolo o multi-nodo. In quest’ultimo caso, il numero di nodi, i tipi di nodo e il relativo hardware dipendono dal caso d’uso.<\/p>\n\n\n\n I tipi di nodi<\/strong> sono:<\/p>\n\n\n\n Un nodo pu\u00f2 avere pi\u00f9 tipi. Per impostazione predefinita, ogni nodo \u00e8 un nodo master di dati, di acquisizione e di coordinamento.<\/p>\n\n\n\n Durante la creazione di un cluster AWS OpenSearch, puoi personalizzare i nodi di dati e i nodi master dedicati.<\/p>\n\n\n\n Per i nodi di dati, puoi specificare il numero di nodi, il tipo di istanza, il tipo di volume e la dimensione del volume.<\/p>\n\n\n\n I Master Node dedicati sono nodi che non contengono dati e sono dedicati alla gestione del cluster. Puoi scegliere di non avere alcun nodo master dedicato negli ambienti di sviluppo o test. Poich\u00e9 non contengono dati, \u00e8 necessario specificare solo il numero di nodi e il tipo di istanza.<\/p>\n\n\n\n Su AWS \u00e8 possibile creare un cluster OpenSearch in due modi diversi:<\/p>\n\n\n\n L’approccio classico \u00e8 quello Serverfull<\/strong> in cui occorre scegliere quanti nodi si desidera creare, specificandone il tipo, il dimensionamento e altre propriet\u00e0.<\/p>\n\n\n\n Diamo un’occhiata alla console AWS e analizziamo il servizio Amazon OpenSearch<\/strong>. Il primo passo che faremo sar\u00e0 la creazione di un dominio<\/strong>; in altre parole un cluster OpenSearch.<\/p>\n\n\n\n Potrai scegliere tra due opzioni: Easy create<\/strong> o Standard create<\/strong>.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Il nostro consiglio \u00e8 quello di scegliere l’opzione di Standard Create<\/strong> poich\u00e9 \u00e8 pi\u00f9 flessibile. L’opzione di Easy create<\/strong> \u00e8 consigliata invece per brevi demo o POC.<\/p>\n\n\n\n Optando per la Standard create<\/strong>, ci verr\u00e0 chiesto di scegliere tra due template gi\u00e0 pronti: Produzione<\/strong> o sviluppo\/test<\/strong>. Suggeriamo di saltare questa scelta e di continuare con la configurazione personalizzata.<\/p>\n\n\n\n La selezione pi\u00f9 importante \u00e8 il tipo di ridondanza del cluster:<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n \u00c8 importante prestare attenzione a queste opzioni poich\u00e9 con queste scelte potrebbe cambiare drasticamente il prezzo che andremo a pagare.<\/p>\n\n\n\n Infatti, l’opzione Dominio con standby<\/strong> creer\u00e0 un cluster con minimo 3 nodi di dati, ed sar\u00e0 possibile incrementarli solo di multipli di 3.<\/p>\n\n\n\n Con il Dominio senza standby<\/strong>, \u00e8 possibile personalizzare il numero di nodi, ma nessuno di essi sar\u00e0 riservato come nodo standby.<\/p>\n\n\n\n Qual \u00e8 la soluzione pi\u00f9 adatta dunque? <\/p>\n\n\n\n Come regola generale, scegli l’opzione Dominio con standby<\/strong> per i carichi di lavoro mission-critical. Per altri scenari, optiamo invece per l’altra opzione.<\/p>\n\n\n\n AWS fornisce OpenSearch Serverless, una configurazione on-demand a scalabilit\u00e0 automatica per Amazon OpenSearch Service. OpenSearch Serverless fornisce raccolte, ovvero gruppi di indici con un caso d’uso comune. Le raccolte sono la controparte serverless dei cluster, ma non richiedono il provisioning manuale.<\/p>\n\n\n\n OpenSearch Serverless consente due diversi tipi di raccolte: raccolte di serie temporali<\/strong> e raccolte di ricerca<\/strong>.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n La differenza principale \u00e8 che nelle raccolte di ricerca tutti i dati vengono archiviati in uno storage caldo<\/em> per garantire tempi di risposta alle query estremamente rapidi, mentre le raccolte di serie temporali utilizzano una combinazione di cache hot e warm per ottimizzare i tempi di risposta alle query per i dati ad accesso pi\u00f9 frequente.<\/p>\n\n\n\n Inoltre, \u00e8 possibile indicizzare per ID personalizzato solo nelle raccolte di ricerca.<\/p>\n\n\n\n La capacit\u00e0 di calcolo OpenSearch Serveless \u00e8 misurata in OpenSearch Compute Unit (OCU). Ogni OCU \u00e8 una combinazione di 6 GiB di memoria, CPU virtuale corrispondente e trasferimento dati su Amazon S3.<\/p>\n\n\n\n La prima raccolta Serverless crea un’istanza di un totale di quattro OCU (2 utilizzati per l’acquisizione, primario e standby; 2 utilizzati per la ricerca, una replica attiva per l’alta disponibilit\u00e0). Le raccolte successive possono condividere queste OCU. OpenSearch ridimensiona le OCU in base ai carichi di lavoro di indicizzazione e ricerca. Queste quattro OCU iniziali sono sempre attive, anche in assenza di attivit\u00e0 di indicizzazione o ricerca, pertanto vengono addebitate almeno quattro OCU. Si pu\u00f2 comunque impostare un numero massimo di OCU per contenere i costi. <\/p>\n\n\n\n In aggiunta, viene anche addebitato lo spazio di archiviazione conservato in Amazon S3.<\/p>\n\n\n\n Ok, ora sappiamo tutto sulla creazione di un cluster OpenSearch, ma come possiamo usarlo? Attraverso le query<\/strong>.<\/p>\n\n\n\n OpenSearch fornisce un linguaggio di ricerca chiamato DSL (Query Domain-Specific Language) che fornisce un’interfaccia JSON. OpenSearch supporta anche SQL per scrivere query anzich\u00e9 utilizzare DSL.<\/p>\n\n\n\n Esistono due tipi principali di query: Leaf queries<\/strong> e Compund queries<\/strong><\/p>\n\n\n\n Le leaf query ricercano un valore specificato in uno o pi\u00f9 campi. Le leaf query possono essere ulteriormente classificate in diversi sottotipi.<\/p>\n\n\n\n Le query full-text vengono utilizzate per documenti di testo. Esistono diversi tipi di query full-text.<\/p>\n\n\n\n \u00c8 possibile abbinare un valore specifico in un campo specifico o cercare i valori in un elenco di campi. Si pu\u00f2 assegnare un peso a ciascun campo per aumentarne il valore nel punteggio del risultato. Ad esempio, durante la ricerca di un libro, trovare il valore nel campo “titolo” potrebbe avere un impatto maggiore rispetto a trovarlo nel campo “abstract”.<\/p>\n\n\n\n Un tipo di query consente di cercare termini diversi in un campo e l’ultimo termine della stringa di input verr\u00e0 utilizzato come prefisso per avere documenti che contengono uno qualsiasi di questi termini o termini che iniziano con il prefisso.<\/p>\n\n\n\n Alcune query full-text supportano un parametro \u201cfuzziness\u201d utile nel caso di input scritti con alcuni caratteri mancanti o caratteri la cui posizione viene scambiata.<\/p>\n\n\n\n Altri supportano un parametro “slop” che controlla come le parole possono essere ordinate in modo errato ed essere comunque considerate una corrispondenza.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Le Term-level queries vengono utilizzate per cercare nei documenti un termine specifico.<\/p>\n\n\n\n \u00c8 possibile cercare un termine esatto o pi\u00f9 termini in un campo. Durante la ricerca di pi\u00f9 termini, le Term-level queries consentono anche di specificare il numero minimo di corrispondenze richieste. \u00c8 possibile cercare un ID, un valore contenuto in un intervallo o termini che contengono un prefisso specifico. <\/p>\n\n\n\n Le query fuzzy<\/em> cercano termini simili al termine di ricerca utilizzando la distanza di Levenshtein. Le Term-level queries offrono la possibilit\u00e0 di effettuare ricerche utilizzando espressioni regolari Wildcard o Lucene. Puoi anche cercare documenti che contengono un campo specifico invece di un valore.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Le query XY ricercano documenti che contengono geometrie utilizzando i campi xy_point e xy_shape. I campi xy_point supportano i punti. I campi xy_shape supportano punti, linee, cerchi e poligoni.<\/p>\n\n\n\n \u00c8 possibile cercare documenti i cui punti o forme intersecano la forma fornita oppure documenti le cui forme non si intersecano, sono contenute o contengono la forma fornita.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Le query geografiche vengono utilizzate per cercare documenti contenenti geometrie geospaziali. Le query geografiche supportano punti e forme come linee, cerchi e poligoni.<\/p>\n\n\n\n \u00c8 possibile cercare documenti i cui valori geopoint si trovano all’interno di un riquadro di delimitazione o di un poligono. Le query geografiche restituiscono documenti che contengono geopoint o geoshape che intersecano la forma fornita, oppure documenti che contengono geoshape che non si intersecano, sono contenuti o contengono la forma fornita. \u00c8 inoltre possibile eseguire query per documenti con punti geografici che si trovano entro una distanza specificata da un punto geografico fornito.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Le Joining queries possono essere utilizzate per interrogare un oggetto nidificato come documento indipendente o per recuperare documenti padre o documenti figlio collegati tramite un campo di tipo “join”.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Le compound query eseguono il wrapping di pi\u00f9 leaf query per combinarne i risultati o per modificarne il comportamento. Puoi unire pi\u00f9 clausole di query con la logica booleana o assegnare un punteggio pi\u00f9 alto ai documenti che corrispondono a pi\u00f9 clausole. Le query composte offrono anche la possibilit\u00e0 di creare una funzione per ricalcolare il punteggio dei documenti restituiti. Infine, \u00e8 possibile combinare una query \u201cpositiva\u201d con una query \u201cnegativa\u201d; i documenti trovati attraverso la query positiva avranno un punteggio maggiore, mentre i documenti trovati attraverso la query negativa avranno un punteggio diminuito. Questo \u00e8 utile in caso di sinonimi che desideri rimuovere dai risultati.<\/p>\n\n\n\n Esistono due scopi principali per l’utilizzo del servizio OpenSearch: uno \u00e8 archiviare e interrogare\/analizzare i log<\/strong> e le metriche <\/strong>dell’applicazione e dell’infrastruttura, l’altro \u00e8 creare un motore di ricerca<\/strong>.<\/p>\n\n\n\n Questo \u00e8 uno degli usi principali di OpenSearch. Grazie al rapido tempo di risposta alle query, consente la ricerca molto veloce di specifici log dell’applicazione o dell’infrastruttura.<\/p>\n\n\n\n Lo scopo principale di questa soluzione \u00e8 disporre di un archivio di log centralizzato in cui \u00e8 possibile trovare tutti i log delle applicazioni e dell’infrastruttura e creare dashboard quasi in tempo reale che visualizzano metriche diverse per comprendere l’integrit\u00e0 dell’applicazione.<\/p>\n\n\n\n Immaginiamo una web app composta da un front-end Single Page Application e un back-end ospitato su AWS utilizzando servizi serverless come Amazon API Gateway e AWS Lambda. Quello che si pu\u00f2 fare \u00e8 inviare tutti i log ad AWS OpenSearch strutturando un payload di log con almeno queste informazioni:<\/p>\n\n\n\n Baster\u00e0 modificare gli attributi in base a ci\u00f2 che stai registrando; Ad esempio, possiamo immaginare di avere almeno due log per ogni richiesta, uno all’avvio della richiesta – che aggiunger\u00e0 l’origine dell’evento come attributi aggiuntivi – e uno al termine della richiesta, con un attributo che definisce il codice di stato della risposta. Se si verifica un errore, possiamo immaginare di registrare lo stesso payload con un codice di stato di errore.<\/p>\n\n\n\n Con queste poche informazioni possiamo costruire una semplice Dashboard che ci mostri:<\/p>\n\n\n\n e possiamo filtrare tutti i log per un intervallo di tempo specifico o anche per l’id di una singola richiesta ottenendo l’intero log di quella specifica richiesta.<\/p>\n\n\n\n Un altro perfetto caso d\u2019uso per OpenSearch \u00e8 la creazione di un motore di ricerca. Grazie a tutti i diversi tipi di query supportati, \u00e8 semplice creare una barra di ricerca che utilizza la fuzziness<\/em> per cercare tutti i dati che assomigliano a ci\u00f2 che l’utente ha digitato.<\/p>\n\n\n\n Puoi persino utilizzare la funzione match_phrase_prefix<\/em> per completare automaticamente l’input dell’utente in base ai dati che hai nel database o utilizzare la funzione di suggerimento per correggere l’input dell’utente.<\/p>\n\n\n\n In questo articolo abbiamo dato una visione generale di cos’\u00e8 Opensearch, dei suoi fondamenti e di come sfruttare i servizi AWS per gestire un cluster di questo tipo. <\/p>\n\n\n\n Molti argomenti non sono stati presi in considerazione, ad esempio come autenticarsi e autorizzarsi ad un cluster OpenSearch, come sfruttare S3 per lo storage di dati warm e cold, abilitare Cognito come Identity Provider o come gestire il Disaster Recovery per le applicazioni business critical.<\/p>\n\n\n\n Se siete interessati a questi o ad altri aspetti riguardnti l’utilizzo di OpenSearch, scriveteci nei commenti!<\/p>\n\n\n\n A presto su Proud2beCloud con un nuovo blog post!<\/p>\n\n\n\n Ti \u00e8 piaciuto l’articolo? Scegli gli argomenti<\/a> che pi\u00f9 ti interessano e iscriviti alla newsletter!<\/em><\/p>\n\n\n\nTerminologia<\/h2>\n\n\n\n
\n
\n
Tipologie di provisioning<\/h2>\n\n\n\n
\n
Serverfull<\/h3>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure><\/div>\n\n\n
Serverless<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n
Tipi di query<\/h2>\n\n\n\n
Leaf Queries<\/h3>\n\n\n\n
Full-text queries<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
Term-level queries<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
XY queries<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
Geographic queries<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
Joining queries<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
Compound queries<\/h3>\n\n\n\n
Casi d\u2019uso<\/h2>\n\n\n\n
Logs & Metriche<\/h3>\n\n\n\n
\n
\n
Motore di ricerca<\/h3>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n