1. Story from the Trenches using
OrientDB as main database
Luigi Dell’Aquila
OrientDB Committer
Responsabile della OrientDB Academy
Twitter: @ldellaquila
2. Cosa vi racconto?
• Progetti reali, non PoC, non “teoria”
• No Logo (NDA, sorry…)
• Alcuni buoni motivi per scegliere (o meno)
OrientDB
• Il bello dello Schema(less)
• BigData == tanti calcoli
• Mixare i layer applicativi
• Quando la logica la scrive il Cliente
3. The Big Picture
Il modello dei dati:
• Poche tipologie di dato (~10 entita’)
• Time series
• ~20.000 record BASE (input) per singolo
periodo
• Ogni record ha in media 1.500 attributi su
>50.000 possibili
• Da questi discendono le altre entita’, che
sono riaggregazioni dei dati secondo
logiche CUSTOM
4. The Big Picture
Il processo:
• Caricamento dati di N periodi
• Definizione funzioni di riaggregazione
– Matematiche
– Logiche
– Lookup
– …
• Riaggregazione dei dati in base a tali funzioni
• Reportistica dinamica su singolo periodo o su
time series
5. The Big Picture
I vincoli:
• Flessibile
– Cambia lo schema
– Cambiano le formule
• Veloce
– Riaggregazione singolo periodo in minuti
– Report in real time
8. Perchè OrientDB?
Il modello dei dati
• Ho record con 1.500 attributi (variabili)!!!
• RDBMS? Una tabella “normale” non regge:
tabella chiave-valore
• Key/Value store? La località dei dati…
• Document – Schemaless!
• (Column based? Forse…)
9. Perchè OrientDB?
Il modello di elaborazione: le formule di
riaggregazione le scrive il Cliente!
• Prima idea: DSL, ma…
– Doppio lavoro per me
– Doppio lavoro per il cliente
• Javascript!
– Non devo “inventare” un linguaggio
– Orient lo esegue nativamente
– Lo posso eseguire
• Sull’application layer
• Nel DB
– Il cliente trova tutta la documentazione che
vuole - casualmente (?) già lo conosce
10. Architettura (v. 1)
Applicazione
Storage
UI Reporting
Dominio (schemaless + metadati)
Framework
Calcolo
Factories, repositories,
Logica di front-end,
profilatura …
Funzioni JS
Schema dei dati
(metadati)
Remote
Import
11. Prima sfida: Import
L’import dei dati
• 1 periodo: 500 MB
• In Remote ci mette TROPPO!
File
500
MB
Import
Esiste?
No
Insert into…
File System Application Storage
12. Soluzione 1
Scrivo una piccola libreria che fa l’import storage level
• Lavoro in Embedded Mode
• direttamente sui Documetn
• Rinuncio alla logica applicativa “di contorno”
• Tempi 1:5
Import
Import
Application Storage
File
500
MB
nomeFile
13. Soluzione 1
Applicazione
Storage
UI Reporting
Dominio (schemaless + metadati)
Framework
Calcolo
Factories, repositories,
Logica di front-end,
profilatura …
Funzioni JS
Schema dei dati
(metadati)
Remote
Import
½ Import
14. Seconda sfida: JS
L’utente si deve scrivere le funzioni!
• Facile!
• Creo una piccola libreria js per astrarre un
po’ di concetti di dominio
• Sviluppo una maschera (simile a Studio) in
cui il cliente scrive il codice (CodeMirror) e
lo TESTA!
17. Terza sfida: Calcolo
L’import dei dati
• In Remote ci mette TROPPO!
• Mi scrivo un ½ calcolo sullo storage?
Calcolo
Select…
Data
Update…
User Application Storage
20. Soluzione
Applicazione
Storage
UI Reporting
Dominio (schemaless + metadati)
Framework
Calcolo
Factories, repositories,
Logica di front-end,
profilatura …
Funzioni JS
Schema dei dati
(metadati)
Remote
Import
Dominio (schemaless + metadati)
Framework
Calcolo
Factories, repositories,
Logica di front-end, profilatura …
Import
Funzioni di controllo
importacalcola
21. Terza sfida: Calcolo
• Deploy di un subset dell’applicazione nello
storage
• Questo layer lavorerà in Embedded Mode
• VELOCE!
• Riutilizzo TUTTO il lavoro fatto (factories,
repositories, application logic, controlli vari)
• Posso scegliere a RUN TIME dove eseguire ogni
singola operazione
• Devo creare uno strato di funzioni di controllo
per lanciare le funzionalità server-side e
ottenere i risultati (functions, ma volendo WS,
RPC ecc.)
26. OrientDB Academy
Corsi e Certificazioni
http://www.orientechnologies.com/training
Sconto del 30% per i partecipanti al Meetup sul corso
OrientDB Master Developer di giugno
Codice OrientDBSuperDiscount30
