HyperSQL è un programma che vi consente di analizzare meglio come utilizzate il vostro database.

Il programma è una specie di misto fra doxygen e javadoc per SQL. Può mappare viste, procedure e funzioni e generare pagine html in cui è possibile navigare per capire meglio le relazioni.

Può anche elaborare codice C++ e Java. È scritto in Python ed è rilasciato sotto licenza GPL. Se siete interessati potete dare un’occhiata al demo messo a disposizione dagli sviluppatori.

Via | Izzysoft

Uno dei tentativi di “cracking” più diffusi per i siti web riguarda l’inserimento di codice “maligno” a livello di database, una pratica nota come SQL Injection per quanto riguarda i DBMS basati appunto sul linguaggio SQL: fortunatamente esistono diversi strumenti atti a identificare e rimuovere le intrusioni — uno di questi è sqlmap, scritto in Python.

Tra gli aspetti più apprezzabili di sqlmap (distribuito sotto licenza GPLv2) c’è la documentazione – arricchita d’interessanti digressioni sul tema dell’SQL Injection – che è davvero completa e corredata di video esplicativi. Oltre al download dei sorgenti sono disponibili pacchetti precompilati in formato .DEB ed .RPM oltre a un eseguibile per Windows.

Il supporto di sqlmap – di recente giunto alla versione 0.8 – ai database esistenti sembra non dimenticare proprio nessuno: si parla infatti di MySQL, Oracle, PostgreSQL e Microsoft SQL Server cui si aggiunge la possibilità di monitorare Microsoft Access, DB2, Informix, Sybase e Interbase. Un tool che ogni DBA dovrebbe tenere d’occhio.

Forse non tutti sanno che il progetto è stato lanciato da un noto programmatore italiano, Salvatore ‘antirez’ Sanfilippo, che qualcuno di voi potrebbe già conoscere per altri suoi lavori come HPing o Lloogg. Lo abbiamo contattato affinché ci descrivesse meglio il funzionamento e le caratteristiche di Redis.

Presentati e prova ad illustrare Redis e la sua architettura per il pubblico che ancora non lo conosce.

Redis è un database un pò bizzarro, rispetto ai canoni a cui siamo abituati, per due motivi principali:

1) Tiene tutti i dati in memoria anche se persiste sul disco. In pratica il disco serve solo nel caso in cui il database viene fermato e riavviato, a leggere nuovamente tutto il data set in memoria. Ma tutti gli accessi in lettura e scrittura vengono gestiti principalmente in RAM. Questo permette ad un singolo server Redis che gira su una macchina Linux normalissima, su un solo core, di raggiungere l’interessante prestazione di 100 mila query al secondo. Cosa più interessante le query in lettura e scrittura prendono lo stesso tempo.

2) Le operazioni che supporta sono molto diverse da quelle di un database SQL. Non c’è il concetto di tabella, e non è un semplice database Key-Value a cui si associa ad una stringa (la chiave) un’altra stringa (il valore). Infatti i valori possono essere di altri tipi, come liste, insiemi, insiemi ordinati, o semplicemente stringhe.

L’idea di mantenere tutto il dataset in RAM aiuta a migliorare le prestazioni, ma cosa succede quando la memoria non è sufficiente?

L’idea di mantenere tutto il dataset in RAM aiuta a migliorare le prestazioni, ma cosa succede quando la memoria non è sufficiente?

Nella versione stabile di Redis non c’è modo di andare oltre la RAM. Al massimo Redis può essere configurato per non accettare nuovi dati quando ha utilizzato più di un dato limite di memoria, o di tentare di cancellare le chiavi “volatili” in tal caso per fare spazio alle altre (una chiave volatile è una chiave associata ad un EXPIRE in secondi, poiché Redis supporta l’auto cancellazione delle chiavi dopo tot secondi).

Ma la svolta da questo punto di vista è nella versione non stabile, dentro Git. Si tratta della funzionalità denominata “Virtual Memory”. In pratica Redis implementa un file di swap su cui scarica le chiavi meno usate automaticamente. Se il database supera la dimensione della RAM, tutte le chiavi che sono usate meno spesso vengono trasferite sul disco, per essere ritrasferite indietro in memoria quando saranno nuovamente richieste.

Siccome molte applicazioni sono “sbilanciate” nell’accesso ai dati, ed accedono molto frequentemente ad una piccola percentuale di chiavi, in molti casi le prestazioni di Redis rimangono simili a quelle che esprime quando tutte le chiavi sono in memoria.

La Virtual Memory è già abbastanza stabile e può essere testata. Ho scritto un lungo articolo qui a proposito del suo funzionamento: http://antirez.com/post/redis-virtual-memory-story.html

Tra i piani per il futuro c’è l’opzione di implementare una memoria virtuale. Potresti spiegarci i vantaggi di questo approccio rispetto al lasciar fare tutto al sistema operativo?

Esatto, ho appena parlato di questo. Perché non si può lasciar fare al sistema operativo?

È più semplice di quello che sembra. Il sistema operativo trasferisce o carica dallo swap delle “pagine” di memoria che sono grandi 4096 byte. Redis utilizza delle strutture molti piccole, anche per valori grossi. Ad esempio una lista di Redis, è composta da tanti piccoli Redis Objects. Non solo, il dizionario principale è implementato tramite una hash table, che è una struttura dati ad accesso “molto” casuale. In pratica nella stessa pagina di memoria ci finiscono dati relativi a decine o centinaia di chiavi: se anche una sola chiave è attiva, questa pagina non può essere trasferita su disco.

Per cui la memoria virtuale del sistema operativo funziona malissimo con Redis. C’è un altro motivo importante: in memoria i dati di Redis occupano molto più spazio rispetto a quello occupato dallo stesso dato codificato su disco da Redis. La memoria virtual del sistema operativo non ha idea di cosa ci sia dentro le pagine di memoria, e le trasferisce dal/al disco così come sono. Invece la memoria virtuale di Redis ha più informazioni, e codifica e comprime i valori trasferiti, per cui esegue molto meno input/output sul disco a parità di necessità di swapping.

Come vengono sfruttate la macchine multicpu/multicore e la distribuzione del dataset su più computer?

Attualmente ci sono due modi per sfruttarle: o far girare più istanze di Redis sulla stessa macchina, o usare la Virtual Memory che ha una implementazione basata sui thread, per cui anche se Redis è “single threaded” cioè opera su un singolo thread grazie ad una tecnica chiamata “multiplexing”, la Virtual Memory si avvale di diversi thread (configurabile) in modo da non bloccare gli altri client quando un client ha la necessità di accedere ai dati che sono sul disco.

Redis è un progetto che si discosta dal tradizionale modello relazionale. Su cosa punteresti per invogliare gli utenti a provarlo?

Faccio un esempio banale. Per implementare su MySQL un sistema semplicissimo di commenti dove ogni nuovo commento sta in cima alla pagina (ad esempio nel caso di un blog), su MySQL devo creare una tabella, mettere l’ID del post, e usare ORDER BY anche se tutto ciò che voglio è prendere i commenti nello stesso ordine in cui li ho inseriti o nell’ordine inverso.

Su Redis invece tutto quello che devo fare è, per ogni commento:

LPUSH post:100:comments

LPUSH aggiunge alla testa della lista contenuta nella chiave “post:100:comments” (dove 100 è un esempio di ID del post).

Per prendere i primi 10 commenti in ordine inverso nel quale li ho postati, mi basta scrivere:

LRANGE post:100:comments 0 9

Quale tipo di progetto potrebbe beneficiare maggiormente dall’uso di Redis al posto di un dbms relazionale?

I progetti che hanno grandi traffici, o dove i dati sono sistemati in modo da necessitare operazioni atomiche. Ad esempio Redis supporta intersezioni tra i set, per cui è facile implementare un sistema di tag. Allo stesso modo è facilissimo implementare una “score board” con i sorted set. In pratica si inseriscono in Redis dei valori che hanno un dato punteggio: anche con milioni di dati Redis inserirà questi dati in O(log(N)) ma con tempi costanti davvero bassi.

Questi dati sono inseriti in maniera ordinata, dunque posso chiedere a Redis: quali sono i primi 10 elementi di questo sorted set? (simile a SELECT * FROM
table ORDER BY score LIMIT 0 10), o posso chiedere a Redis di darmi tutti gli elementi in cui lo score è compreso tra due valori. Queste operazioni sono molto veloci, per cui più di una azienda di videogame sta usando Redis per gestire i punteggi degli utenti, ad esempio di giochi online molto trafficati.

Quali sono i siti più importanti che utilizzano Redis nel loro backend?

http://engineyard.com
http://github.com
L’applicazione “Boxcar” per iPhone, molto famosa per le notifiche push

Sono alcuni esempi di grosse applicazioni, ma ci sono centinaia di startup che stanno usando Redis in produzione.

Recentemente Redis è arrivato alla versione 1.2 che introduce la nuova modalità di persistenza “append only file”. Ci puoi descrivere il funzionamento e come possono cambiare le prestazioni?

In pratica normalmente Redis salva i dati su un file, di tanto in tanto (in maniera configurabile, ad esempio salva ogni 60 secondi se sono cambiati almeno 5 dati in memoria). Questo è molto veloce e viene fatto da un processo “figlio” in parallelo, ma se la macchina si spegne perché ad esempio c’è un problema con la corrente elettrica, si rischia di perdere gli ultimi 60 secondi di dati.

Con l’Append Only File invece Redis scrive su disco, in un file sequenziale, tutte le operazioni di scrittura che riceve, istantaneamente. Quando viene fatto ripartire, rilegge tali operazioni di scrittura come se le ricevesse dai client, per ricostruire lo stato dei dati in memoria. Questo log però diventa sempre più lungo, ma Redis sa compattarlo in backrground, senza bloccare le richieste che arrivano dai dati.

Le prestazioni sono molto buone anche con l’Append Only File, ma dipende molto da come è configurato Redis, infatti può chiedere al sistema operativo di fare il “flush” dei dati ogni secondo, di lasciar fare al sistema operativo, o di farla ad ogni singola scrittura. Nell’ultimo caso Redis diventa lento ma estremamente “durabile” (molto più di MySQL ad esempio), ogni operazione viene trasferita sul disco prima possibile. Questo va bene per applicazioni finanziarie magari, ma non è una buona idea.

Quando è configurato per fare il flush ogni secondo (scelta consigliata) è quasi veloce come quando l’append only file è disabilitato.

Sul sito sono presenti progetti per usare redis con più di 10 linguaggi, qual è il loro grado di maturità?

Alcuni sono estremamente maturi: Ruby, Python, Java.

Il client PHP scritto da “nostro” Daniele Alessandri è ottimo (Predis) ma per ora necessità di PHP moderni. Chiaramente le librerie dei linguaggi meno utilizzati sono aggiornate meno frequentemente, ma il protocollo di Redis è davvero molto semplice.

Cosa vedi nel futuro di Redis e più in generale dei key-value DB?

Abbiamo una roadmap importante. Nel futuro vedo il rilascio della 2.0 che aggiunge transazioni atomiche, Virtual Memory, e operazioni bloccanti sulla lista. E poi il progetto Redis-cluster, che tenterà di far diventare Redis un database distribuito.

Credo che i Key Value “semplici” siano utili, ma Redis ha aperto un nuovo fronte. Mi piacerebbe che nuovi database adottassero questa politica di Redis ma con implementazioni su disco. Insomma, manca un Tokyo Cabinet con le operazioni offerte da Redis secondo me.

Il movimento NoSQL è molto giovane… vedremo cosa succederà ma io sono abbastanza convinto che finalmente i programmatori si sono “riappropriati” dei database, e non useranno più una sola soluzione (SQL) per tutti i tipi di problemi.

Una curiosità. Come è nato Redis?

Perché con MySQL non riuscivo a scalare http://lloogg.com :)

Nel corso di questi anni hai realizzato molti progetti, hai già qualche nuova idea per il futuro?

Mi vorrei concentrare su Redis per il futuro. È un progetto che ha bisogno di molto sviluppo. Forse tra 5 anni passerò a qualcos’altro ma per ora il mio focus è li.

Dato il successo di Redis pensi di farlo diventare il tuo lavoro principale?

Si, sto provando a lavorare full time a Redis. Forse tra qualche tempo annuncerò delle interessanti novità ;)

Grazie per averci concesso il tuo tempo e per l’ottimo lavoro svolto con Redis. Un plauso anche per la documentazione chiara ed abbondante con numerosi esempi.

Grazie a voi!

Cassandra è un database distribuito sviluppato per gestire una gran quantità di dati sparsi su molte macchine con lo scopo di offrire un’alta affidabilità senza strutture SPoF (single point of failure).

Il progetto inizialmente è stato sviluppato da Facebook e viene descritto come un database che utilizza il modello dati BigTable sopra ad un’infrastruttura di tipo Amazon Dynamo. Dopo essere stato rilasciato sotto licenza Apache 2 lo scorso marzo è entrato a far parte dei progetti gestiti dall’Apache Foundation.

A distanza di quasi un anno di sviluppo è finalmente diventato un Top Level Project, come avvenuto anche con Subversion. Dopo il salto potete trovare le slide ed un video che presentano le caratteristiche del database.

Via | Apache

Derby, infatti, è un RDBMS sviluppato da Apache e basato su SQL, costituito da un engine abbastanza piccolo da poter essere integrato in qualsiasi soluzione realizzata con java. Derby inoltre assicura l’integrità dei dati e fornisce supporto alle transazioni.

Derby offre al programmatore una duplice modalità di utilizzo: Embedded o Server-based. Utilizzando la modalità embedded, il database e l’applicativo utilizzeranno la medesima virtual machine, risultando di conseguenza trasparente all’utente finale il quale non dovrà preoccuparsi di avviare o arrestare il database. La seconda modalità, invece, vede Derby configurato come un server di rete. In questo caso, verrà utilizzata la JVM del server sul quale Derby è stato installato.

Piuttosto lunga risulta essere la lista dei progetti e dei prodotto in grado di supportare Derby: Tomcat, Jboss, Glassfish, Eclipse Database Developer, NetBeans, OpenOffice, Squirrel SQL, Hibernate, ma la lista potrebbe continuare a lungo.

Frutto della collaborazione tra Monty Program ab, la nuova azienda di Widenius, e di Percona , azienda specializzata in consulenze su MySQL, si pone come scopo principale quello di essere un punto di riferimento per tutti gli sviluppi e servizi relativi a MySQL, riducendo la frammentazione e l’incertezza che al momento stanno affrontando le varie comunità, le aziende e i tecnici che hanno a che fare con MySQL e MariaDB il fork di MySQL creato dalla nuova azienda di Widenius.

Il consorzio è la naturale conseguenza dell’acquisizione da parte di Oracle di MySQL, e del suo silenzio riguardo alla definizione di un futuro certo per il famoso database opensource. Le aziende che operano o che hanno intenzione di contribuire a MariaDB o di utilizzarlo come prodotto per applicazioni enterprise sono invitate ad unirsi all’ODBA.

Via | OpenDatabaseAlliance

La novità più importante è l’implementazione del nuovo transactional storage engineFalcon (scelta derivante dall’acquisto di InnoDB da parte di Oracle) che promette feature molto interessanti come crash recovery, transazioni veloci, velocità nell’indicizzazione, diagnosi delle performance attraverso l’utilizzo di specifiche tabelle, semplicità nella configurazione.

La versione 6.0.2 alpha rilasciata da pochi giorni include tra le molte novità il supporto a sistemi Windows a 64 bit, a MacOSX e molto altro.

Download: MySQL 6.0.2

[Via | Freshmeat]

Falcon per ora ha visto solo la seconda alfa release e quindi è ben lungi dall’essere “error free” ed ottimizzato come gli altri engine supportati dal DBMS. Sono comunque interessanti gli articoli che iniziano a comparire sul sistema in questione e su quello che offrirà.

via Linux Today

[Via: Firebird News]