[NoSQL] Implementare un Document Store NoSQL con Oracle 12c e le SODA API

Postato il 27 Dicembre 2016 by Fr@nk

Avete intenzione di implementare una schemaless application, memorizzando le informazioni in modo “dinamico” e flessibile, secondo il cosiddetto paradigma “NoSQL style document store”?

Anche Oracle DB, a partire dalla versione 12.1.0.2, fornisce il supporto per la memorizzazione, l’indicizzazione e la ricerca di documenti in formato JSON.

Più dettagliatamente, Oracle DB 12c permette, senza necessità di installare plugin aggiuntivi, l’implementazione di un Document Store e fornisce il seguente set di API, progettate per garantire il supporto allo sviluppo di schemaless application:

SODA for Java: interfaccia di programmazione document-store per sviluppatori Java che usano JDBC per comunicare con il database. SODA for Java consiste di un set di semplici classi che rappresentano il database, una collezione di documenti e un documento. I metodi di queste classi forniscono tutte le funzionalità richieste per gestire ed interrogare documenti e collezioni di documenti memorizzati in un database Oracle;
SODA for REST: interfaccia REST-based document-store implementata come Java servlet e distribuita come parte dell’Oracle REST Data Services (ORDS) 3.0. Le applicazioni basate su SODA for REST usano il protocollo HTTP per comunicare con la Java Servlet. SODA for REST Servlet può anche essere eseguito su un HTTP Server nativo del database (esistono versioni “bundle” di Web Server, come TomCat e JBoss opportunamente configurati per accedere al DB Oracle tramite API SODA). I metodi HTTP come PUT, POST, GET e DELETE mappano le operazioni eseguite sui documenti JSON. Fornendo API di tipo REST è possibile integrare la soluzione con web application esterne per esporre i dati memorizzati nella base dati Oracle.

Riferimento: http://www.oracle.com/technetwork/database/appdev-with-soda-2606220.pdf

Modello relazionale VS. Modello No-SQL. Volendo comparare un database relazionale con un DB NoSQL “document-store”, è possibile dire che:

Una collezione di documenti è una tabella
Un documento è una riga di una tabella
Un campo del documento è una colonna della tabella

I documenti in formato JSON vengono memorizzati con un ID univoco all’interno di una collezione. Per ciascun documento è possibile recuperare metadati, come data di creazione, dati di aggiornamento, owner e versione del documento, ecc.

Le funzionalità offerte da un document store includono:

Creazione e cancellazione di una collezione
Creazione, ricerca, aggiornamento o cancellazione di un singolo documento in base al suo ID
Recupero dei documenti in una collezione
Ricerca di una collezione, tipicamente utilizzando Query By Example (QBE) metaphor
Creazione e cancellazione di indici

Dato questo semplice livello di funzionalità fornito da un document store, l’API diventa semplice, particolarmente quando comparato con le tradizionali API SQL-based come JDBC.

Il DBMS Oracle già forniva dalla versione 9 il supporto alla memorizzazione, alla ricerca e all’indicizzazione di documenti XML. Oracle Database 12c estende tale funzionalità ai documenti JSON, introducendo le due implementazioni dell’interfaccia SODA, denominate, come suddetto, SODA for REST e SODA for JAVA, e ponendosi sul mercato come valida alternativa tra i NoSQL-style Document Store.

Oracle NoSQL-style Document Store Capabilities. In Oracle DB 12c, i documenti vengono memorizzati, indicizzati e ricercati senza che il database ne conosca la struttura (schemaless). Ciò lascia agli sviluppatori la libertà di modificare la struttura dei documenti JSON in base alle esigenze. Non esiste un datatype dedicato per memorizzare i documenti JSON, ma gli stessi vengono memorizzati con i tipi standard VARCHAR2, CLOB e BLOB. Viene introdotto il nuovo constraint “IS JSON”, utilizzato per assicurare che il contenuto di una colonna sia un JSON valido, fornendo pieno supporto al trattamento avanzato dei JSON, come disaster recovery, replication, compression ed encryption.

Inoltre, è possibile eseguire delle query SQL direttamente sulle tabelle di documenti JSON del database utilizzando le JSON Path Expressions. Tali espressioni sono equivalenti al linguaggio xPath in XML e sono sintatticamente simili a JavaScript. Si riportano di seguito degli esempi:

SODA API. SODA fornisce un set di API semplice da utilizzare per lavorare con i documenti memorizzati in un Oracle Database. L’oggetto Database, che è richiesto per interagire con le Collections, viene istanziato usando un database connection con le API SQL standard di Oracle. La versione corrente di SODA adotta una strategia di optimistic locking, ma quella di pessimistic locking èsarà probabilmente disponibile nelle future release.

La specifica SODA definisce un set di metodi che forniscono le seguenti funzionalità:

Stabilire una connessione ad un Oracle Database Document Store
Creare e cancellare una collezione
Creare, ricerca, aggiornare e cancellare un documento
Elencare i contenuti di una collezione
Ricercare una collezione di documenti che “matchino” una espressione Query By Example (QBE)
Operazioni di “bulk insert” in una collezione
Creazione e cancellazione di indici

Di seguito, riporto alcune caratteristiche dell’implementazione “SODA for JAVA”, tralasciando “SODA for REST” (utile nel caso ci si voglia interfacciare direttamente con il Document Store con il paradigma REST).

SODA for JAVA. Consiste di un set di semplici classi che rappresentano un database, una collezione di documenti e il documento stesso. I metodi che queste classi forniscono permettono di gestire e ricercare le collezioni e i documenti JSON memorizzati. Utilizza una connessione JDBC standard e SQL*NET per comunicare con il database: ciò significa che le API sono transazionali e una serie di operazioni SODA può generare una singola transazione. Poiché SODA utilizza una connessione JDBC, è possibile utilizzare sia le API di SODA for JAVA che quelle tradizionali JDBC.

Di seguito, si riportano le principali classi di “SODA for JAVA” con relativa descrizione:

Classe	Descrizione	Commenti
OracleClient	Classe client generica SODA. L’entry point di SODA per i JSON.
OracleRDBMSClient	La classe Client dell’Oracle Database	Usata per recuperare l’oggetto OracleDatabase
OracleDatabase	Rappresenta un Document Store, il quale consiste di uno o più collezioni.	Usato per accedere alle collezioni.
OracleDatabaseAdmin	Usato per creare e cancellare collezioni
OracleCollection	Rappresenta una collezione di un Document Store
OracleCollectionAdmin	Usato per creare e cancellare indici
OracleDocument	Rappresenta un documento in un Document Store	Aggiorna (o crea) il documento con un dato ID

Struttura di un documento di una collezione. Di seguito, si riporta la struttura SQL di una collezione rappresentata su una tabella Oracle e contenente il JSON in corrispondenza di una colonna CLOB:

Name Null? Type

—————————————– ——– —————————-

ID NOT NULL VARCHAR2(255)

CREATED_ON NOT NULL TIMESTAMP(6)

LAST_MODIFIED NOT NULL TIMESTAMP(6)

VERSION NOT NULL VARCHAR2(255)

JSON_DOCUMENT CLOB

Le colonne della tabella rappresentano quanto segue:

ID	ID autogenerato del singolo record
JSON_DOCUMENT	Contenuto del documento in JSON
CREATED_ON	Timestamp (autogenerato) di inserimento del record
LAST_MODIFIED	Timestamp (autogenerato) di modifica del record
VERSION	Versione del documento (incrementato automaticamente quando viene modificato)

Per dettagli sulle API di SODA e sulla potenza espressiva delle Query By Example per la ricerca dei documenti di una collezione: http://docs.oracle.com/cd/E63251_01/doc.12/e58124/soda.htm#ADSDA107

Memorizzazione dei documenti JSON (codifica e datatype). Un documento JSON può essere considerato un dato semi-strutturato, ossia non conforme alla struttura formale dei modelli di dato associato con le basi di dati relazionali. Esso, comunque, contiene etichette o altri marcatori per separare gli elementi semantici e rafforzare le gerarchie di record e campi all’interno del dato. E’ anche conosciuto come “dato senza schema” o “dato con struttura autodescritta”.

Oracle raccomanda di memorizzare tali dati utilizzando datatype di tipo LOB, in quanto la quantità di caratteri può essere elevata (maggiore di 4000 byte e, dunque, della massima capacità di un datatype VARCHAR2). I datatype raccomandati per i contenuti testuali sono Characted Large Object (CLOB) e National Character Large Object (NCLOB).

Il datatype CLOB è raccomandato per la memorizzazione di stringhe o documenti di lunghezza fissa. Invece, il datatype NCLOB è raccomandato per quelli a lunghezza variabile.

Riferimento: https://docs.oracle.com/database/121/ADXDB/json.htm#ADXDB6252

Per quanto riguarda il character encoding, conviene adottare quello AL16UTF16 o AL32UTF8. In particolare, Oracle raccomanda l’uso di AL32UTF8 per memorizzare i dati con caratteri Unicode.

Riferimenti:
https://docs.oracle.com/cd/E11882_01/appdev.112/e18294.pdf
https://docs.oracle.com/database/121/NLSPG/ch2charset.htm#NLSPG179

Sicurezza dei dati. Al fine di salvaguardare la sicurezza e l’integrità dei dati,è possibile sfruttare il meccanismo di Oracle Secure Files, il quale consente anche le compressione dei dati memorizzati all’interno di datatype LOB.

Riferimento: https://docs.oracle.com/database/121/ADLOB/toc.htm

This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2016/12/27/nosql-implementare-un-document-store-nosql-in-oracle/.

[BigData] ELK Stack: ElasticSearch + Logstash + Kibana

Postato il 27 Dicembre 2016 by Fr@nk

Risposta

Nel presente articolo riporto alcune informazioni rilevanti relative all’ ELK Stack, set di tecnologie open-source più diffuse e utilizzate per l’implementazione di una soluzione di Log Management, costituito dai seguenti prodotti:

ElasticSearch: server di ricerca basato su Lucene, e, dunque, con capacità “full-text”, e con supporto ad architetture distribuite e su larga scala. Le modalità di interazione e di interrogazione con la base dati proprietaria (su file system) avvengono attraverso interfaccia RESTful. Le informazioni sono memorizzate internamente come documenti JSON; Riferimento: https://www.elastic.co

LogStash: progetto Open Source scritto in JRuby, distribuito in formato JAR, la cui funzione principale è quella di fare il pipe di un qualsiasi evento, che può essere un log di sistema, una riga di testo, un tweet, ecc. Logstash può interfacciarsi con numerosi input, elaborarli, filtrarli e passarli ad un motore di ricerca o memorizzazione, come MongoDB, Redis, ElasticSearch e molto altro, configurando (attraverso un opportuno file di configurazione) la pipeline per l’acquisizione, il filtering e l’invio dei dati. L’integrazione con ElasticSearch è quella più potente e veloce per l’implementazione di una soluzione di log management. Riferimento: https://www.elastic.co/products/logstash

Kibana: è un tool che permette di visualizzare, grazie a strumenti di data analytics, le informazioni indicizzate ed acquisite da ElasticSearch o altri prodotti. Permette la rappresentazione delle informazioni in tempo reale, attraverso dashboard configurabili con vari tipi di widget (pie chart, istogrammi, grafici cartesiani, ecc.). Riferimento: https://www.elastic.co/products/kibana

La soluzione ELK Stack permette di implementare differenti modelli architetturali di alta scalabilità. Per maggiori dettagli su LogStash, vi consiglio il seguente riferimento: LogStask Book. Si riportano, di seguito, alcuni dei modelli di riferimento dell’ELK stack.

Modelli di riferimento: soluzioni con ELK Stack

Soluzione di base
La soluzione di base proposta da ELK Stack prevede la configurazione di una singola istanza di LogStash in modo da acquisire i dati non strutturati da differenti sorgenti. E’ possibile configurare più istanze di LogStash (Agent Shipper), in modo da acquisire i dati da datasource differenti ed indirizzare le informazioni strutturate (documenti JSON) ad un’unica istanza di ElasticSearch. Quest’ultimo effettua l’indicizzazione e la memorizzazione dei documenti JSON acquisiti.

Tramite un file di configurazione è possibile far puntare l’istanza agent di LogStash ad uno o più datasource (SysLog Server, File System, DBMS, ecc.), grazie all’utilizzo di vari input plugin.

Inoltre, è possibile configurare le destinazioni, a cui inviare i documenti JSON degli eventi acquisiti, utilizzando vari output plugin. Il parsing e il filtering degli eventi acquisiti dai vari datasource può essere configurato grazie a filter plugin.

Di seguito, si riporta un esempio di trasformazione di un evento di log in formato SysLog (formato non strutturato) in un documento JSON (formato strutturato):

SysLog Message:

Dec 17 16:00:35 joker systemd-logind[2113]: New session 31581 of user bob.

JSON Log Event:

{
  "host" : "joker.example.com",
  "priority" : 13,
  "timestamp" : "Dec 17 16:00:35",
  "logsource" : "joker.example.com",
  "program" : "bob",
  "pid" : "23262",
  "severity" : 5,
  "facility" : 1,
  "facility_label" : "user-level",
  "severity_label" : "Notice",
  "@timestamp" : "2012-12-17T16:00:35.000Z",
  "@version" : "1",
  "message" : "New session 31581 of user bob",
  "type" : "syslog"
}

Soluzione con coda di messaggi
Quando i dati inviati alla pipeline di LogStash eccedono l’abilità del cluster di ElasticSearch di poterli prendere in input, conviene utilizzare un message queue come buffer. Prevedendo un message queue nell’architettura si garantisce un livello di protezione per evitare la perdita dei dati. In questo modo si riesce ad evitare la congestione dell’istanza Indexer, la quale “scoda” i messaggi sulla coda uno alla volta e in maniera asincrona.

Soluzione ad alta affidabilità

La soluzione su rappresentata è quella più completa dal punto di vista dell’alta affidabilità. Grazie ad un bilanciatore è possibile instradare differenti datasource verso una istanza agent di LogStash attiva ed inviare il messaggio di evento sul message queue. In pratica, ogni istanza agent di LogStash viene configurata su input multipli e l’architettura può essere scalata orizzontalmente. Pipeline separate incrementano, dunque, la reliability del sistema ed eliminano i single points of failure.

Modello per la memorizzazione degli eventi
Nella soluzione con l’ELK Stack, il prodotto ElasticSearch usa Apache Lucene per la creazione degli indici. Ogni indice è un namespace logico che permette di recuperare tutti gli eventi collezionati nella base dati NOSQL di ElasticSearch. Di default, LogStash invia il documento JSON sull’indice che ha nel nome il suffisso del giorno di acquisizione dell’evento, ad esempio: logstash-2015.11.31.

Questo tipo di memorizzazione potrebbe essere preso come riferimento per collezionare le informazioni in tabelle/indici creati su base temporale (ad esempio, mensilmente). In questo modo si potrebbero salvare tutti gli eventi su base temporale, evitando di caricare di troppi record una singola tabella. Tale scelta dipende anche dai tipi di correlazione che occorrerà fornire per la Log Analysis.

Volendo comparare il modello di memorizzazione di ElasticSearch con quello di un database relazionale si ha che:

Un index è una tabella
Un document è una riga della tabella
Un field è una colonna della tabella.

Per maggiori dettagli vi rimando ai tutorial su Mokabyte:

Protetto: [BigData&NoSQL] Log Management: un caso d’uso di Big Data e di Operational Intelligence

Postato il 12 Dicembre 2015 by Fr@nk

This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2015/12/12/bigdatanosql-log-management-un-caso-duso-di-big-data-e-di-operational-intelligence/.

[Gartner] Il futuro degli Analytics: precisi, trasparenti e decisivi

Postato il 23 Giugno 2013 by Fr@nk

Risposta

Interessante il webinar di Gartner intitolato The future of Analytics: precise, transparent and decisive (Il Futuro degli Analytics: Precisi, Trasparenti e Decisivi), tenutosi online il 18 giugno scorso.

Si è parlato dei limiti attuali e delle prossime “sfide” degli analytics , che da “semplici” strumenti di monitoraggio del traffico web (web analytics) sono diventati vere e proprie tecnologie di misurazione (business analytics), in grado di prevedere opportunità di business, scoprire le abitudini degli internauti (pagine visitate, ricerche, preferiti, ecc.), monitorare la “visibilità” delle risorse web sulla rete e il loro impatto (buzzing), in grado di costruire “conoscenza”.

Per far sì che gli strumenti di analytics siano efficaci, occorre “scremare” le informazioni carpite dalla rete, fornendo loro soltanto quelle strettamente necessarie. Ad esempio, costruendo vere e proprie “basi di conoscenza”, in cui memorizzare soltanto le informazioni di interesse per il dominio di analisi. Su tali informazioni, un’organizzazione, ad esempio, si può condurre operazioni di sintesi e di analisi per supportare i propri processi decisionali.

Dunque, gli obiettivi degli Analytics sono riassunti da Gartner nei seguenti punti:

Creare sistemi di misurazione e di classificazione precisi ed operativi. Quest’ultima caratteristica è espressa dal termine “actionable“: gli analytics devono essere finalizzati ad una azione o in qualche modo la devono preparare
Far sì che dall’ “esperienza” dei clienti (customer-facing experience), semplicemente monitorandone e valutandone il grado di soddisfazione (customer satisfaction) o il sentiment, si possano costruire Modelli di Business
Supportare il processo decisionale (decision making)

Il futuro degli analytics è la precisione: nel 20° secolo, i processi di business furono standardizzati, rendendoli più omogenei per arrivare all’efficienza. Nel 21° secolo, i processi di business saranno personalizzati, diventando più precisi per arrivare all’efficacia. Si ricorda che per efficacia si intende la capacità di raggiungere un determinato obiettivo, mentre per efficienza la capacità di raggiungerlo con la minima allocazione possibile di risorse.

Per raggiungere questa efficacia occorre mettere su un Performance Measurement System, nel quale distinguere una fase “intensiva” ed una “estensiva”. Nella fase intensiva, detta “esecutiva“, si vengono a definire le strategie di business, le metriche e gli obiettivi di ogni metrica. Nella fase estensiva, detta “di integrazione e di analisi“, si integrano i dati (interni ed esterni), si calcolano le metriche, si riportano i valori attuali e gli obiettivi per ogni metrica, per poi esaminare le varianze, gli indicatori e gli impatti dei cambiamenti. L’obiettivo di un sistema siffatto è quello di analizzare i dati, per ottimizzare l’allocazione di risorse (la performance, appunto).

La sfida è di passare dai tradizionali strumenti di Business Intelligence e di Analytics a strumenti in grado di supportare il decision making, per attuare azioni-risposte efficaci in tempo reale.

Potremmo definire dei livelli di crescita strutturata per quanto riguarda la “maturità” degli Analytics, visti come tecnologie di supporto alle decisioni di una organizzazione:

Livello 1. Caotico: ogni evento che porta ad una decisione viene trattato differentemente. Non vi è uno scambio di feedback tra i processi di business;
Livello 2. Ripetibile: alcuni processi che portano ad una decisione vengono condivisi tra gruppi e vi è un minimo scambio di feedback sulle decisioni;
Livello 3. Definito: si definiscono processi per il supporto alla decisione all’interno di una organizzazione. Vi è scambio di feedback, ma non vi è alcuna connessione tra i tipi di decisione;
Livello 4. Gestito: le decisioni sono collegate da metriche di performance, processi e sistemi di registrazione (link operazionali, decisioni tattiche e strategiche)
Livello 5. Ottimizzato: il processo di decisione è continuamente rivisto e migliorato. Il feedback è proattivo tra i diversi tipi di decisione (tecniche ottimizzate di decisione).

Ecco i livelli di business analytics in cui ci si muove:

Dall’INFORMAZIONE si riesce a capire attualmente cosa succede e perchè; DESCRIPTIVE & DIAGNOSTIC ANALYTICS. Ad esempio, “Chi sono i miei clienti?“
Dai FORESIGHT (previsioni) si riesce a capire cosa accadrà: PREDICTIVE ANALYTICS. Ad esempio, “A quali clienti potrebbe interessare la mia prossima offerta?”
Dalle DECISIONI si riesce a capire cosa fare e come muoversi: PRESCRIPTIVE ANALYTICS. Ad esempio, “Quale offerta fare a ciascun cliente?”

La frontiera finale delle capacità analitiche (Analytic Capabilities) è costituita dal Prescriptive Analytics. L’Analisi prescrittiva è un’area di business analytics (BA) dedicata a trovare le migliori linee d’azione per una data situazione. Mentre l’analisi descrittiva si propone di fornire indicazioni (insight) su ciò che è successo e quella predittiva aiuta a costruire modelli di previsione su quello che potrebbe accadere, l’analisi prescrittiva serve a determinare la soluzione migliore o l’esito tra le varie scelte, dati parametri noti. L’Analisi prescrittiva può anche suggerire opzioni decisionali per il modo di usufruire di una futura opportunità o attenuare un rischio futuro, e illustrare le implicazioni di ciascuna opzione di decisione. In pratica, l’analisi prescrittiva può continuamente e automaticamente processare nuovi dati per migliorare l’accuratezza delle previsioni e per fornire migliori opzioni decisionali.

Le tecnologie di analisi prescrittiva devono essere adattive per prendere in considerazione il Big Data, la velocità e la varietà di dati che i processi mission critical e i loro ambienti produrranno.

In un processo ad alta intensità di lavoro, l’approccio prescrittivo analizza le potenziali decisioni, le interazioni tra le decisioni, le influenze che portano a queste decisioni e produrre, infine, un “corso” ottimale di azioni da eseguire in tempo reale.

Per attuare un PRESCRIPTIVE ANALYTICS, occorre definire ciò che segue:

un insieme di azioni (decisioni e non solo predizioni)
calcolare i risultati attesi delle opzioni di decisioni alternative (spesso chiamati “decision model“)

L’idea è quella di supportare il processo decisionale come segue:

si scoprono gli eventi di interesse sulle informazioni
tali eventi verranno analizzati ed utilizzati dai processi decisionali per poter attuare delle azioni
le azioni svolte sono continuamente valutate, in modo da monitorarne le performance

L’Analisi prescrittiva anticipa non solo che cosa accadrà e quando accadrà, ma anche perché accadrà. Inoltre, suggerisce opzioni di decisione su come approfittare di una futura opportunità o attenuare un rischio futuro e dimostra l’implicazione di ogni opzione. L’Analisi prescrittiva può continuamente e automaticamente prendere nuovi dati per migliorare la precisione di previsione e fornire migliori opzioni decisionali. Essa ingerisce “dati ibridi”, una combinazione di dati strutturati e non strutturati, e regole di business per prevedere quello che ci aspetta e di prescrivere come approfittare di questo futuro predetto senza compromettere le altre priorità.

Progressi nella velocità di calcolo e lo sviluppo di complessi algoritmi matematici applicati ai set di dati (Big Data) hanno reso possibile l’analisi prescrittiva. Tecniche specifiche utilizzate nelle analisi prescrittive comprendono l’ottimizzazione, la simulazione, la teoria dei giochi e metodi di decisione-analisi.

Ecco video di IBM che spiegano il passaggio dal descrittive analytics, ai predicative analytics e prescriptive analytics: http://searchcio.techtarget.com/definition/Prescriptive-analytics

This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2013/06/23/gartner-il-futuro-degli-analytics-precisi-trasparenti-e-decisivi/.

[NO-SQL] Appunti su analisi di performance e comparazione dei database NoSQL

Postato il 12 Febbraio 2013 by Fr@nk

Continuando la trattazione dell’argomento dei Database No-SQL, viste le impressioni e segnalazioni via email dei visitatori di questo blog, condivido un pò di appunti in un documento che potete scaricare qui di seguito:

Database NoSQL-Comparazione tecnologie

Il documento raccoglie le considerazioni e le valutazioni oggettive emerse durante la lettura di articoli e documentazioni online sull’argomento dei DB No-SQL. Nello specifico, l’oggetto di studio è stato MongoDB, confrontandolo con altre soluzioni (relazionali e non) e, in particolare, è stata approfondito il suo possibile utilizzo per la gestione di una struttura a grafo.

Ecco l’indice dei paragrafi del documento, sperando vi possa essere utile per spunti o per far nascere riflessioni/discussioni sull’argomento:

I database NoSQL
1. Perché NoSQL? Il teorema di CAP e il No-SQL data model
2. Un confronto tra le famiglie di DB NoSQL
3. I database document-oriented e graph-oriented
Breve introduzione su MongoDB
1. Principali caratteristiche di MongoDB
2. Comparazione tra MongoDB e MySQL
3. Ambiti di utilizzo e realizzazione dei direct graph con MongoDB
4. Soluzioni ibride: MongoDB + database a grafo + RDF triple store
5. Analisi delle prestazioni di MongoDB all’aumentare dei documenti memorizzati
Confronto tra le performance di MongoDB e di altri database NoSQL
1. Confronto MongoDB con vari database NoSQL
2. Confronto HBase e MongoDB
Analisi di performance dei Graph Database
1. Elenco e caratteristiche di varie implementazioni di Graph Database
2. Analisi e confronto delle performance di varie implementazioni di Graph Database
3. Scalabilità

This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2013/02/12/no-sql-appunti-su-analisi-di-performance-e-comparazione-dei-database-nosql/.

: Titolo: Database NoSQL-Comparazione tecnologie (0 click)
Etichetta:
Filename: database-nosql-comparazione-tecnologie.pdf
Dimensione: 770 KB

[NO-SQL] Not Only SQL: una panoramica sui database NoSQL

Postato il 7 Febbraio 2013 by Fr@nk

Risposta

In precedenti articoli su questo blog, si è già accennato al movimento NoSQL (Not Only SQL) e ad una delle sue tecnologie, MongoDB:

Ebbene, da allora (pochi mesi), le tecnologie sono aumentate e l’interesse verso questo modello di dati è esploso, di pari passo alla tematica del Big Data che sta diventando molto di moda nell’ultimo periodo (molti ne parlano, ma chi davvero lo fa???).

Ecco le keywork che riassumono le peculiarità dei DB NoSQL:

non-relational: le struttura di memorizzazione dei dati è differente dal modello relazionale. L’approccio a “schema rigido” dei db relazionali non permette di memorizzare dati fortemente dinamici. I db NoSQL sono “schemaless” e consentono di memorizzare “on the fly” attributi, anche senza averli definiti a priori
distributed: la flessibilità nella clusterizzazione e nella replicazione dei dati permette di distribuire su più nodi lo storage (e il calcolo), in modo da realizzare potenti sistemi fault–tolerance
open-source: alla base del movimento NoSQL vi è la filosofia “open-source”, fondamentale per contribuire ad accrescere le potenzialità delle sue tecnologie
horizontally scalable: architetture enormemente scalabili, che consentono di memorizzare e gestire una grande quantità di informazioni

Al seguente link, trovate una lista aggiornata dei database NoSQL che rispettano i requisiti su citati: http://nosql-databases.org

Un whitepaper sulla tecnologia dei DB NoSQL l’ho trovato sul sito di CouchBase (un altro DB NoSql document-oriented): NoSQL Database Technology

E ancora, “10 cosa da sapere sui DB NoSQL”: 10 things you should know about NoSQL databases

Essi sono suddivisi nelle seguenti famiglie:

Wide Column Store / Column Families
Document Store
Key Value / Tuple Store
Graph Databases
Multimodel Databases
Object Databases
Grid & Cloud Database Solutions
XML Databases
Multidimensional Databases
Multivalue Database

Dal precedente grafico, si possono fare delle considerazioni. Un parametro di valutazione è l’operational complexity: la struttura di memorizzazione dei DB a grafo è particolarmente complessa e anche gli algoritmi che ne permettono la navigazione (traversal) sono i classici algoritmi di routing, di una certa complessità computazione. Ovvio che all’aumentare della complessità nella struttura dati, diminuisce la capacità di memorizzazione dei dati stessi (parametro size). La famiglia dei DB a grafo (graph databases), come NEO4J e OrientDB, dispone di routine di accesso ai dati particolarmente performanti, ma non possono trattare troppi dati – [per una introduzione ben fatta sui database a grafo, eccovi un buon riferimento: Graph Databases An Overview].

Al contrario, la famiglia dei DB a chiave-valore (key-value databases), come Redis, è particolarmente consigliata per memorizzare e gestire grosse quantità di dati. La famiglia dei DB a documenti (document databases), come MongoDB, si trovano in una posizione intermedia.

Un plauso va a due sviluppatori italiani che hanno sviluppato i più utilizzati DB NoSQL del momento:

Un sondaggio aperto agli utilizzatori (previa registrazione) sui vari DB (sia relazionali che non) e che vi permette di comparare le varie caratteristiche, lo trovate a questo link (potete inserire più colonne per confrontare più tecnologie tra loro): http://vschart.com/compare/mongodb/vs/redis-database

Ho cercato online una tesi di laurea in cui poter trovare un benchmark sui DB NoSQL e ho trovato quella ben fatta su Analisi delle performance dei database non relazionali: il caso di studio di MongoDB dell’Università di Padova, dove si compara MongoDB col db relazionale più diffuso, MySQL.

Eccovi un articolo di comparazione tra i principali DB delle famiglie elencate:

Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris comparison

E ancora, un confronto tra alcuni DB NoSQL, dove Cassandra e HBase vincono sul throughput: A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak.

Il Tag Cloud: dai blog al Big Data

Postato il 6 Dicembre 2012 by Fr@nk

Risposta

Ultimamente si parla molto del tag cloud (o word cloud), uno strumento che sta diventando particolarmente utile nell’ambito della data analysis. Basta guardare il grande successo di Expert Systems, nell’ambito appunto dell’analisi semantica di varie fonti online (Expert Systems Rassegna Stampa). Ma il tag cloud c’è da un bel po’: nei blog, per esempio, esiste dalla notte dei tempi, e nell’era del Big Data e dell’Internet of Things ha acquisito la sua giusta notorietà, visto come uno strumento utile per filtrare un bel po’ di informazioni e concetti sulla miriade di contenuti sparsi in rete.

Il Tag Cloud non è altro che una rappresentazione visiva di concetti, detti keyword metadata (tags), ricercati su fonti online e visualizzati sotto forma di testo semplice. I tag sono solitamente parole singole e l’importanza di ognuno di essi è mostrata con un font di dimensione diffente e/o uno specifico colore. Avere una rappresentazione “a nuvola” ci aiuta ad estrapolare meglio i concetti del dominio di analisi e a navigarlo (magari associando ai singoli tag anche dei link ipertestuali agli articoli/fonti da cui sono stati estratti).

Solitamente i tag cloud si basano sul concetto di “frequency“, ossia associano a ciascun tag una frequenza, il numero di volte in cui quel tag è stato “rintracciato” in un singolo item (articolo, pagina web o fonte) e, dunque, sulla “popularity” di quel concetto sulla rete.
Esiste anche un modo per “categorizzare” i tag, con i cosiddetti tag cluster (clustering): i tag che si riferiscono allo stesso contesto (categoria o tassonomia) possono essere classificati in “sotto-nuvole”, dette appunto cluster. La categorizzazione avviene spesso applicando algoritmi di similarità semantica (Natural Language Processing) o statistici.

Sui blog, questa categorizzazione di informazioni viene generata dagli utenti mediante l’utilizzo di parole chiave (o tag) scelte liberamente, e si parla di Folksonomie. Vi invito a leggere l’interessante articolo: “Folksonomy: questione di semantica“.

Vi riporto ora delle librerie che ho studiato e utilizzato per la realizzazione di una tag cloud:

La libreria D3-Cloud di Jason Davies (basata su D3js) e scaricabile da GitHub

La piattaforma Carrot2 Clustering Engine, che permette di clusterizzare i risultati di una ricerca in topic (cluster)

[BigData] Il Big Data Forum 2012 a Roma: le soluzioni ICT per un vantaggio competitivo

Postato il 26 Novembre 2012 by Fr@nk

Risposta

Il 21 Novembre scorso si è tenuta a Roma la 2° edizione del Big Data Forum, dallo slogan “Big Data Forum 2012: per fare chiarezza sul fenomeno dell’esplosione dei dati e scoprire le soluzioni ICT che consentono di trasformarlo in vantaggio competitivo“.

L’evento, pubblicizzato da ICT4Executive, con partner di eccezione come Microsoft, Oracle e Informatica Software, è stato condotto da relatori di riguardo, particolarmente distinti sia nel campo della ricerca ICT (in particolare, nella Business Intelligence), che in quello strategico aziendale.

Ho partecipato all’evento e vi riporto un resoconto dettagliato delle tematiche affrontate ed estrapolate dagli interventi dei relatori presenti.

La Big Data Analysis

Il moderatore Carlo Vercellis, responsabile dell’Osservatorio di Business Intelligence & Big Data Analytics e professore alla School Management del Politecnico di Milano, ha sottolineato che il BigData è un tema di attualità molto in voga nell’ultimo periodo, come il cloud computing del resto, ma che da fenomeno del momento deve trasformarsi in innovazione tecnologica, in grado di cambiare gli attuali schemi e paradigmi del modo di trattare le informazioni su Internet.

Come non citare lo slogan di Tim Berners-Lee “ROW DATA, NOW!“. Dati grezzi da trattare, che sono diventati (e diventeranno ancora) troppi e dai cui è difficile poter estrarre informazione. Un fenomeno di cui si vocifera particolarmente nell’ultimo periodo, visti gli impegni delle varie iniziative di Open Data e eGov, che “impongono” ai detentori illegittimi di dati (ndr. come pubbliche amministrazioni) di distribuire informazioni di proprietà dei cittadini.

I dati diventano “interessanti” solo se siamo capaci di estrarre da essi un contenuto utile, da trasformare in servizio per gli utenti finali.

Continua la lettura →

This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/11/26/bigdata-il-big-data-forum-2012-a-roma-le-soluzioni-ict-per-un-vantaggio-competitivo/.

[21 Novembre 2012] Big Data Forum 2012 a Roma

Postato il 17 Novembre 2012 by Fr@nk

Risposta

Big Data Forum 2012

Per fare chiarezza sul fenomeno dell’esplosione dei dati e scoprire le soluzioni ICT che consentono di trasformarlo in vantaggio competitivo

21 NOVEMBRE 2012 – ROMA

Ore 9.30 – Centro Congressi Roma Eventi – Piazza della Pilotta, 4 – Roma

Quali sono le opportunità ed i benefici derivanti dall’utilizzo di soluzioni ICT per la gestione dei Big Data?
Qual è l’impatto sulla competitività dell’impresa?
Come gestire ed analizzare dati destrutturati derivanti da fonti esterne (siti Web, social media, ecc.)?
In quali settori si stanno diffondendo maggiormente tali soluzioni?
A supporto di quali attività dell’impresa?
Quali sono le soluzioni infrastrutturali che abilitano la gestione dei Big Data?

Il 21 novembre a Roma si terrà Big Data Forum, un evento nel corso del quale si cercherà di rispondere a queste e altre domande, focalizzandosi sul contributo di alcune soluzioni ICT nel miglioramento dei processi decisionali strategici e operativi.

La capacità di analizzare un’elevata mole di informazioni – spesso non strutturati – può rappresentare per le imprese operanti in alcuni settori una chiara fonte di vantaggio competitivo e di differenziazione.

Questo perché in proporzione all’aumento di nuove tipologie di informazione come i social media e il mondo Internet of Things, caratterizzate da un ciclo di vita molto breve (basti pensare che, secondo alcune stime, il 90% dei dati utilizzati oggi dalle imprese è stato creato negli ultimi 2 anni), aumenta anche l’esigenza di gestirle dal punto di vista della velocità, della varietà e della complessità.

Per far fronte a queste esigenze, le aziende dovranno dotarsi di nuove soluzioni ICT, sia a livello infrastrutturale che applicativo, per gestire e immagazzinare un’ampia quantità di dati e migliorare le proprie capacità di analisi e di previsione.

BIG DATA FORUM, propone un confronto su queste tematiche e su quali siano le migliori soluzioni da adottare per aumentare la competitività dell’impresa.

Il sito con le informazioni sull’evento e per registrarsi: ICT4Executive

————————————————————————

Vi linko anche all’articolo che spiega bene il fenomeno: Big Data: l’infografica per capire cosa sono e perchè possono cambiare il mondo

This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/11/17/21-novembre-2012-big-data-forum-2012-a-roma/.

Francesco Ficetola

Information Engineer & IT Specialist

Archivio tag: big data

[NoSQL] Implementare un Document Store NoSQL con Oracle 12c e le SODA API

[BigData] ELK Stack: ElasticSearch + Logstash + Kibana

Protetto: [BigData&NoSQL] Log Management: un caso d’uso di Big Data e di Operational Intelligence

[Gartner] Il futuro degli Analytics: precisi, trasparenti e decisivi

[NO-SQL] Appunti su analisi di performance e comparazione dei database NoSQL

[NO-SQL] Not Only SQL: una panoramica sui database NoSQL

Wide Column Store / Column Families

Document Store

Key Value / Tuple Store

Graph Databases

Multimodel Databases

Object Databases

Grid & Cloud Database Solutions

XML Databases

Multidimensional Databases

Multivalue Database