OrientDB & Big Data

1,804 views

Published on

BigData & Graphs in Rome
OrientDB & Big Data: storie di vita vissuta
Da un caso di successo a un futuro che “spacca”

Un backstage di un caso di successo con un occhio critico ai problemi avuti, ma con la consapevolezza di un futuro brillante.

Il riassunto della nascita di una suite di business intelligence.

By Luca Bianconi
@LucaBianconi74

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,804
On SlideShare
0
From Embeds
0
Number of Embeds
32
Actions
Shares
0
Downloads
23
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

OrientDB & Big Data

  1. 1. OrientDB & Big Data: storie di vita vissuta Da un caso di successo a un futuro che “spacca” BigData & Graphs in Rome
  2. 2. Luca Bianconi Senior Consultant Partner Italiano di Orient Technologies UK 2
  3. 3. Un po’ di storia • Nata nel 2004 come technological company di AssetManagement, AssetData si impone sin da subito come leader in Italia per lo sviluppo e l’integrazione delle tecnologie open source più innovative ed evolute: – Java – Roma<Meta>Framework – AngularJS – OrientDB • Ha partecipato a diversi progetti per lo sviluppo e la diffusione di software open source con il supporto della Comunità Europea • Leader nello sviluppo di soluzioni HR • Acquisita nel 2012 da leader nel settore della somministrazione di lavoro (fatturato internazionale >> € 800M) 3
  4. 4. La nuova direzione Trick StressCorrelato SKY Apprendistato 4
  5. 5. La richiesta Sviluppare un sistema di BI (real time) per le VLT di una famosa società italiana di gaming 5
  6. 6. Cosa sono le VLT Video Lottery Terminal 6
  7. 7. Il mondo delle VLT • Fornitori: Gtech, Novomatic, etc. • Concessionari: Lottomatica, SNAI, SISAL, etc. • Macchine: VLT, AWP, etc. • Distribuzione geografica: Aree, Regioni, Province, …, Sale • Granularità dati: Sala, Gioco, VLT • Frequenza dati: singola giocata o giornaliera 7
  8. 8. Qualche numero • 5.000 Sale • 40.000 VLT • 30 Giochi • 10 Concessionari • 9 Flussi di dati a concessionario • > 60.000.000 di record al giorno per le concessionarie più grandi 8
  9. 9. Cosa abbiamo trovato • DB2 • 4 ore per l’estrazione dei file di un singolo concessionario (size = 2.5GB) • Excel e Access • 3 persone full x analizzare i dati • Centinaia di mail a settimana per il board • Dati destrutturati… 9
  10. 10. Esigenze • BIG DATA – MILIARDI DI RECORD • PERFORMANCE – TEMPI DI RISPOSTA IMMEDIATI • WEB BASED – RAGGIUNGIBILE DA INTRANET/INTERNET • GESTIONE UTENTI – PROFILAZIONE RUOLI • REPORT, GRAFICI E DATI MODIFICABILI – ALTA INTERATTIVITA’ 10
  11. 11. L’implementazione Serve un multi-model graph database! 11
  12. 12. C’è tanto da fare Ok abbiamo il DB: Orient 1.3. E adesso? 12
  13. 13. Da Orient a OrientBI CSV ETL (Java) OrientDB Istruzioni in JS Front end e Back end Html + JS + Bootstrap Command + JS Report Orient Processing LAnguage JSON JSON JS (orientdb-bi) 13
  14. 14. Architettura finale PLATFORM 1 … PLATFORM 2 PLATFORM 4 OrientBI GRAFICI REPORT SCHEDE MODIFICABILI PLATFORM 3 14
  15. 15. La lista della spesa •ETL •Back end •Front end •Report •Applicazione 15
  16. 16. ETL parte 1 • I file si trovano all’interno di una cartella denominata ‘’template’’ • I file hanno estensione: *.template • Nel file orientdb-server-config.xml c’è il seguente codice relativo all’etl: ……………………………. 16
  17. 17. ETL parte 2 ‘’HEADER’’ @class Sala [@save disabled] @field sistema link @join Sistema.id_sistema_aams @field seriale_vlt string @trim @field codice_aams string @index @field regione skip @field metri_quadri integer @field data_estrazione date @format MM/dd/yyyy @index Sala.sistema_seriale UNIQUE sistema seriale_vlt 17
  18. 18. ETL parte 2 ‘’BODY’’ @onBeforeFile {{{ … }}} @onBeforeLine {{{ @onAfterFile {{{ @onAfterLine {{{ … [record.save();] }}} 18
  19. 19. ETL e linguaggi • Rhino • Se viene utilizzato Java 8 il motore sarà Nashorn – Prestazioni equiparabili a Google V8 19
  20. 20. ETL esempi di codice 1 @onBeforeLine {{{ var record = task.getVariable("currentRecord"); var lastDate = task.getVariable("lastDate" ); var currentDate = record.field("data_contabile"); if( lastDate == null || !lastDate.equals( currentDate ) ) { var deleted = db.command("delete from DatiContabiliVLTGioco where data_contabile = ? and sistema = ?", currentDate, sistema); task.setVariable("lastDate", currentDate ); } }}} 20
  21. 21. ETL esempi di codice 2 // GROUP MONTLY DATA var dayOfTheMonth = finalDate.get(java.util.Calendar.DAY_OF_MONTH); var firstOfMonth = Packages.com.orientechnologies.orient.core.util. ODateHelper.getDatabaseCalendar(); … groupDatiSala(firstOfMonth.getTime(), maxDate, "DatiContabiliSala_mese", sistema); 21
  22. 22. 1° POC • >> 1000 rec/sec • Ok ‘’It works!’’ • Come vedo se ha importato i dati? • La console è scomoda… usa Studio! 22
  23. 23. Il primo Studio 23
  24. 24. Il secondo Studio 24
  25. 25. Boe dammi una Duff! 25
  26. 26. E’ sufficiente? • 120.000.000 (record) ÷ 1.200 (record/secondo) • + o - fanno 28 ore… • E il real time? Darvaza Turkmenistan Porta dell’inferno 26
  27. 27. La soluzione Dove non arriva JS arriva Java Modifica dell’header del template e implementazione dell’import in Java @class GiocateOrarie @implementation it.assetdata.customer.bi.listener.GiocateOrarieImp orterListener 27
  28. 28. Pericolo scampato • Risultato = 25.000 r/s (1h e ½ per l’import) 28
  29. 29. Front end • I dati ci sono • Visualizziamoli 29
  30. 30. Come è strutturata una pagina Menu di selezione sale Menu di selezione temporale Pulsanti di esecuzione, schedulazione, etc. [Sezione relativa ai grafici] Creazione variabili Invio contestualizzato variabili Funzioni specifiche Menu Risultati Codice 30
  31. 31. Un report tipo function renderProvince() { var concessionarie = $("#concessionarie").val(); var aree = $("#aree").val(); var regioni = $("#regioni").val(); var optionsProvince = "<option value='undefined'></option>"; queryResult = db.executeFunction('province', [ concessionarie, regioni, aree ]); for ( var r in queryResult.result) { optionsProvince += '<option value="' + queryResult.result[r].provincia + '">' + queryResult.result[r].provincia + '</option>'; } $('#province').html(optionsProvince); renderCitta(); } 31
  32. 32. Le OFunction 32
  33. 33. Come viene generato un report queryResult = db.process('conc8', [ year, month, week, day, conc, regioni, pv, citta, sale, aree ], function(result) { $('#content').html(processResult(result.result[0], {})); }, function() { showErrorMessage(orientServer.getErrorMessage()); }); 33
  34. 34. Orient Processing LAnguage: OPLA • Cosè OPLA? • Creato nel 2012 per essere integrato in Orient • E’ un JSON • E’ un linguaggio di interrogazione del server in maniera strutturata • Potente, semplice e leggero 34
  35. 35. Alcuni elementi di OPLA 1 • Comprende 8 tipi di blocchi: – Execute – Let – Output – Table – Function – Query – Script – Iterate 35
  36. 36. Alcuni elementi di OPLA 2 • Inizio tipico { "type" : "execute", "do" : [{ … 36
  37. 37. Struttura di report Ricezione delle variabili Assegnazione del nome dei campi [Customizzazione del nome dei campi] Let Output Header Body Execute Do Function Esecuzione OFunction Query Esecuzione query Function Formattazione campi Script Esecuzione IstruzioniEnd Output Esecuzione OFunctionFooter 37
  38. 38. Acquisizione variabili { "type" : "execute", "do" : [{ "type" : "let", "value" : { "debugMode" : "false", "da" : "${arg0}", "a" : "${arg1}", "range" : "${arg2}" 38
  39. 39. Esecuzione OFunction { "type" : "function", "function" : "getClassName", "args" : [ "DatiContabiliSala", null, "${range}" ], "return" : "className" } 39
  40. 40. Esecuzione query { "type":"query", "target":"${className}", "fields":[ "data_contabile", "' ' as cipupd", "count( distinct( vlt ) ) as macchine_giocanti" ], "groupBy":"data_contabile", "filter":" data_contabile between ${da} and ${a} ${filterByZone}", "return":"macchineGiocanti" } 40
  41. 41. Altre applicazioni di let { "type" : "let", "if" : "${typologyReportResult[2]} > 0 ", "target" : "${current}", "value" : { "cipupd" : "={ if( ( ${typologyReportResult[1]} <> 0 ), eval(' ${current.cash_in} / ${typologyReportResult[0]}'), '' ) }" } } 41
  42. 42. OPLA e altri linguaggi ], "end" : { "type":"script", "language":"Javascript", "code":" var actualPeriod = ctx.getVariable('$root.$actualPeriod'); if( actualPeriod != null && !actualPeriod.equals('undefined') ){ var block = ctx.getVariable('$root.$block'); var result = block.getParentBlock().getReturnValue(); if( result.size() > 0 ){ 42
  43. 43. Un ultimo passaggio • Il JSON viene processato dalla funzione processResult della libreria orientdb-bi • Verranno formattati header, body e footer orientdb-bi 43
  44. 44. Il risultato 44
  45. 45. App: Archivio Commerciale • Esigenza: informatizzare le visite delle sale • Soluzione: OrientBI – Command – JS – JQueryUI Scheda Sala Upload/Download file e foto Aggiornamento DB 45
  46. 46. Come si presenta 46
  47. 47. Qualche dettaglio 47
  48. 48. Come si salvano i dati rootObject = { "@type" : "d", "@class" : "VisiteSala", "sala" : ridSala, "data" : dataUTC, "esercente" : esercente, ... "vlt_piattaforma" : vlt_piattaforma }; rootObject = db.save(rootObject); if (db.getErrorMessage() == null) { visitaList(ridSala); } else alert(db.getErrorMessage()); 48
  49. 49. Alcuni dati salvati EmbeddedMap Collection 49
  50. 50. E le storie di vita vissuta? • Local • Indici • Backup • OPLA & Debug • SNAPSHOT • Aggregazioni 50
  51. 51. Robustezza(…) e velocità Orient 1.4 = Local + MVRB-Tree 51
  52. 52. Quali inconvenienti? • Riavvio improvviso della macchina: – Ricostruzione degli indici – Possibili record corrotti (tipicamente si danneggia la tabella di allocazione dei record sul disco risultando enormi >> 1GB) • Riavvio normale del server Orient: – Possibile flush non completo su disco (prevalentamente con il kill del processo) • Possibili record danneggiati • Possibili indici inaffidabili • In sostanza i normali problemi del Memory Mapping! 52
  53. 53. Come correggere i danni? Come si ricostruisce una città dopo il passaggio di Godzilla? Solo avendo una città di backup! 53
  54. 54. Ripristino dei dati • Il backup è affidabile? – Se il db è integro si – E’ lento (di fatto è un processo di export e import) – E’ estremamente lento in caso di record corrotti 54
  55. 55. OPLA & Debug • NON esiste • Si passa per i breakpoint su IDE… • C’è un poc realizzato da @ldellaquila di una versione OrientBI 2.0 dove è possibile impostare i breakpoint sui blocchi OPLA da IDE web 55
  56. 56. Quando sarà rilasciato? • Solo lui ci può rispondere… 56
  57. 57. Dalla 1.4 alla 1.7 • Local vs Plocal • Wal • MVRB-Tree vs SBTree, Hash & Lucene • Backup migliorato • Clustering multimaster • Sharding • Lucene • … • Più funzionalità • Più stabilità 57
  58. 58. Come è andata? 58
  59. 59. Tutto ok? • Gli indici non sono ancora dentro il WAL • Con grandi db la ricostruzione è lenta (anche 11 ore!) • Nel caso di indici compositi se nella query non è presente la prima property non avremo nessun risultato (usare più indici) • Parser sql… • Ottimizzatore query non sempre ottimizza… • Complessa la parte di debug (explain, yourkit*, etc…) • Serializzazione… 59
  60. 60. RoadMap 2.0 60 • Protocollo binario (3x – 20x) • Indici nel WAL • Improvement Multicore • Visualizzazione dei grafi su Studio • Altro…
  61. 61. Per il futuro? 61
  62. 62. Lavorare con le SNAPSHOT • Perché? – Per avere sempre l’ultima versione – Per avere subito delle modifiche ad hoc utilizzando solo GIT • Perché no? (tutto quello che è successo e nessuno lo ha mai detto…) – Perché all’improvviso chiunque potrebbe inserire una feature che non permette più di aprire il db – Perché all’improvviso si potrebbe rendere necessario esportare e importare tutto – Perché all’improvviso alcune convenzioni potrebbero cambiare in maniera sostanziale – Perché all’improvviso i nuovi indici potrebbero non essere più affidabili – Perché i sistemi di debug potrebbero non funzionare* – Perché non si dovrebbe fare e basta! 62
  63. 63. Sinergie • Lavorare con le SNAPSHOT permette una scoperta e una soluzione dei bug molto rapida (con il team di Orient) • Gli indici sono migliorati in maniera importante (la ricostruzione è passata da 300 r/s a 20.000 r/s senza più heap dump) • Sono state aggiunte molte nuove funzionalità 63
  64. 64. Le aggregazioni • Nuova richiesta: velocizzare il report più usato • Visualizza tutti i giorni, settimane, mese e anni presenti sul db (a seconda della scelta) • Raggruppa ogni volta real time • Esegue e unisce i risultati delle query eseguite su 2 classi: da 2.000.000 e da 8.000.000 di record • I raggruppamenti settimanali e mensili sono i più usati 64
  65. 65. BI = Aggregazioni • Una soluzione è creare altre classi che gestiscono i dati aggregati. • Vantaggi: – Facile implementazione (OFunction in fase di import) – Pochi dati da gestire • Svantaggi: – Problemi di coerenza da una classe all’altra – Moltiplicazione degli indici 65
  66. 66. Dov’è la parte graph? • Nei flussi che contengono tutte le transazioni è stato seguito un approcio diverso: legare le date ad un grafo temporale Anno Mese Settimana Giorno Ora Minuti Secondi Record Record Record 66
  67. 67. Meglio degli indici? • Gli indici sono un albero bilanciato (che è un tipo di grafo), quindi sono quasi equivalenti • Performance sulle aggregazioni non accettabili (su classi da centinaia di milioni di dati) • Perché è stato sviluppato? • Per sopperire agli indici allora immaturi 67
  68. 68. Come ottimizzare le ricerche Anno Mese Settimana Giorno Ora Minuti Secondi RecordRecord Record Aggr AggrAggrAggr Aggr AggrAggr n x 12 n Aggr 68
  69. 69. Quante dimensioni? • Tipicamente temporale o temporale x territoriale • Limite = n 69
  70. 70. Tutto rose e fiori? • Punti di attenzione: – Dimensioni del db – Transazionalità delle aggregazioni per evitare inconsistenza da un livello più basso ad uno più alto – E’ più efficiente del connubio indici x classi? Probabilmente no! 70
  71. 71. Quando è più indicato il graph? • Utilizzare il grafo quando il costo di aggregazione è maggiore di quello di ricerca out().in() 71
  72. 72. Continueremo ad usare Orient? • Si perché: – In molti casi offre notevoli vantaggi rispetto ad un relazionale e rispetto alla concorrenza – Perché la 1.7 è un prodotto maturo e la 2.0 sarà ancora più performante – Perché se il cliente cambia i requisiti dopo 18 mesi in produzione con poco effort si può cambiare un’applicazione  72
  73. 73. Feedback Insomma parafrasando Edward Norton ‘’Orient spacca!’’ 73
  74. 74. Grazie luca.bianconi@assetdata.it
  75. 75. #AssetCercaCollaboratori jobs@assetdata.it 75

×