Il presente articolo è stato tradotto automaticamente.

Il programmatore al lavoro

Database NoSQL Cassandra, parte 3: clustering

Ted Neward

 

L'ultima volta, ho esaminato Apache Cassandra, il "open source, distribuito, decentrato, elasticamente scalabili, altamente disponibile, tolleranza, tuneably coerente, database column-oriented che basa la sua progettazione distribuzione su Amazon Dinamo e il modello di dati su Google Bigtable," come descritto nel libro "Cassandra: La guida definitiva"(o ' Reilly Media, 2010). Per essere più precisi, dopo aver installato Cassandra (nella prima parte di questa serie), ho guardato come a programma da Microsoft .NET Framework, facendo i bit di base di lettura e scrittura di dati. Niente di spettacolare.

Infatti, parte del "Spettacolare" di Cassandra è avvolto nella sua capacità intrinseca di cluster, dando facile scalabilità Cassandra. Questo significa che si può crescere fuori di dimensioni "ridicoli" — nella maggior parte dei casi con poco o nessun sforzo amministrativo — specialmente quando confrontato con il lavoro richiesto dalla maggior parte dei database relazionale per memorizzare le dimensioni equivalenti. Ad esempio, una società di tecnologia locale qui a Redmond, Washington. (dove vivo), ha sostenuto in un recente meetup di avvio che è stato di memorizzazione più di 50PB di dati in Cassandra.

Permettendo anche l'esagerazione e iperbole, appena un decimo di quello (5PB, o più di 5, 000TB) è un pezzo abbastanza pesante di dati. Ad essere onesti, il sito Web di Cassandra (cassandra.apache.org) afferma, "Il più grande conosciuto Cassandra cluster ha oltre 300 terabyte di dati in oltre 400 macchine," che è ancora piuttosto difficile da fare con una configurazione relazionale out-of-box.

Ma la chiave che tutti gli archivi è in cluster, e mentre ottenere un cluster di quelle dimensioni a produzione è probabilmente oltre la portata di questo articolo, possiamo almeno iniziare a giocare con lui ottenendo un cluster multinodo in esecuzione per il lavoro di sviluppo. Richiede pochi passi, quindi vado a piedi attraverso di essa un passo alla volta. (A proposito, DataStax ha un facile installare per Cassandra, ma come vicino posso dire manca la possibilità di configurare un cluster multinodo in una scatola; Questo è l'unico aspetto negativo che posso vedere così lontano.)

Installare Recap

Nel primo articolo di questa serie (msdn.microsoft.com/magazine/jj553519), sono andato attraverso il dolore (a volte angosciante) impostazione di Cassandra dal file zip e la riga di comando: Assicurarsi che sia installato un runtime Java e sul percorso; verificare che una variabile d'ambiente JAVA_HOME sia configurata; decomprimere la distribuzione di Cassandra in una directory; e poi lanciare il file "cassandra.bat" dalla directory "bin" per ottenere il server installato e funzionante.

Al momento, può avere sembrava davvero anacronistico di farlo, ma due cose positive provengono dal fare l'installazione in questo modo. In primo luogo, si ottiene qualche esperienza in come installare un server scritto in Java (e che si rivela per essere un'abilità molto utile, dare quante delle diverse implementazioni di NoSQL sono scritti in Java). In secondo luogo, è necessario "trucco" che la configurazione a un livello piuttosto basso per ottenere Cassandra eseguire più volte in una singola casella.

Vedete, la nozione di Cassandra di scalabilità proviene da un "anello" di server: più istanze del servizio Cassandra in esecuzione su diverse finestre, ciascuna una memorizzazione di una parte del set di dati totale. Poi, quando nuovi dati vengono scritti in anello, Cassandra "comari" (che è il termine tecnico effettivo per esso) tra i nodi nell'anello per inserire i dati nel posto giusto all'interno dell'anello. In un anello di oculatezza, Cassandra equilibrerà i dati tra i nodi in modo uniforme. Cassandra ha un numero di diverse strategie per scrivere i dati tra i nodi, ed è sempre possibile scrivere una nuova strategia personalizzata (supponendo che sei a tuo agio scrivendo Java), ma per ora ho intenzione di attaccare con le impostazioni predefinite per mantenere le cose più facili.

Un anello per domarli tutti...

Normalmente, il modo più semplice per configurare un cluster di Cassandra è di avere più macchine e ovviamente un modo di fare che su un singolo computer portatile è quella di impostare più istanze di macchine virtuali in esecuzione contemporaneamente tutti. Ma che può ottenere ingombrante e amp sui requisiti hardware abbastanza rapidamente, soprattutto se siete uno di quegli sviluppatori che fa tutto fuori un portatile (come me).

Così, il secondo modo per ottenere più nodi è eseguito più volte sulla stessa casella, memorizzazione dei dati in più posizioni e in ascolto su porte diverse presa di Cassandra. Questo significa tuffarsi nel file di configurazione di Cassandra per impostare le impostazioni di configurazione diverse due (o più) e al lancio di ciascuno.

Assumendo una Cassandra 1.1 installazione (la versione più recente a partire da questa scrittura), Cassandra memorizza tutte le sue informazioni di configurazione nella directory /conf. All'interno di tale directory, ci sono due file, in particolare, che è necessario modificare: log4j-server.properties e cassandra.yaml. Ho anche bisogno di capire dove i nodi dati e registri stanno per andare, così andrò avanti e basta creare due sottodirectory sotto la Cassandra directory di installazione. Supponendo che hai installato Cassandra a C:\Prg\apache-cassandra-1.1.0 (come ho fatto), poi per creare due nuove directory sotto che, uno per ogni nodo che si sta andando a creare: C:\Prg\apache-Cassandra-1.1.0\node1 e \node2.

All'interno di quelle due directory, copiare il contenuto della directory /conf Cassandra, che porterà oltre questi due file di cui che avete bisogno. Vuoi anche copiare il file cassandra.bat/bin, perché questo è dove il terzo e ultimo cambiamento dovrà accadere, per raccontare Cassandra di cui ha bisogno per eseguire i file di configurazione sarà.

Questo non è Java roba divertente?

Il primo file, log4j-server.properties, è un file di configurazione per il progetto open source di registrazione diagnostica di log4j. (Java utilizza i file "Properties" molto simile a Windows utilizzato il file "ini" back in the day). Qui il vostro interesse principale è quello di assicurarsi che ciascun nodo Cassandra sta scrivendo un file registro di diagnostica in un luogo diverso rispetto gli altri nodi. Personalmente, voglio che tutti i dati per ogni nodo di essere all'interno di tali directory \node1 e \node2, quindi voglio trovare la riga all'interno di log4j-server.properties che legge come questo:

log4j.appender.R.file=/var/log/Cassandra/System.log

Allora voglio cambiare per saperne qualcosa di più Windows-ish e più \node1-ish, come questo:

log4j.appender.R.file=C:/PRG/Apache-Cassandra-1.1.0/node1/log/System.log

La directory dei log non deve esistere prima dell'avvio di Cassandra, lei crea se non c'è. A proposito, assicurarsi che le barre sono avanti le barre qui fidati di me su questo; lavoreremo. (Java li riconosce se sono avanti o le barre all'indietro, ma la sintassi del file di proprietà usa le barre all'indietro come caratteri della sequenza di escape, come sorta di come funzionano in C# stringhe.)

In secondo luogo, è necessario rompere aprire il file "cassandra.yaml" per rendere il prossimo set di modifiche. La sintassi ".yaml" è "Ancora un altro Markup Language," e, sì, avete indovinato, è un'altra sintassi di configurazione ini-stile. Java non standardizzata, quindi è abbastanza comune vedere i diversi stili di configurazione diversi tutti insieme si componeva in un singolo progetto (come Cassandra).

In particolare, è necessario modificare un paio di impostazioni qui; Questi sono sparsi in tutto il file (che, tra l'altro, è piena di tonnellate di commenti, quindi sono davvero un po' ovvio se letto attraverso tutto):

cluster_name: 'Test Cluster'
data_file_directories:
  - /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog
saved_caches_directory: /var/lib/cassandra/saved_caches
listen_address: localhost
rpc_address: localhost

"Nome_cluster" è opzionale, ma non è una brutta cosa cambiare comunque, forse a qualcosa come "Miocluster" o "Grande Cluster O divertente". Il resto delle impostazioni, tuttavia, bisogno di essere cambiato. Le voci "directories" è necessario scegliere le directory \node1 e \node2, rispettivamente.

Un anello per trovarli tutti...

Le ultime due impostazioni devono essere modificate per motivi diversi. Cassandra, ricordate, istintivamente vuole eseguire come un servizio per ogni macchina, così lei si assume che è OK per associare solo un socket TCP/IP a "localhost". Ma se si hanno due o più servizi in esecuzione sulla stessa macchina, che non sta andando a lavorare. Quindi è necessario dirle di associare gli indirizzi che risolveranno efficacemente la casella stessa, anche se potrebbero essere valori diversi. Fortunatamente, è possibile farlo inserendo esplicitamente 127.0.0.1 per node1, 127.0.0.2 node2 e così via.

(Si potrebbe chiedere perché questo funziona; la risposta è oltre la portata di questo articolo, ma qualsiasi buon riferimento TCP/IP dovrebbe essere in grado di spiegarlo. Se non siete convinti, provate "ping 127.0.0.1" e "ping 127.0.0.2" sulla tua casella. Entrambi devono risolvere bene. Se non ti piace specificare questi valori, si possono sempre assegnare loro i nomi nel file "hosts" nella directory c:\WINDOWS\system32\drivers\etc..)

Parte del motivo che Cassandra ha bisogno di questa configurazione di rete elaborata è perché lei sta andando a "scoprire" l'anello primo connettendosi a un nodo «sementi», che dirà poi tale istanza su altri nodi nell'anello. Questo fa parte del protocollo di gossip che lei utilizza per trasmettere informazioni importanti intorno all'anello. Se stavamo installando l'anello per eseguire su macchine diverse, Cassandra avrebbe bisogno l'impostazione per puntare a un nodo in esecuzione, ma in questo caso di configurazione di "semi" — perché stiamo tutti in esecuzione sulla stessa casella — predefinito 127.0.0.1 funziona bene.

Dopo tutte le modifiche, il file cassandra.yaml in \node1 dovrebbe assomigliare a questo:

cluster_name: 'Test Cluster'
data_file_directories:
  - C:/Prg/apache-cassandra-1.1.0/node1/data
commitlog_directory: C:/Prg/apache-cassandra-1.1.0/node1/commitlog
saved_caches_directory: C:/Prg/apache-cassandra-1.1.0/node1/saved_caches
listen_address: localhost
rpc_address: localhost
For \node2, the file should look like this:
cluster_name: 'Test Cluster'
data_file_directories:
  - C:/Prg/apache-cassandra-1.1.0/node2/data
commitlog_directory: C:/Prg/apache-cassandra-1.1.0/node2/commitlog
saved_caches_directory: C:/Prg/apache-cassandra-1.1.0/node2/saved_caches
listen_address: 127.0.0.2
rpc_address: 127.0.0.2

Infine, Cassandra ha bisogno di essere detto quando lei si avvia dove trovare la configurazione dei file, e normalmente lo fa guardando lungo il percorso di classe Java (che è vagamente simile al meccanismo di risoluzione Assemblea nell'ambito .NET, ma circa una metà decennio più primitiva, ad essere sincero). Anche lei vuole esporre alcuni di gestione e controllo delle informazioni di JMX (Java equivalente a PerfMon o Strumentazione gestione Windows) su una porta TCP/IP, ed entrambi i servizi non possono utilizzare la stessa porta. Pertanto, le modifiche finali devono essere a cassandra.bat:

REM accertarsi che le variabili CLASSPATH definito dall'utente non vengono utilizzate all'avvio

Set CLASSPATH="%CASSANDRA_HOME%\node1"

E per cassandra.bat in \node2:

REM accertarsi che le variabili CLASSPATH definito dall'utente non vengono utilizzate all'avvio

Set CLASSPATH="%CASSANDRA_HOME%\node2"

Così come la seguente riga in \node2:

-Dcom.sun.management.jmxremote.port=7299^

In originale, la porta di leggi "7199."

Come ho detto, questo non è Java roba divertente?

… E nel buio li legano

Ma una volta che tutte le cose di configurazione ottiene fuori strada, inizia il divertimento. Fuoco una finestra di prompt dei comandi (uno con le variabili di ambiente JAVA_HOME e CASSANDRA_HOME verso la radice del JDK e Cassandra directory di installazione, ricordo) e modificare la directory alla directory \node1 tu hai state ingannando fuori. Fuoco spento "cassandra -f" al prompt dei comandi e guardare il rotolo di informazioni diagnostiche di. Questa è la prima istanza, e supponendo che tutte le impostazioni di configurazione sono buoni (errori di battitura), si dovrebbe vedere il testo scorre da e alla fine con "Ascolto per i clienti di risparmio..."

Ora, in una seconda finestra di prompt dei comandi, passare sopra a \node2 e fare la stessa cosa. Questa volta, come gli incendi fino, vedrai anche qualche attività avvengono in pochi minuti nella finestra \node1 — ciò che sta accadendo non c'è che dopo l'istanza di \node2 si alza e in esecuzione, si connette all'istanza di \node1 (il "seme"), e i due essenzialmente configurare vicenda per iniziare a lavorare insieme in un anello. In particolare, cercare le due linee "JOINING: in attesa di informazioni di schema e anello"e"nodo /127.0.0.1 è ora parte del cluster"a vengono visualizzati nella finestra di \node2 e"il nodo /127.0.0.2 è ora parte del cluster"e"/127.0.0.2 InetAddress è ora"nella finestra di \node1.

Ma, se vi siete persi vedendo quei messaggi, Cassandra ha una sorpresa più in serbo per voi. In una terza finestra di prompt dei comandi, passare alla – l'originale Cassandra \bin directory e lanciare "nodetool anello h 127.0.0.1" e si dovrebbe vedere qualcosa come Figura 1.

Figura 1 due istanze di Cassandra, ogni proprietario 50% dei dati

Questo è davvero eccitante roba, perché come si può vedere dalla colonna Owns, le due istanze di Cassandra hanno già capito che ognuno dovrebbe proprio 50% dei dati, senza alcuna configurazione aggiuntiva di lavoro da parte vostra. Dolce!

La parte migliore è, se si esegue il codice dall'articolo precedente, i dati verranno distribuiti attraverso il cluster senza ulteriori modifiche.

È un complemento, non una sostituzione

Come alcuni altri database strumenti questa colonna ha esplorato (MongoDB e SQLite), Cassandra non dovrebbe essere considerato come un sostituto all'ingrosso per un database relazionale, ma come una tecnologia complementare che può essere utilizzato sia per le zone dove la funzione set di un database relazionale proprio non si adatta bene (caching o archiviazione di set di dati altamente strutturati vengono in mente, per esempio), o come un sistema ibrido, in combinazione con un database relazionale. Ad esempio, una società potrebbe memorizzare una serie di "fissa" di elementi di dati in un database relazionale e includere come una delle colonne relazionali una chiave di Cassandra, al fine di recuperare i dati rimanenti, non strutturati. Il database relazionale può rimanere quindi strutturato e relazionale (obbedendo la maggior parte o tutte le regole di forma normale), ma il sistema complessivo avrà ancora la flessibilità necessaria per memorizzare dati aggiuntivi imprevisti elementi che gli utenti sembrano sempre da aggiungere al sistema come età.

Per un altro esempio, considerare la pagina Web ha colpito dati che vuoi sempre essere calettati fuori la pagina stessa, ma sarebbero facilmente traccia in milioni o miliardi di elementi di dati. Un servizio di accorciamento URL (ad esempio bit. ly) sarebbe banale da fare qui, perché il minimo percorso URL (la parte "foobar" in http://bit.ly/foobar) sarebbe la chiave e colpire le statistiche dei dati, nonché una descrizione facoltativa e forse anche uno snapshot periodico di URL di reindirizzamento — sarebbe fatto per Cassandra. E così via.

Cassandra non ha intenzione di assumere il datacenter in qualunque momento presto, né dovrebbe esso. Ma quando viene utilizzato in modo intelligente, è un nuovo potente strumento nella casella degli strumenti, e gli sviluppatori sarebbe sciocchi ignorarlo. C'è molto di più per esplorare su Cassandra, ma è il momento di lasciare la profetessa Trojan andare e passare ad altre cose.

Codifica felice!

Ted Neward è un consulente architettonico con Neudesic LLC. Ha scritto oltre 100 articoli e autore o coautore di una dozzina di libri, tra cui "Professional F # 2.0" (Wrox, 2010). Egli è un F # MVP e noto esperto di Java e a conferenze sia Java e .NET tutto il mondo. Egli consulta e mentors regolarmente — contattarlo al ted@tedneward.com o Ted.Neward@neudesic.com se vuoi lui di venire a lavorare con il vostro team. Ha blog a blogs.tedneward.com e possono essere seguiti su Twitter a twitter.com/tedneward.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Kelly Sommers