Cassie è un client di Cassandra, il database non relazionale, realizzato in Scala — un linguaggio di programmazione su Virtual Machine (VM), alternativo a Java di Oracle. Twitter ha creato un fork dell’abbandonato progetto di Coda Hale e ne ha “liberato” i sorgenti. È il client utilizzato per la stessa piattaforma di microblogging.
Utilizzato per dialogare con «una dozzina di cluster e oltre un migliaio di macchine» su Cassandra, Cassie si avvale di Finagle: il network stack di Twitter per generare client di Remote Procedure Call (RPC) asincrone in Java, Scala o qualunque altro linguaggio di programmazione per JVM. Finagle è basato su Netty e scritto in Scala.
È considerato molto stabile. Tuttavia, Cassie prevede delle funzionalità limitate alle esigenze di Twitter: non supporta ogni caratteristica di Cassandra. Ad esempio, l’iterazione asincrona tra righe e colonne del database è di nuova concezione e potrebbe cambiare nel tempo. Cassie è più “leggero” di Astyanax, il client di Netflix.
Via | Twitter Developers
Astyanax è un client di Cassandra, il database non relazionale, scritto in Java — e realizzato da Netflix. Garantisce delle prestazioni equivalenti a Hector, una soluzione su CloudBees. Astyanax è figlio di Hector e nipote di Cassandra, nella mitologia ellenica: il client è ottimizzato per le esigenze di catalogazione del servizio.
Il rilascio dei sorgenti di Astyanax – per i quali è stata scelta la licenza Apache 2.0 – rientra nella nuova politica open source di Netflix, che è stata inaugurata lo scorso dicembre con la “liberazione” di Curator per ZooKeeper. Entrambe le soluzioni sono state concepite in Java e sono utilizzate da Netflix per i servizi erogati.
Partito come un fork di Hector, Astyanax è diventato uno strumento più complesso. Se l’offerta di Netflix è tuttora assente dal mercato italiano, i sorgenti delle soluzioni open source sono disponibili ovunque: la scelta di “liberare” le tecnologie utilizzate in azienda è decisamente preferibile all’abbandono di progetti in disuso.
Via | Netflix
Rickard Öberg è uno sviluppatore di Neo Technology e ha realizzato un’estensione in Java Database Connectivity (JDBC) per Neo4j – il database open source mantenuto dalla propria società – che permette l’esecuzione di query in linguaggio SQL su database del tipo NoSQL. È un abbattimento definitivo, per le barriere tra i due modelli.
L’interfaccia ha dato la possibilità a Öberg di utilizzare DbVisualizer, LibreOffice, IntellJ e il gateway ODBC–JDBC con Neo4j. Öberg ha realizzato una “quirk mode” per rendere riconoscibile a Cypher – il linguaggio delle query di Neo4j – la sintassi di SQL dalle Representational State Transfer (REST) API. Il tutto passando da JDBC.
Bisogna sottolineare che l’estensione di Öberg è ancora in una fase iniziale e non è adatta a un utilizzo su larga scala. È, comunque, un presupposto interessante per l’interoperabilità delle applicazioni con database relazionali e non relazionali. Soprattutto se si prende in considerazione il test, già effettuato, su LibreOffice.
Via | The H Open
Jan Lehnardt è il presidente del Project Management Committee (PCM) di Apache CouchDB e ha deciso di rispondere a Canonical sullo stato dell’arte del database. In sintesi, il progetto è tutt’altro che “morto” e soprattutto non dipende da Couchbase: la società di Mark Shuttleworth citava quest’ultima come la proprietaria di CouchDB.
La querelle ha avuto inizio con l’eliminazione di CouchDB da Ubuntu One: Canonical ha optato per la realizzazione di un proprio database, U1DB, rivelata dagli sviluppatori di Novacut. Lehnardt non entra nel merito della decisione, ma non gradisce che i responsabili di Ubuntu denigrino CouchDB. È sempre lecito fare scelte differenti.
Purché non si dichiarino delle inesattezze. Canonical ha motivato la propria scelta con diverse argomentazioni, più o meno valide: fra queste non è accettabile che s’associ CouchDB a Couchbase. Se le patch, fornite da quest’ultima, sono state implementate nel ciclo di sviluppo di CouchDB è perché rispettavano la politica di Apache.
Continua a leggere: Gli sviluppatori di Apache CouchDB parlano a Canonical di Ubuntu One
Markus Winand considera Git come un ottimo esempio per i database di tipo NoSQL sulla base di una serie di motivazioni: anzitutto, Git non ha un frontend per SQL, né ha bisogno d’appoggiarsi a un backend in SQL. Inoltre è un sistema distribuito. Motivazioni inattaccabili, quanto povere per una tesi del genere: Git non è un database.
Eppure l’idea di Winand non è campata per aria e trova riscontro in un progetto di Tim Caswell, il creatore di WebApp su node.JS. Wheat, infatti, è un engine per la creazione di blog che s’appoggia a node.JS e utilizza proprio Git per il salvataggio delle informazioni. È un’applicazione inconsueta per il DVCS, comunque funzionante.
Da qui a definire Git un database di tipo NoSQL ce ne passa… oppure no? In sé, la definizione di NoSQL copre qualsiasi progetto utilizzato per immagazzinare i dati in modo non relazionale. Specialmente se distribuito. È un concetto molto generico, perciò anche Git potrebbe rientrarci. Il dibattito è aperto: e voi cosa ne pensate?
Via | ReadWriteWeb
Sviluppatori del progetto MongoDB hanno annunciato con molta soddisfazione la nuova versione 1.4.0 che è la prima a potersi fregiare del titolo “ready for production” ed è arrivata dopo altri 3 mesi di sviluppo dalla precedente release.
Per arrivare a questo risultato è stato indispensabile l’aiuto degli utenti che già utilizzavano questo database NoSQL in ambiti di produzione. La versione 1.4 ha migliorato le prestazioni, ha la possibilità di creare indici in background ed una gestione migliorata degli slave.
Migliorata anche la parte più vicina al programmatore, infatti il linguaggio di interrogazione si è arricchito di nuove keyword e della possibilità di fare ricerche geospaziali.
Il codice è rilasciato sotto licenza Affero GPLv3 ed è disponibile per Linux, Mac OS X, Solaris e Windows.
Via | MongoDB
Jonathan Ellis ha scritto un bell’articolo che analizza il movimento Nosql e quali sono le differenti strategie dei database non relazionali open source emergenti.
Cassandra, CouchDB, HBase, MongoDB, Neo4J, Redis, Riak, Scalaris, Tokyo Cabinet e Voldemort vengono analizzati in base:
Una buona guida per orientarvi tra questi nuovi prodotti cercando di capire quali sono i loro punti di forza, debolezze e come possono integrarsi con le vostre presenti e future applicazioni.
Via | RackspaceCloud
I database relazionali non sono sempre e certamente il sistema migliore dove immagazzinare i dati.
Negli ultimi mesi si stanno affermando database non relazionali per la gestione di dati o di interi documenti. Uno di questi è MongoDB che è sviluppato in c++ e prende il suo nome dal termine humongous.
I dati vengono salvati in formato Bson, in pratica un documento Json con una rappresentazione binaria efficiente. Grazie all’assenza di uno schema ed al supporto per strutture, liste, array associativi e blob binari potete inserire direttamente i dati dei vostri oggetti all’interno del database.
Redis, REmote DIctionary Server, è un avanzato database di tipo key-value.
Ha delle similitudini con memcached, da cui è partita l’idea originale, e può manipolare in maniera atomica stringhe, liste e set. Per essere molto veloce cerca di tenere il database in memoria scrivendo sul disco in maniera asincrona solo in determinate condizioni, ma supporta la replicazione master-server.
La versione 1.1 in beta supporta anche una modalità di scrittura su disco append-only con politiche di sync configurabili. Questo server è scritto in C e può girare su molto sistemi unix like. Sono disponibili anche molte libreria per l’interazione con i più diffusi linguaggi di programmazione.
Continua a leggere: Redis, un altro database non relazionale
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
