GreenSQL ora su AWS

Greensql_AWSbigGreenSQL offerta Database Secutiry su Amazon Web Services (AWS)

9 Luglio 2014, GreenSQL, azienda leader nelle soluzioni di sicurezza dei dati (DB), ha annunciato al mondo la disponibilita’ di una soluzione appositamente pensata per la piattaforma AWS, per l’appunto ” GreenSQL per AWS ” pronta a dare tutta la potenza ed i livelli di sicurezza certificati da GreenSQL sia in locale che ora anche nel Cloud.

Le caratteristiche principali sono le seguenti :

  • Versione del prodotto (ad oggi) 2.6.7
  • Sistema Operativo Linux / Unix, Linux Amazon 2.014,03
  • Architettura64-bit Amazon Macchina Image (AMI)
  • Servizi AWS AmazonEC2, AmazonEBS


Descrizione del prodotto
(alcuni interessanti video si possono trovare sul canale Youtube di GreenSQL)

GreenSQL fornisce soluzioni avanzate di sicurezza per database, proteggendoli da attacchi di SQL injection (ad esempio SSN, numeri di carte di credito, e-mail, password amministrative ecc…), mascherando i dati sensibili e monitorando costantemente la veridicita’ dei dati di accesso degli utenti che dovranno soddisfare vari livelli di conformita’ a normative quali PCI e HIPAA. Una volta installato come front-end delle vostre applicazioni web nel Cloud, GreenSQL sara’ in grado di mimetizzare perfettamente e proteggere le applicazioni, i database ed i dati in essi contenuti, questo poiche’ GreenSQL e in grado di individuare automaticamente e mascherare i dati sensibili memorizzati nel database.

Inoltre e’ in grado di:

– bloccare in tempo reale tutte le SQL injection rilevate;  

–  monitorare le attività sul database eseguite dagli amministratori di sistema e dai DBA

– attuare la separazione delle funzioni creando le regole base per le restrizioni di accesso ai dati filtrando ed accoppiando le utenze ad apposite liste d’indirizzi IP geografici ….

Se quello che avete letto vi incuriosisce e volete saperne di piu’ in merito vi invito a leggere gli articoli precedenti su GreenSQL quali :

DB fate largo ai No-SQL

nosql_logoI Database NoSQL

NO-SQL è un movimento che negli ultimi anni si è molto affermato, producendo dei risultati soddisfacenti con la creazione di progetti e iniziative utilizzate anche su larga scala. Tale movimento vuole “rompere” la storica linea dei database relazionali e definire delle nuove linee guida per l’implementazione di database che non utilizzano il linguaggio di interrogazione SQL e non siano strettamente legati ad una definizione “rigida” dello schema dati.
La filosofia del NO-SQL si può riassumere nei seguenti punti, partendo dalla domanda “Perchè avere altri DBMS se esistono quelli relazionali?”:

  1. I database relazionali sono troppo costosi e spesso, quelli che svolgono bene il loro lavoro, sono solo commerciali. NO-SQL abbraccia totalmente la filosofia open-source;
  2. NO-SQL è semplice da usare e non occorre uno specialista di DBMS. Il paradigma di programmazione è, infatti, ad oggetti;
  3. I dati sono altamente portabili su sistemi differenti, da Macintosh a DOS;
  4. Non definisce uno schema “rigido” (schemaless) e non occorre prototipare i campi, per cui non esistono limiti o restrizioni ai dati memorizzati nei database NO-SQL;
  5. Velocità di esecuzione, di interrogazione di grosse quantità di dati e possibilità di distribuirli su più sistemi eterogenei (replicazione dei dati), con un meccanismo totalmente trasparente all’utilizzatore;
  6. I DBMS NO-SQL si focalizzano su una scalabilità orizzontale e non verticale come quelli relazionali.

A questo punto passiamo a fare una comparazione tra quelli che attualmente sono tra i piu’ utilizzati , quali :

Cassandra, MongoDB, CouchDB, Redis, Riak, HBase, Membase e Neo4j :

** (vedi anche precedente articolo Not Only Sql)
– CouchDB

Scritto in: Erlang
Punto principale: Consistenza DB consistency, facilità d’uso
Licenza: Apache
Protocolli: HTTP/REST
Replicazione bidirezionale continua o ad-hoc con individuazione dei conflitti, replicazione master-master
MVCC – le operazioni di scrittura non bloccano le letture
Sono disponibili le versioni precedenti dei documenti
Progettazione crash-only (reliable)
Necessità di compattazioni nel tempo
Viste: embedded map/reduce
Viste formattate: lists & shows
Possibilità di validazione server-side dei documenti
Possibile autenticazione
Aggiornamenti real-time attraverso _changes (!)
Gestione degli allegati e, CouchApps (standalone js apps)
libreria jQuery inclusa
Utilizzo ideale: Per accumulazione dei dati con cambi occasionali sui quali vengono eseguite query predefinite. Situazioni in cui la gestione delle versioni è importante.
Per esempio: CRM, sistemi CMS. Situazioni in cui la replicazione master-master è una caratteristica interessante (ad esempio multisito).

– Redis

Scritto in: C/C++
Punto principale: Velocità
Licenza: BSD
Protocolli: Telnet-like
Disk-backed in-memory database,
In questo momento non include il disk-swap (VM e Diskstore sono stati abbandonati)
Replicazione master-slave
Recupero di valori semplici o intere tables a partire da una chiave
suppporto ad operazioni complesse come ZREVRANGEBYSCORE.
INCR (incremento) e  simili (molto utili per gestire limitazioni di valore e statistiche)
permette l’uso di insiemi (sets) e operazioni su essi (unione/differenza/intersezione)
permette l’uso di liste (lists) e  operazioni su esse (queue; blocking pop)
permette l’uso di hashes (oggetti dotati di campi)
permette l’uso di insiemi ordinati (utili per classifiche, e ricerche su range di valori)
Redis implementa correttamente le transazioni (!)
I valori memorizzati possono avere una scadenza temporale (sistemi di cache)
Implementa facilmente il messaging Publisher/Subscriber (!)
Utilizzo ideale: Adatto a moli di dati (residenti in memoria) di dimensione nota che cambiano frequentemente .
Per esempio: Quotazioni azionistiche. Analisi. Gestione dati in Real-time. Comunicazioni in Real-time.

– MongoDB

Scritto in: C++
Punto principale: Mantiene alcune proprietà utili del modello SQL (Query, index) molto facili da usare.
Licenza: AGPL (Drivers: Apache)
Protocollo: Specifico, binario (BSON)
Replica Master/slave (munita di  failover quando si usano i  “replica sets”)
Lo Sharding è parte integrante del sistema
Le intterrogazioni a db (queries) sono espressioni javascript
Permette l’uso di funzion i javascript lato server
Update-in-place migliore rispetto a CouchDB
Usa “memory mapped files” per la persistenza dei dati
Favorisce la velocità rispetto alle funzionalità implementate
Journaling (opzione –journal) fortemente consigliato
Sui sistemi a 32bit risente di una  limitazione sulla quantità di dati a circa 2.5Gb
Un database vuoto occupa comunque 192Mb
GridFS per la memorizzazione di “big data + metadata” (effettivamente non è un  FS)
Indicizzazione geospaziale Geospatial indexing
Utilizzo ideale: se si necessita di query dinamiche. Se si preferisce lavorare con gli indici rispetto ad usare algoritmi map/reduce. Buono se si ha bisogno di velocità quando si lavora con grandi moli di dati.  Adatto a tutti gli scenari in cui si usa CouchDB e non si può scegliere quest’ultimo perchè i dati cambiano troppo riempiendo la memoria fisica.
Per esempio: tutte le situazioni in cui si vorrebbe usare MySQL o PostgreSQL senza avere colonne definite a priori.

– Riak

Scritto in: Erlang & C, some Javascript
Punto principale: Fault tolerance
Licenza: Apache
Protocollo: HTTP/REST o custom binary
Trade-offs modulabili per replica e distribuzione (N, R, W)
Hooks di pre- e post-commit in JavaScript o Erlang, per la validazione e la sicurezza.
Map/reduce in JavaScript o Erlang
Links & link walking per utilizzarlo come database a grafi
Indici secondari: ricerca nei metadati
Supporto per oggetti di grandi dimensioni (Luwak)
Edizioni sia “open source” che “enterprise”
Ricerca full-text, indexing e querying con il Riak Search server (beta)
Sta migrando lo storing di backend da “Bitcask” al “LevelDB” di Google
La multi-site replication replication senza alcun master e il monitoring SNMP necessitano di una licenza commerciale
Utilizzo ideale: se si vuole qualcosa di simile a Cassandra (Dynamo), ma non si ha nessuna intenzione di avere a che fare con la realtiva inerente complessità. Se si ha bisogno di un’ottima scalabilità, disponibilità e fault-tolerance per un solo sito ma si è disposti a pagare per la replica multi-sito.
Per esempio: Raccolta dei dati di point-of-sales. Sistemi di controllo aziendali. Situazioni in cui anche il downtime di alcuni secondi può essere rilevante. Potrebbe essere anche utilizzato come un web server estremamente aggiornabile.

– Membase

Scritto in: Erlang & C
Punto principale: Compatibile con memcache ma con persistenza e clustering
Licenza: Apache 2.0
Protocollo: memcached con estensioni
Accesso molto veloce ai dati mediante chiave (200k+/sec)
Persistenza su disco
Tutti i nodi sono identici (replicazione master-master)
Fornisce un sistema a buckets simile a memcached
De-duplicazione delle scritture per ridurre IO
Interfaccia GUI per la gestione dei cluster molto interessante
Aggiornamento software senza mettere offline il database
Proxy di connessione per il pooling e il multiplexing (Moxi)
Utilizzo ideale: Qualsiasi applicazione dove un bassa latenza dell’accesso ai dati, un’alta concorrenzialità e un’alta disponibilità degli stessi sono requisiti chiave.
Per esempio: Casi in cui c’è necessità di bassa latenza come l’erogazione di servizi di pubblicità mirata (ad targeting)  o alta concorrenza come il giochi online (per esempio Zynga).

– Neo4j

Scritto in: Java
Punto principale: Database a grafi o dati connessi
Licenza: GPL, salcune caratterstiche con AGPL/commerciale
Protocollo: HTTP/REST (o incluso in  Java)
Standalone, o includibile nelle applicazioni Java
Piena conformità ACID (incluso i dati durable)
Sia i nodi che le releazioni possono avere dei metadati
Linquaggio di query basato su pattern-matching (“Cypher”)
Può anche essere usato il linguaggio di attraversamento dei gravi “Gremlin”
Indicizzazione dei nodi, delle chiavi e delle relazioni
Piacevole interfaccia di amministrazione web
Sono disponibili diversi algoritmi di ricerca dei percorsi
Ottimizzato per le letture
Ha le transazioni (nelle API Java)
Si può usare il linguaggio di scripting Groovy
Backup online, monitoraggio avanzato e alta disponibilità con licenza AGPL/commerciale
Utilizzo ideale: Per dati interconnessi, semplici o complessi, con struttura a grafo. In questo senso Neo4j is è un po’ diverso dagli altri database noSQL.
Per esempio: Relazioni sociali, collegamenti nei trasposti pubblici, mappe di strade, topologie di rete.

– Cassandra

Scritto in: Java
Punto principale: Migliore di BigTable e Dynamo
Licenza: Apache
Protocollo: Proprietario, binario (Thrift)
Distribuzione e replicazione attivabile (N, R, W)
Query possibili mediante colonne e insiemi di chiavi
Carattersitiche simili a BigTable: colonne, famiglie di colonne
Indici secondati
La scrittura è molto più veloce della lettura(!)
Mappatura e riduzione possibile mediante Apache Hadoop
I admit being a bit biased against it, because of the bloat and complexity it has partly because of Java (configuration, seeing exceptions, etc)
Utilizzo ideale: Quando si scrive più che leggere (logging). Se ogni componente del sistema deve essere in Java.
Per esempio: Sistemi bancari e industria finanziaria.
Inoltre, siccome le scritture sono più veloci delle letture, una nicchia naturale è l’analisi dei dati in tempo reale.

– HBase

Scritto in: Java
Punto principale: miliardi di righe con milioni di colonne
Licenza: Apache
Protocollo: HTTP/REST (anche Thrift)
Modellato dopo BigTable
Mappatura e riduzione con Hadoop
Costrutti query push down attraverso scansione lato server e con filtri per il get
ottimizzazione per le query in tempo reale
E’ un gateway Thrift con alte performance
HTTP supports XML, Protobuf, and binary
Cascading, hive, and pig source and sink modules
Shell basata su Jruby (JIRB)
Punti di ripristino multipli
Rolling restart for configuration changes and minor upgrades
L’accesso random ai dati è paragonabile a quello di MySQL
Utilizzo ideale: Se siete innamorati di BigTable.   e quando c’è la necessità di un accesso in lettura e scrittura, random e in tempo reale alla grande quantità di dati.
Per esempio: il database dei messaggi in Facebook.

 

La scelta e’ davvero varia a seconda del compito che vi serve maggiormente venga svolto dal DB che avrete prescelto, quindi perche’ non provarli ?

Proteggi Mysql con GreenSQL

SQL Injection

SQL Injection

Mysql DB, GreenSQL FW e le SQL injection

Nel corso degli anni i Database hanno conosciuto un’evoluzione repentina, a questa ha fatto seguito, data l’importanza dei dati contenuti, un’escalation dei problemi inerenti la sicurezza. Le vulnerabilita’ che colpiscono i DB sono ormai molte e differenziate e gli “exploit” di tipo SQL injection sono quasi all’ordine del giorno, tra i piu’ colpiti c’e’ proprio Mysql che in pochi anni e’ diventato il default DB di moltissime applicazioni web; ecco perche’ bisogna fare molta attenzione e sapere come correre ai ripari.

Come ben noto ai web master le SQL Injection sono un problema comune di molte applicazioni web li dove le piu’ banali cause possono venire arginate da un sitemista scrupoloso e attento ad un buon hardening di sistema, possono sempre insorgere altri “bachi” non voluti, negli algoritmi di arginazione.

Una soluzione efficiente e ben strutturata la propone GreenSQL, un software Open Source che si presenta sotto l’aspetto di un proxy/firewall, al quale ci si interfaccia come una comunissima connessione ai database e gestisce le connessione con il database filtrando eventuali codici “illegali”.

Come funziona

In pratica la query inviata alla web application viene esaminata da GreenSQL, che intercetta il traffico diretto al DB, e nel qual caso la query sia ritenuta rischiosa non viene inoltrata al database e il risultato restituito sara’ nullo.
Viceversa se l’interrogazione risulta conforme alle specifiche verrà inoltrata al database e il risultato reso disponibile all’applicazione.

Il software può lavorare in tre modalità:

  • Simulation Mode (IDS)
  • Blocking Suspicious Commands (Database IPS)
  • Learning Mode
  • Active protection da query sconosciute (DB Firewall)

Come agiscono
Se l’applicazione è impostata in Simulation Mode funziona sostanzialmente come un sistema IDS (Intrusion Detection System). Tutte le query ritenute dannose vengono semplicemente loggate e poi notificate all’amministratore che può consultarle attraverso la console d’amministazione.

In modalità Blocking Suspicious Commands il sistema invece funziona come un IPS (Intrusion Prevention System). In questa modalità le query che non sono all’interno della white list del programma vengono automaticamente bloccate e, il programma, restituisce un risultato nullo all’applicazione web. Altrimenti, se la query è considerata non maligna, viene eseguita. Durante questa modalità però possono essere generati falsi positivi o falsi negativi.
Per evitare i problemi dovuti alle due modalità sopra citate è stata sviluppata la modalità Learning mode durante la quale il programma impara tutte le query che l’applicazione web può inviare e le aggiunge alla white list. Una volta finita la modalità d’apprendimento si deve ripassare ad una delle due modalità citate in precedenza, in modo da avere un livello di protezione piu’ adeguato.
Si può inoltre attivare la protezione dalle query sconosciute, questa opzione permette di bloccare in automatico i comandi sconosciuti che giungono GreenSQL. Per poter calcolare se un comando è illegale o meno si avvale di un motore di pattern matching che lavora in due modalità. La prima controlla che la query inviata non vada ad eseguire comandi amministrativi (ad esempio GRANT o REVOKE, o comandi che vanno a modificare la struttura del database). L’altra invece calcola il rischio di una query basandosi su dei metodi euristici, se il rischio è sufficientemente alto la query viene bloccata in automatico.

Calcolare il rischio delle query
GreenSQL puo’ calcolare il rischio di ogni query ; essenzialmente, questo è un sottosistema di rilevamento delle anomalie. Dopo che il rischio è calcolato, GreenSQL è in grado di bloccare la query o semplicemente creare un messaggio di avviso (questo dipende dalla modalità attivata). Ci sono una serie di operazioni euristiche che GreenSQL utilizza per il calcolo del rischio. Per esempio, il rischio di query è aumentato da:

  • L’accesso alle tabelle sensibili (gli utenti, gli account, le informazioni di credito)
  • Commenti all’interno di comandi SQL
  • Una stringa password vuota
  • Una ‘OR’ all’interno di una query
  • Un’espressione SQL che restituisce sempre vero

Per trovare anomalie, GreenSQL usa il proprio lexer ( o analizzatore lessicale ) cercando SQL tokens (costituiti da identificatori, costanti e parole chiave).

Per maggiori chiarimenti e per avere una guida ufficiale non esitate ad andare sul sito ufficiale di GreenSQL FW

 

GreenSQL il FW per i DB

greensql-architecture
GreenSQL: un reverse proxy contro gli attacchi SQL injection

GreenSQL è un’interessante applicazione che promette di proteggere un database da eventuali attacchi dannosi. Sostanzialmente si tratta di un firewall open source che fa da filtro tra l’applicazione web e il database. Funziona come un proxy, l’applicazione invece di connettersi al database si connette a GreenSQL che poi gestisce la connessione con il database vero e proprio.

Attacchi SQL injection

Un attacco di tipo SQL injection consiste nell’inserimento “injection” di una particolare query SQL nei dati passati in input ad una applicazione da parte di un client allo scopo di provocare l’esecuzione di comandi SQL predefiniti.
Un exploit di tipo SQL injection se coronato da successo può rivelare dati sensibili da un database, modificarli, eseguire operazioni amministrative sul database (come uno shutdown od un backup), e talvolta anche impartire comandi al sistema operativo sottostante.

GreenSQL è un database firewall Open Source utilizzabile per proteggere le basi di dati da attacchi di tipo SQL injection, operando come un proxy per comandi SQL,e con integrato il supporto per Mysql.

La sua logica operativa si basa sulla valutazione dei comandi SQL, sia utilizzando una matrice di indici di rischio, sia bloccando comandi amministrativi del db (DROP, CREATE, etc).

GreenSQL opera come un reverse proxy per le connessioni Mysql. Vale a dire che invece del server Mysql, le applicazioni si connettono al server GreenSQL, che analizzerà le queries SQL e le inoltrerà al server Mysql di back-end.

Sostanzialmente funziona così: se la query mandata dall’applicazione è ritenuta rischiosa da parte di GreeSQL essa non viene mandata al DB e GreenSQL restituisce all’applicazione un risultato nullo. Alternativamente, se la query non presenta problemi, viene inviata al server e la rispostata arriva poi alla web application.

Per default GreenSQL lavora sulla porta 3305 girando tutte le richieste al server Mysql sulla porta

http://127.0.0.1:3306

Si puo’ configurare in modalita’ differenti quali :

  • Simulation Mode (database IDS): Non effettua nessuna operazione ma permette l’analisi del comportamento di GreenSQL.
  • Blocking Suspicious Commands (database IPS): In questa modalita’ effettua un analisi euristica per cercare query giudicate “illegali” e le blocca automaticamente. In questa modalita’ si richia di bloccare falsi positivi e far eseguire query che risultano essere falsi negativi.
  • Learning mode: si usa per evitare i problemi del Blocking Suspicious mode. Permette di visionare l’analisi della query e “informare” di volta in volta il software se bloccare o no questo tipo di operazioni.
  • Active protection from unknown queries (db firewall): dopo un certo periodo di “apprendimento” nella modalita’ learning mode il sistema puo’ passare alla fase successiva (bene, ho imparato tutto, ora sono pronto ad operare da solo!).

Passiamo ora all’installazione:

Si scarichi l’ultima versione del software dalla url del sito http://www.greensql.net in particolare la “GreenSQL Firewall”
riferito alla vostra piattaforma ed una volta installato il pacchetto inerente alla vostra piattaforma.

Dopo l’installazione il server greensql girera’ sulla porta 3305. provate ad accedervi con il comando:

mysql -h 127.0.0.1 -P 3305 -u root -p

Dopo aver digitato la password di root dovreste andare sul prompt di mysql (quit per uscire).

Ora il sistema e’ pronto per essere utilizzato. Non dovete far altro che avere l’accortezza di modificare i vostri script di configurazione chiedendo di connettersi sulla porta 3305 piuttosto che la 3306.

Se ad esempio il vostro CMS e’ gia’ impostato per effettuare la connessione sulla porta di default allora editate il configuration.php (o relativo file) nella sezione specifica. Ad esempio se trovate qualcosa del tipo:

$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');

sostituitela con

$link = mysql_connect('localhost:3305', 'mysql_user', 'mysql_password');

Installiamo ora la greensql-console che permette di gestire, manutenere ed impostare tutte le caratteristiche di GreenSQL.

Scaricate sempre dal link per i download scaricate la “Management Console” relativa alla vostra piattaforma :

tar xvfz greensql-console-<VERSIONE> -C /opt/

cd /opt/greensql-console

vim config.php

Editate i campi:

$db_name = "greendb";

$db_user = "green";

$db_pass = "greensqlpassword";

Accertatevi di aver impostato i permessi della cartella template_c a 777:

# chmod 777 templates_c

Ora potete accedere via web alla management Console dalla URL:

http://<vostro_indirizzo_ip>/greensql-console

Da qui potete verificare tutte le operazioni che effettua il GreenSQL con le varie possibilita’ di operare.

Infine per fermare e riavviare il servizio potete eseguire i comandi:

/etc/init.d/greensql-fw stop

/etc/init.d/greensql-fw start

Buon divertimento !

Introduzione a CouchDB

couchDBCouchDB e’ un database documentale NoSQL disponibile con l’ampia licenza Apache.
Apache CouchDB e’ un moderno documentale richiamabile semplicemente con l’HTTP e che al tempo stesso offre le piu’ avanzate funzionalita’ di replicazione dati e di ricerca in parallelo (Map/Reduce).

CouchDB (acronimo di Cluster Of Unreliable Commodity Hardware) e’ uno dei piu’ diffusi DB documentali Web grazie alla sua velocita’, alla flessibilita, alla semplicita’ di utilizzo ed al… prezzo!

Installazione

Installare CouchDB e cURL (che serve per accedere) e’ facile su Linux (eg. RedHat, Fedora, CentOS, Scientific Linux, …):

yum install couchdb curl -y
oppure
sudo aptitude install couchdb curl
Ora bisogna far partire il server CouchDB con il comando couchdb. Per verificare se funziona tutto basta un comando:
# curl http://127.0.0.1:5984
{“couchdb”:”Welcome”,”uuid”:”fd91d8b7b77c7f6d75d5937326a95ad2″,”version”:”1.5.0″,”vendor”:{“version”:”14.04″,”name”:”Ubuntu”}}

CouchDB e’ disponibile per tutti i sistemi UNIX-based ed anche sulle piattaforme MS-Windows e Mac OS X. Installare le versioni precedenti di CouchDB non era cosi’ semplice: bisognava partire dall’installazione del linguaggio di programmazione Erlang e ricompilare…

Utilizzo

CouchDB e’ accessibile esclusivamente attraverso un HTTP-based RESTful API, cio’ significa che, anziche’ collegarsi al DB server utilizzando un’applicazione client per interagire con il sistema, basta utilizzare un software in grado di interagire con un HTTP server web per fare richieste. CouchDB che a sua volta eseguira’ le azioni nel database, restituendo una risposta appropriata quando finito.
Quindi e’ possibile gestire il database semplicemente visitando gli URL nel browser web oppure utilizzando gli strumenti da riga di comando come curl o, cosa piu’ importante, attraverso qualsiasi linguaggio di programmazione che supporta richieste HTTP.
L’implementazione dell’interfaccia REST (Representational Transfer State) su CouchDB e’ molto completa poiche’ non si limita al CRUD (CREATE, READ, UPDATE, DELETE) ma ogni operazione svolta su CouchDB e’ richiamabile con l’HTTP.

Futon

CouchDB possiede una sua interfaccia web molto user friendly, Futon, dalla quale e’ possibile eseguire qualsiasi operazione per la gestione di un database, come l’inserimento, la visualizzazione, la modifica e la cancellazione dei dati. Inoltre Futon contiene anche le principali funzionalita’ di amministrazione di un database, come le impostazioni di configurazione, la replicazione dei dati, definizione dei ruoli e privilegi e uno strumento di testing.
Per accedere all’interfaccia web basta collegarsi da browser a localhost:5984/_utils

cURL

Per i piu’ affezionati alla linea di comando (come me per esempio), si puo’ usare curl, un ottimo tool utile per trasferire dati da/a un server utilizzando vari protocolli, tra cui HTTP, HTTPS, FTP. Il modo per farlo e’ digitando:

curl <opzioni> <ip_host>:5984/<database>/<record>.

Da notare che nel URL viene specificata la porta 5984, e’ quella usata dal processo di couchdb.
Tra le opzioni piu’ importanti: -X per specificare il tipo di richiesta http: GET per richiedere dati, PUT e POST per modificare dati o DELETE per cancellare. Inoltre -d permette di specificare i dati da includere nella richiesta, ad esempio per modificare documenti nel database.
Esempi:

# Crea il database "libri"
curl -X PUT http://127.0.0.1:5984/libri

# Visualizza il contenuto di "libri" (all'inizio e' vuoto)
curl -X GET http://127.0.0.1:5984/libri

# Crea il documento con _id "lafineeilmioinizio" dentro il database "libri"
curl -X PUT http://127.0.0.1:5984/libri/lafineeilmioinizio \
 -d '{"titolo":"La fine e il mio inizio", "autore":"Tiziano Terzani", 
      "casa_editrice":"Longanesi", "prezzo":"18.60"}'

# NB: Tutte le volte che un documento viene modificato riceve un revision number
# Modifica un documento aggiungendo come allegato un'immagine
curl -X PUT http://127.0.0.1:5984/libri/lafineeilmioinizio/cover.jpg?rev=1-XXX \
 --data-binary @images/budda.jpg -H "Content-Type: image/jpg"

# Crea un documento hungergames copiando il contenuto da un altro documento
curl -X COPY http://127.0.0.1:5984/libri/lafineeilmioinizio -H "Destination: hungergames"

# Cancella il documento con _id "hungergames"
curl -X DELETE http://127.0.0.1:5984/libri/hungergames?rev=1-YYY 

# Effettua un caricamento massivo di documenti da file
curl -X POST http://127.0.0.1:5984/libri/_bulk_docs -H "Content-type: application/json" -d @biblio.json

# Visualizza tutto il contenuto del database "libri" e il dettaglio dei documenti presenti
curl -X GET http://127.0.0.1:5984/libri/_all_docs?include_docs=true

Architettura

CouchDB e’ un database document-oriented. Cio’ significa che a differenza dei piu’ tradizionali DBMS (Database Management System) relazionali come Oracle e PostgreSQL, i dati non vengono memorizzati in tabelle (o se volete, relazioni), ma in “documenti”.

Su un database relazionale le tabelle hanno una struttura rigida, sono composte da campi definiti prima della effettiva memorizzazione dei dati. Le tabelle vanno dichiarate con gli opportuni statement DDL, prima di essere utilizzate. Ogni tabella e’ composta da tuple (ovvero le righe della tabella o i record) che contengono i dati. La gestione dei dati si effettua con statement DML. I comandi DDL e DML della stragrande maggioranza dei DB relazionali sono in SQL. Ora dimentichiamoci tutto questo…

In CouchDB il concetto di relazione o di tabella non esiste, l’elemento fondamentale e’ il documento che contiene al suo interno tutti i dati relativi, organizzati in modo eterogeneo. Si possono aggiungere e modificare i campi anche dopo l’effettivo inserimento dei dati. In questo modo record appartenenti alla stessa categoria di informazioni possono avere campi diversi tra di loro. La chiave primaria dei database relazionali viene tradotta nel campo univoco _id di CouchDB, creato automaticamente dall’engine del DBMS (ma che e’ anche possibile indicare in modo esplicito.

Dal punto di vista del sistema operativo CouchDB si presenta come un unico processo beam.smp in ascolto sulla porta TCP 5984 (6984 se e’ abilitato l’HTTPS). In realta’ all’interno del processo operano diversi thread con compiti specifici.
I file utilizzati da CouchDB su Linux si trovano in /etc/couchdb, i file di database su /var/lib/couchdb, i log su /var/log/couchdb.

Consistenza dei dati e replicazione

CouchDB non utilizza alcun meccanismo di locking ma sfrutta l’MVCC (Multiversion Concurrency Control), ogni modifica di un oggetto ne crea una nuova versione. Le versioni precedenti non vengono cancellate. Se due modifiche vanno in conflitto poiche’ accedono allo stesso documento, la seconda riceve un errore in save. L’applicazione deve riprendere l’ultima versione del documento e rieseguire l’UPDATE.
L’isolamento e’ mantenuto solo a livello di un singolo documento, questa e’ una notevole semplificazione, rispetto alla complessa logica transazionale di altri database, ma consente l’ottimizzazione, la parallelizzazione e la distribuzione dei dati in modo semplice. A livello di accesso al file di dati ogni singola modifica ad un documento rispetta le proprieta ACID (Atomic Consistent Isolated Durable) con la serializzazione delle modifiche sui documenti e la scrittura sincrona sul disco.

Piu’ database CouchDB possono essere collegati tra loro in modo molto semplice. I database vengono aggiornati tra loro con una replicazione peer-to-peer incrementale implementata nativamente nell’engine. CouchDB permette una replicazione bidirezionale asincrona, utilizza un meccanismo automatico di risoluzione dei conflitti e fornisce una eventual consistency tra i database. Se i database sono ospitati su nodi differenti si ottiene con questo la distribuzione dei dati.
La replicazione di CouchDB puo’ essere utilizzata sia per sincronizzare database locali che per complesse configurazioni con sharding dei dati.