Embedded Java database engines.

Negli ultimi due mesi sto conducendo un lavoro di scouting su tecnologie adattabili al nostro modello dati per un problema in esercizio.

Quando sono entrato nel team di sviluppo il modello dati era ormai ampiamente implementato e collaudato, ma cominciava a mostrare il fianco soprattutto per una non corretta valutazione delle risorse necessarie al suo uso in esercizio e al target operativo.

Lo strumento utilizzato in questo momento è EMF.

Come cita la pagina di presentazione:

EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose….


Oltre a queste utilissime funzioni di generazione automatica del codice senza cui nessun programmatore riuscirebbe a vivere….:) EMF offre anche un vero e proprio framework per il modello dati in termini di inserimento, ricerca cancellazione… e una modalità di persistenza del modello dati su file system.

Il problema nasce dal fatto che per offrire tutte queste funzionalità EMF pesa molto in termini di RAM.

Per fare un esempio il nostro modello dati diciamo che rappresenta dei dispositivi di telecomunicazione (dei DSLAM come ben sa ormai chi mi conosce…) e con con l'attuale configurazione riusciamo a gestire circa 100 dispositivi per blade (server dual processor con 4 GB di ram); visto che a pieno regime ci sono circa 10000 dispositivi sul territorio questo vorrebbe dire 100 blade da circa 3000 dispositivi l'una che inesorabilmente porta a 300000 euro di sola ferraglia….. un pò troppo visto il nostro budget…

Era indispensabile cambiare tecnologia per il modello dati, e per questo sono stati esaminati prodotti appartenenti a diverse famiglie:

  1. RDBMS di tipo tradizionale (i.e. Oracle Database).
  2. In-memory database (i.e. TimesTen).
  3. Embedded database engines in Java (i.e. Berkeley DB Java Edition).

Io mi sono occupato dello studio della terza tipologia di prodotti, prendendo in considerazione Hypersonic SQL, H2 Database, Mckoy SQL Database, Apache Derby e Berkeley DB JE.

I nostri requirement sono:

  1. Gestione trasparenete della ram (memoria per il framework configurabile).
  2. Scalabilità e performance nelle operazioni CRUD.
  3. Politica transazionale di tipo ACID.
  4. Salvataggio dei dati in locale.

Hypersonic si è dimostrato poco performante per i nostri impieghi, H2 molto performante ma con soluzioni solo in-memory o solo on-disk, Derby ancora non offre nessuna feature in-memory e Mckoy ha rilasciato nel 2004 la versione 1.0.3 come una ultima release, un pò datato e indice di nessun ulteriore sviluppo.

Berkeley DB JE invece mi è piaciuto da subito: non offre nessuna interfaccia SQL e non implementa un modello relazionale, ma offre una serie di API per la persistenza molto intuitive e molto flessibili adatte agli sviluppatori; permette di definire la persistenza di oggetti del modello dati tramite le annotation, così come le relazioni di contenimento piuttosto che i constraint. Il suo runtime coincide con quello dell'applicazione e si appoggia a un file system locale per la persistenza dei dati.

Gestisce le transazioni, ha elevate performance e permette di configurare la ram utilizzata per il suo environment, usando il disco quando necessario per swappare.

Insomma proprio quello che cercavamo🙂

Non per niente Sleepycat (l'azienda che lo ha svilppato) è stata recentemente comprata da Oracle.

Unico neo è che è rilasciato con un doppia licenza, GPL e commerciale senza bisogno di rilasciare il codice: stiamo aspettando un preventivo per capire la portata della spesa, ma visto che ormai è un prodotto Oracle non ci aspettiamo niente di economico.

Nel caso qualcuno ne avesse bisogno, durante le mie ricerche mi sono imbattuto in questo bell' elenco di database engines open source scritti Java.

Mazi

2 Responses

  1. Tieni conto che Oracle una volta aveva una politica di pricing (una cosa tipo Oracle Embedded) per cui se utilizzi un prodotto Oracle all’interno di un prodotto, la licenza è gratis.

    Non so se questa politica esista ancora e quali siano le limitazioni in termini di prodotto.

    Il grosso vincolo è che devi sviluppare un prodotto, qualcosa che sia vendibile commercialmente.

  2. Sleepycat prevede due tipi di licenze commerciali: user license o processor license.

    Non si capisce bene ora che è stata comprata da Oracle se manterranno questa politica oppure se cambieranno strada.
    Sta di fato che ancora recentemente Berkeley DB non risulta nell’elenco della pricing list dei prodotti Oracle.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: