Este artículo proviene de un motor de traducción automática.

El programador políglota

Cassandra NoSQL Database, parte 3: Clústeres

Ted Neward

 

Última vez, examiné Apache Cassandra, el "código abierto, distribuido, descentralizado, elásticamente escalable, alta disponibilidad, tolerante, tuneably coherente, base de datos orientada a columna que basa su diseño de distribución en Amazon Dynamo y su modelo de datos en Google Bigtable," como se describe en el libro, "Cassandra: La guía definitiva"(o ' Reilly Media, 2010). Para ser más precisos, habiendo instalado Cassandra (en la primera parte de esta serie), miré cómo al programa de Microsoft .NET Framework, haciendo los bits básicos de lectura y escritura de datos. Nada espectacular.

De hecho, parte de "Espectacular" de Casandra es envuelto en su capacidad inherente de cluster, dando Cassandra fácil escalamiento. Esto significa que puede crecer a tamaños "ridículo" — en la mayoría de los casos con poco o ningún esfuerzo administrativo — especialmente cuando se compara con el trabajo requerido por la mayoría de las bases de datos relacionales para almacenar el tamaños equivalentes. Por ejemplo, una firma de tecnología local aquí en Redmond, Washington. (donde yo vivo), afirmó en un reciente encuentro de inicio que era almacenar más de 50PB de datos en Casandra.

Incluso permitiendo exageración y la hipérbole, apenas una décima parte de eso (5PB, o más de 5, 000TB) es un fragmento bastante considerable de datos. Para ser justos, el sitio Web de Cassandra (cassandra.apache.org) afirma, "El más grande conocido Cassandra clúster tiene más de 300 terabytes de datos en más de 400 máquinas," que sigue siendo bastante difícil hacerlo con una configuración relacional de out of the box.

Pero es la clave para que de almacenamiento del clúster, y mientras que un clúster de ese tamaño en producción es probablemente más allá del alcance de este artículo, por lo menos podemos empezar a jugar con él haciendo un cluster de múltiples nodos que ejecutan para el desarrollo. Se requiere unos pocos pasos, por lo podrá atravesar un paso a la vez. (Por cierto, DataStax tiene una instalación sencilla para Cassandra, pero como cerca como puedo decir carece de la capacidad para configurar un cluster de múltiples nodos en una caja; eso es su único inconveniente que puedo ver hasta el momento.)

Instalar recapitulación

En el primer artículo de esta serie (msdn.microsoft.com/magazine/jj553519), me fui por el dolor (a veces angustioso) de configuración de Cassandra desde el archivo .zip y la línea de comandos: Asegúrese de que esté instalado un runtime de Java y en el camino; Asegúrese de que una variable de entorno JAVA_HOME es configurada; descomprimir la distribución de Cassandra en un directorio; y, a continuación, ejecute el archivo "cassandra.bat" del directorio "bin" a poner el servidor en funcionamiento.

Al tiempo, puede haber parecido realmente anacrónico hacerlo, pero dos cosas positivas provienen de hacer la instalación de esa manera. En primer lugar, obtener algo de experiencia en cómo instalar a un servidor escrito en Java (y que resulta para ser una habilidad muy útil que tiene, cuántos de los diferentes implementaciones de NoSQL están escritas en Java). En segundo lugar, deberás "truco" que la instalación en un nivel bastante bajo para obtener a Cassandra ejecutar varias veces en una sola caja.

Como ves, la noción de Casandra de escalabilidad proviene de un "anillo" de servidores: varias instancias del servicio Casandra que se ejecutan en varias cajas, cada uno almacena una parte del conjunto total de datos. Luego, cuando nuevos datos se escriben en el anillo, Cassandra "cotilleos" (que es el término técnico real para él) entre los distintos nodos en el aro para poner los datos en el lugar adecuado dentro del anillo. En un anillo bien administrado, Cassandra equilibrará los datos entre los nodos uniformemente. Cassandra tiene un número de diferentes estrategias para la escritura de los datos entre los nodos, y siempre es posible escribir una nueva estrategia personalizada (suponiendo que se siente cómodo escribiendo Java), pero por ahora voy a seguir con los valores predeterminados para mantener las cosas más fáciles.

Un anillo para gobernarlos a todos...

Normalmente, la forma más fácil de configurar un clúster de Cassandra es tener varias máquinas y obviamente de una manera de hacer que el portátil solo es para configurar varias instancias de la máquina virtual funcionando todos al mismo tiempo. Pero que pueden llegar poco manejable y amp hasta los requisitos de hardware bastante rápidamente, especialmente si eres uno de esos desarrolladores que hace de todo apaga un ordenador portátil (como yo).

Así, la segunda forma de obtener múltiples nodos es que Cassandra ejecutar varias veces en el mismo cuadro, almacenar los datos en varios lugares y escuchar en los puertos de toma de corriente diferente. Esto significa buceando en los archivos de configuración de Casandra para configurar los ajustes de configuración diferente de dos (o más) y el lanzamiento de cada uno.

Suponiendo que una instalación de Cassandra 1.1 (la última versión a partir de este escrito), Cassandra almacena toda su información de configuración en el directorio /conf. Dentro de ese directorio, hay dos archivos en particular que deba editar: Log4j-server.properties y cassandra.yaml. Tengo que averiguar donde los nodos de datos y registros se van a ir, así que voy a seguir adelante y crear dos subdirectorios bajo el Cassandra directorio de instalación. Asumiendo que ha instalado Cassandra en C:\Prg\apache-cassandra-1.1.0 (como yo), a continuación, desea crear dos nuevos directorios debajo, uno para cada nodo que se va a crear: C:\Prg\apache-Cassandra-1.1.0\node1 y \node2.

Dentro de los dos directorios, copiar el contenido del directorio /conf Cassandra, que traerá sobre esos dos archivos que necesita. También desea copiar el archivo cassandra.bat/bin, ya es donde el cambio tercero y final tendrá que suceder, para decir a Cassandra donde estarán los archivos de configuración que necesita para funcionar.

¿Esto no es divertido de cosas de Java?

El primer archivo, log4j-server.properties, es un archivo de configuración para el proyecto de código abierto de registro de diagnóstico de log4j. (Java utiliza archivos ".properties" al igual que Windows utiliza archivos "ini" en el día). Su principal interés aquí es asegurarse de que cada nodo de Cassandra es escribir un archivo de registro de diagnóstico en un lugar diferente que los otros nodos. Personalmente, quiero que todos los datos de cada nodo para estar dentro de los directorios \node1 y \node2, así que quiero encontrar la línea interior de log4j-server.properties que dice así:

  Log4j.appender.R.File=/var/log/Cassandra/System.log

Entonces quiero cambiarlo para leer algo más Windows-ish y más \node1-ish, como este:

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

El directorio de registro no tiene que existir antes de Cassandra comienza — ella creará si no existe. Por cierto, asegúrese de que las barras estén adelante barras aquí sólo confían en mí en este caso; trabajará. (Java les reconoce si están adelante o barras inclinadas hacia atrás, pero la sintaxis del archivo de propiedades utiliza barras inclinadas hacia atrás como caracteres de la secuencia de escape, algo así como cómo funcionan en las cadenas de C#).

En segundo lugar, necesita crack abrir el archivo "cassandra.yaml" para hacer el siguiente conjunto de cambios. La sintaxis de ".yaml" es "Todavía otro lenguaje de marcado," y, sí, lo has adivinado — es otra sintaxis de configuración INI-estilo. Java nunca estandarizado en esto, así que es bastante común ver varios estilos de diversa configuración todos los siameses juntos en un solo proyecto (como Cassandra).

Específicamente, usted necesita cambiar un par de ajustes aquí; Estos se encuentran dispersos en todo el archivo (que, por cierto, está plagado de toneladas de comentarios, por lo que son realmente algo explica por sí mismo si usted lee a través de todo):

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

El "nombre_clúster" es opcional, pero no es una mala cosa para cambiar de todos modos, quizá a algo como "MiClúster" o "Gran Cluster O divertido". El resto de los ajustes, sin embargo, deben cambiarse. Las entradas de "directorios" necesitan apuntar a los directorios \node1 y \node2, respectivamente.

Un anillo para encontrarlos todos...

Los dos últimos ajustes deben cambiarse por diferentes razones. Cassandra, recuerde, instintivamente quiere ejecutar como un servicio por la máquina, por lo que ella asume que es aceptar simplemente enlazar un socket TCP/IP a "localhost". Pero si usted tiene dos o más servicios que se ejecutan en el mismo cuadro, que no va a funcionar. Por lo que necesita para decirle a enlazar a las direcciones que efectivamente se resolverán en el mismo cuadro, aunque sean diferentes valores. Afortunadamente, usted puede hacerlo poniendo explícitamente 127.0.0.1 para node1, 127.0.0.2 para Nodo2 y así sucesivamente.

(Usted podría estar preguntando por qué esto funciona; la respuesta está fuera del alcance de este artículo, pero cualquier buena referencia de TCP/IP debe ser capaz de explicarlo. Si no estás convencido, trate de "ping 127.0.0.1" y "ping 127.0.0.2" en su caja. Ambos deben resolver muy bien. Si no desea especificar estos valores, puede siempre asignar ellos nombres en el archivo "hosts" en el directorio C:\Windows\System32\drivers\etc.)

Parte de la razón que Cassandra necesita esta configuración de red funcionó es porque va a "descubrir" el anillo conectando primero a un nodo de "semilla", que luego dirá esa instancia sobre los otros nodos en el ring. Todo esto forma parte del Protocolo el chisme que ella utiliza para transmitir información importante alrededor del anillo. Si estábamos configurando el anillo para ejecutar a través de diferentes máquinas, Cassandra tendría la configuración de "semillas" para señalar a un nodo de ejecución, pero en este caso, porque nos estamos quedando en la misma caja — el defecto 127.0.0.1 funciona muy bien.

Después de todos los cambios, el archivo cassandra.yaml en \node1 debe tener el siguiente aspecto:

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

Por último, Cassandra debe ser informado cuando ella inicia donde encontrar la configuración de archivos, y normalmente lo hace mirando a lo largo de la ruta de clases de Java (que es vagamente similar al mecanismo de resolución de la Asamblea en .NET Framework, sino un lustro más primitivos, para ser franco). Ella también quiere exponer algunos gestión y seguimiento de la información se JMX (Java equivalente a PerfMon o Windows Management Instrumentation) en un puerto TCP/IP, y ambos servicios no pueden utilizar el mismo puerto. Así, los cambios finales tienen que ser cassandra.bat:

  REM Asegúrese que no se utilizan las variables de ruta de clases definidas por el usuario durante el inicio
set CLASSPATH="%CASSANDRA_HOME%\node1"

Y para el cassandra.bat en \node2:

  REM Asegúrese que no se utilizan las variables de ruta de clases definidas por el usuario durante el inicio
set CLASSPATH="%CASSANDRA_HOME%\node2"

Así como la siguiente línea en \node2:

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

En el original, el puerto se leerá "7199."

¿Como he dicho, no es este divertido de cosas de Java?

… Y en la oscuridad, enlazarlos.

Pero una vez que todas las cosas de configuración se obtiene fuera del camino, comienza la diversión. Fuego hasta una ventana de línea de comandos (uno con variables de entorno JAVA_HOME y CASSANDRA_HOME apuntando a la raíz del JDK y Cassandra directorios de instalación, recuerde) y cambie el directorio el directorio de \node1 que has sido engañando a. Fuego apagado "cassandra -f" en el símbolo del sistema y ver el desplazamiento de la información diagnóstico. Esta es la primera instancia, y suponiendo que todas las configuraciones son buenas (no errores tipográficos), verá el texto desplazarse y terminar con "Listening para clientes de ahorro..."

Ahora, en una segunda ventana de línea de comandos, desplácese sobre a \node2 y hacer lo mismo. Esta vez, como que se dispara hacia arriba, también verá alguna actividad ocurrir en pocos minutos en la ventana de \node1 — lo que está ocurriendo allí es que después levanta la instancia de \node2 y funcionando, se conecta a la instancia de \node1 (la "semilla"), y los dos esencialmente configuración mutuamente para empezar a trabajar juntos en un anillo. En particular, busque las dos líneas "Unión: esperando información de esquema y anillo"y"nodo /127.0.0.1 es ahora parte del clúster"aparecen en la ventana de \node2 y"nodo /127.0.0.2 es ahora parte del clúster"y"InetAddress /127.0.0.2 toca ahora"en la ventana de \node1.

Pero, si te perdiste ver esos mensajes, Cassandra tiene más de una sorpresa para ti. En una tercera ventana de línea de comandos, vaya a la original Cassandra \bin directorio y lanzamiento "nodetool anillo diferencian 127.0.0.1", y usted debería ver algo como figura 1.

Figura 1 dos instancias de Cassandra, cada propietario del 50 por ciento de los datos

Esto es realmente emocionante cosas, porque como se puede ver en la columna de 3.owns, las dos instancias de Cassandra ya han averiguado que cada uno debe trabajar propio 50 por ciento de los datos, sin ninguna configuración adicional de su parte. Dulce!

La mejor parte es, si ejecuta el código desde el artículo anterior, los datos se extenderá a través del clúster sin cambios adicionales.

Es un complemento, no un reemplazo

Como parte de la base de datos de herramientas esta columna ha explorado (MongoDB y SQLite), Cassandra no debería considerarse como un reemplazo por mayor para una base de datos relacional, pero como una tecnología complementaria que puede ser utilizado tanto para zonas donde la función de una base de datos relacional simplemente no encaja bien (caché o almacenar conjuntos de datos altamente estructurados vienen a la mente, por ejemplo), o como un sistema híbrido, junto con una base de datos relacional. Por ejemplo, una empresa podría almacenar un conjunto de elementos de datos "fijo" en una base de datos relacional e incluye como una de las columnas relacionales una clave de Casandra, con el fin de recuperar los datos restantes, no estructurados. La base de datos relacional puede quedará estructurado y relacional (obedeciendo la mayoría o todas las reglas de forma normal), pero el sistema global tendrá la flexibilidad para almacenar elementos de datos inesperados adicionales que los usuarios siempre parecen querer agregar al sistema ya que las edades.

Otro ejemplo, considere la posibilidad de página Web golpear los datos, que podrían ser manipulados siempre fuera de la propia página, sin embargo, serían dar seguimiento fácilmente en los millones o miles de millones de elementos de datos. Un servicio de acortamiento de URL (como bit.ly) sería trivial hacerlo aquí, porque la ruta de URL minimizada (la parte "foobar" en http://bit.ly/foobar) sería la clave y golpear estadísticas de datos — así como una descripción opcional y quizás una instantánea periódica del URL redirigida — se hiciera por Cassandra. Y así sucesivamente.

Cassandra no va a asumir el datacenter en el corto plazo, ni en caso de que. Pero cuando se utiliza de manera inteligente, es una poderosa herramienta nueva en el cuadro de herramientas, y los desarrolladores sería tontos a ignorarlo. Hay mucho más para explorar sobre Cassandra, pero es hora de dejar la profetisa troyana ir y pasar a otras cosas.

Feliz codificación!

Ted Neward es una consultora de arquitectura con Neudesic LLC. Ha escrito más de 100 artículos y autor o coautor de una docena de libros, incluyendo "Profesional F # 2.0" (Wrox, 2010). Es un F # MVP y destacado experto de Java y habla en Java y .NET conferencias alrededor del mundo. Consulta y mentores regularmente — llegar a él en ted@tedneward.com o Ted.Neward@neudesic.com si gustaría que venir a trabajar con su equipo. Blogs de él en blogs.tedneward.com y se puede seguir en Twitter en twitter.com/tedneward.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Kelly Sommers