database

Effettuare query tramite i criteria sugli elementi hasMany di una classe Grails

Nei giorni scorsi mi è capitato di dover scrivere la logica con cui in un controller Grails venivano recuperati determinati record corrispondenti ad altrettanti oggetti di una certa classe di dominio tramite i criteria. L’oggetto A in questione, semplificando per concentrarci sull’esempio, era fatto in questo modo :

class A {
    String a1
    String a2
    hasMany = [bs : B]
}
class B {
    Integer b1
    String b2
}

L’oggetto A così dichiarato ha una relazione 0..N con l’oggetto B, indicato nella classe di dominio tramite il classico costrutto hasMany di Grails.

Il mio obiettivo era il seguente: estrarre da database tutti gli elementi di tipo A relazionati ad almeno un oggetto di tipo B, utilizzando i criteria.

Read More…

Passare da Mysql a MongoDB: un esempio pratico

Uno degli obiettivi tecnici che mi sono dato per questo 2011 è quello di avvicinarmi al mondo dei database NoSQL, sigla che indica l’insieme di database che non necessitano la costruzione di legami relazionali per archiviare i dati, adottando una filosofia orientata a quella che viene definita memorizzazione strutturata. A differenza di quanto possa far pensare il nome, l’SQL non è assente in questi database, quello che manca sono dei rigidi vincoli relazionali.

Questo tipo di scelta porta una serie di benefici alle nostre applicazioni, identificabili schematicamente nei seguenti:

  • nessuno schema predefinito a cui rimanere vincolati, soprattutto al crescere della complessità;
  • maggiore scalabilità
  • maggiore availability (scusate, ma in italiano disponibilità non rende l’idea)

Read More…

Come ottimizzare mysql server con il tuning

Riprendo e sintetizzo in italiano l’articolo “What to tune in MySQL Server after installation” del blog www.mysqlperformanceblog.com, un sito davvero interessante curato nei contenuti dagli autori del libro “High performance MySQL”.

Il file di configurazione di Mysql offre la possibilità di gestire molte variabili, che permettono di configurare un database ottimizzato per le esigenze di chi lo utilizza, anche in base all’hardware che si dispone sulla macchina che ospita il db.

Vediamo le principali:

  • key_buffer_size – Questa proprietà ha valore con tabelle di tipo MyISAM e, se si usano solo questa tipologia di tabelle, si consiglia di settarla al 30-40% della memoria disponibile. Bisogna infatti ricordarsi che MyISAM usa la cache del sistema operativo per memorizzare i dati e quindi bisogna far bene le proprie valutazione nello scegliere il valore da assegnare a questa variabile, il calcolo va fatto soprattutto in base alla quantità di indici e dati per evitare di sottrarre troppe risorse al sistema operativo stesso. Il valore minimo consigliato per ottenere risultati decenti è comunque sui 16-32MB.
  • innodb_buffer_pool_size – Questa proprietà è molto importante utilizzando tabelle di tipo InnoDB. Utilizzando InnoDB dati e indici vengono memorizzati dal pool, quindi si può pensare di portare al 70-80% questa proprietà. E’ inoltre consigliato di non superare i 2-3,5 GB sulle macchine a 32bit, perchè sopra una certa soglia il rendimento non aumenta.
  • innodb_additional_mem_pool_size – Questa proprietà pare non influire moltissimo sulle performance, si consiglia un valore massimo di 20MB o poco più (il default è 2MB).
  • innodb_log_file_size – Questa proprietà definisce la grandezza massima del file di log per tabelle InnoDB. Pur essendo vero che maggiore è la dimensione, migliori sono le prestazioni, è anche vero che bisogna fare i conti con le dimensioni del server. A seconda di tale considerazione si consiglia un tuning di questa variabile tra i 64 e i 512MB.
  • innodb_log_buffer_size – Il default per questa variabile è 1MB e per sistemi con poche trasnizioni ed un traffico medio potrebbe bastare. Non va settato un valore troppo alto perchè è il buffer è flushato ogni secondo ed esagerare significherebbe sprecare memoria. Solitamente sono più che sufficienti 8-16 MB.
  • innodb_flush_log_at_trx_commit – Se sembra che InnoDB sia più lento di MyISAM è possibile che questo valore sia stato configurato male. Il default (1) significa che ad ogni commit di una transizione (o statement fuori dalla stessa) necessita di fare flush del log su disco, un’operazione piuttosto costosa se molto frequente. Settare il valore a 2 significa fare il flush del log solo tramite cache del sistema operativo. Il valore 0 è più veloce, ma è rischioso perchè si possono perdere dati durante le transizioni nel caso di un crash di MySQL Server. Anche il valore 2 è rischioso se il sistema operativo va in crash.
  • table_cache – Aprire tabelle è costoso e per mantenere tabelle in memoria è utile avere una cache abbastanza spaziosa. 1024 MB è un buon valore se si ha un sistema sotto le 200 tabelle, ricordandosi sempre che ogni connessione si porta via la propria quantità di memoria.
  • thread_cache – La creazione e distruzione di thread è dispendiosa e avviene ad ogni connessione e disconnessione dal db. Il valore consigliato è di almeno 16, con l’obbiettivo di non avere crezione di thread durante le normali operazioni.
  • query_cache_size – Utile per applicazioni con molti dati in lettura. Valori compresi tra i 32 e i 512 MB sono i migliori, a seconda della potenza della vostra macchina.

Al momento in cui scrivo le considerazioni valgono per MySQL Server 5 (io le ho provate su MySQL Server 5.1) e sono comunque suggerimenti da utilizzare con criterio e in base alle possibilità della propria macchina.

E’ necessario rammentare infatti che queste appena descritte sono tutte variabili definite a livello globale, quindi ragionate bene sulle disponibilità della vostra macchina e sulle necessità delle applicazioni che ci gireranno sopra prima di esagerare, rischiando di peggiorare le performance.
A voi la responsabilità delle vostre.. configurazioni. :)

Oracle compra Sun: ergo acquista Solaris, Java e Mysql

Oracle compra SunOracle, il gigante americano dell’omonimo database, compra per circa 7,4 miliardi di dollari Sun Microsystem, azienda della Sylicon Valley che produce software, semiconduttori e altro ancora. Cosa significa questo acquisto per il mondo dell’Information Technology? Significa che Oracle (sconfiggendo IBM, altro possibile acquirente della società californiana) ha comprato Solaris, Java e Mysql. Un affarone e vediamo perchè.

Solaris: un sistema operativo con “migliaia di applicazioni software di terze parti a disposizione, supporto dai cicli di vita superiori a 10 anni, per implementazioni stabili e a lungo termine, aggiornamenti per le installazioni di Solaris già esistenti, offerte di supporto impareggiabili per le aziende”, da sempre ben integrato col database Oracle e in competizione (seppure relativamente flebile) con Windows e Linux.

Java: uno dei linguaggi di programmazione più diffusi al mondo, utilizzato da sempre con enorme successo lato server e non (e negli ultimi anni anche per la creazione di RIA), con cui Oracle stessa ha costruito buona parte delle sue applicazione middleware e da poco supportato da Google App Engine.

Mysql: il database più diffuso tra quelli dalla versione opensource, grande rivale di Oracle, comprato da Sun per un miliardo di dollari lo scorso anno. Tutti si chiedono che fine farà, anche se è probabile che non sparirà dalla circolazione, soprattutto per via della sua elevatissima diffusione. Il supporto commerciale continuerà indubbiamente ma è facile pensare che, anche se con risorse limitate, continuerà anche l’approccio open source.

Oracle è adesso in grado di fornire un pacchetto davvero completo alle aziende clienti. Chi lo fermerà?

1 2  Scroll to top