Estas en: Home > super

Entradas etiquetadas con super

Logo Cassandra

Cassandra 2.x y PHP para desarrolladores SQL: El modelo de datos

0
hace 7 años
by Mikel en

Si has trabajado con una base de datos relacional tal vez te resulte algo confuso al principio comprender el modelo de datos que usa Cassandra, intentaré ser lo más claro posible, pero si te surgen preguntas no dudes en dejarlas en los comentarios.

 

Columns

El elemento más básico de la base de datos Cassandra es la columna, se compone de tres elementos: nombre de la columna, valor y timestamp. Os muestro un ejemplo como un array:

array(
  "nombre" => "email",
  "valor" => "webmaster@localhost.com",
  "timestamp" => time(),
);

Cassandra añade el timestamp automáticamente, con lo que otra forma de representarlo es como un conjunto clave:valor:

nombre_columna:valor

Super columnas (En desuso) y Columnas Compuestas

Las super columnas son un conjunto de columnas con sus correspondientes valores:

array(
  "nombre_superColumna" => array(
    "usuario1" => array(
      "nombre" => "email",
      "valor" => "webmaster@localhost.com",
      "timestamp" => time()
    ),
    "usuario2" => array(
      "nombre" => "email",
      "valor" => "email@email.com",
      "timestamp" => time()
    ),
    "usuario3" => array(
      "nombre" => "email",
      "valor" => "otroemail@otroemail.com",
      "timestamp" => time()
    ),
  ),
)

Las super columnas tienen algunos problemas de rendimiento, sobre todo al ordenarlas. Para solucionarlo se crearon las columnas compuestas que se benefician de los comparadores compuestos, y sobretodo, de CQL 3 (Cassandra Query Language).

Familia de columnas

Es el conjunto de columnas o super columnas. Me explico:

Las column Family o  familia de columnas se puede configurar de dos maneras: como Super o como Standard. Si se elige la opción Standard, en la column family solo se podrán guardar columnas, no super columnas. En cambio si la column family está configurada como Super podrá guardar, además de las columnas, las super columnas. Esta flexibilidad permite jugar con la base de datos y adaptarla a nuestras necesidades.

Ejemplo:

array(
  "name" => "ColumnFamily",
  array( "name" => "SuperColumn",
    array( "colums" )
  ),
)

Keyspace

El keyspace es nuestra base de datos, donde alojaremos todas las columFamilies que necesitemos.

Ejemplo:

array(
  "name" => "keyspace",
  array("name" => "columnFamily",
    array(
      [...]
    ),
  ),
)
Logo Cassandra

Cassandra 1.x y PHP para desarrolladores SQL: phpCassa (III)

4
hace 11 años
by Mikel en

Ya he tratado casi en su totalidad las funciones más básicas de PHPCassa y Cassandra, con lo que ya tendrás un conocimiento suficientemente amplio de lo que se puede hacer con ellos, el resto dependerá de la evolución de la BD y de las librerías (y de la experiencia que tengas xP).

Hoy trataré varios temas que por las consultas realizadas por varios usuarios se merece un post aparte en el que se pueda tratar de una forma más amplia. Estos temas son: ordenar registros, crear keys para los registros y contar registros.

 

ORDENAR REGISTROS

Cassandra dispone de varios tipos de comparadores y subcomparadores para ordenar los registros. El más habitual es UTF-8 pero hay varios más. Si vamos a Cassandra Cluster Admin y accedemos al formulario de creación de columns family, podremos pasar el ratón por los interrogantes que hay a la izquierda de los campos para poder ver los diferentes tipos de comparadores:

Tipos de comparadores

Tipos de comparadores

Como puedes ver, estos comparadores le dicen a Cassandra como ordenar los registros. Si has seguido este tutorial ya conocerás al menos uno de los comparadores (utf-8) por tanto vamos a ver como ordena Cassandra los registros con este comparador.

Para este primer ejemplo vamos a crear una column family llamada column_family_order_utf8 de tipo standard y el tipo de comparador UTF8Type.

Vamos a nuestro archivo test.php y escribimos el siguiente código:

[codesyntax lang=»php»]

<?php

$data = array();
$data[5] = array(
    'title' => 'Apache Cassandra',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[3] = array(
    'title' => 'MongoDB',
    'license' => 'Open Source',
    'category' => 'no-sql'
);
$data[1] = array(
    'title' => 'Neo4j',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[4] = array(
    'title' => 'MySQL',
    'license' => 'Open Source',
    'category' => 'sql'
);
$data[2] = array(
    'title' => 'MariaDB',
    'license' => 'Open Source',
    'category' => 'sql',
);

foreach($data as $key => $value){
  $cass->guardar('column_family_order_utf8', $key, $value);
}

[/codesyntax]

Este código guardará un array desordenado en nuestra column family. Una vez ejecutado el script accedemos a Cassandra Cluster Admin y visualizamos los registros de column_family_order_utf8, nos mostrará el siguiente resultado:

Listado de los registros guardados

Listado de los registros guardados

Como puedes observar los registros no se han ordenado, sin embargo cada una de las columns de cada registro sí están ordenadas por orden alfabético. Esto sucede porque los comparadores no ordenan por keys o claves de los registros sino por columns, aunque hay un caso especial, si la column family es super los registros si estarán ordenados. Veamoslo.

Creamos una column family llamada column_family_utf8_super con el tipo de comparador UTF8Type y el tipo de column family como super. En nuestro archivo test.php añadimos el siguiente código:

[codesyntax lang=»php»]

<?php

$data = array();
$data[5] = array(
    'title' => 'Apache Cassandra',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[3] = array(
    'title' => 'MongoDB',
    'license' => 'Open Source',
    'category' => 'no-sql'
);
$data[1] = array(
    'title' => 'Neo4j',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[4] = array(
    'title' => 'MySQL',
    'license' => 'Open Source',
    'category' => 'sql'
);
$data[2] = array(
    'title' => 'MariaDB',
    'license' => 'Open Source',
    'category' => 'sql',
);

$cass->guardar('column_family_order_utf8_super', 'databases', $data);

[/codesyntax]

Una vez ejecutado este script nos vamos a nuestra column family y nos mostrará lo siguiente:

Listado de registros en la column family

Listado de registros en la column family

Como puedes observar ahora sí están ordenados los registros, pero claro ahora están dentro de una super column.

En Cassandra la ordenación se realiza a las columnas del registro o los registros dentro de las super columns, si creasemos otra super column, esta no se ordenaría con respecto a la ya creada, ‘databases’.

Aunque esta ordenación puede ser útil y totalmente funcional, para los desarrolladores que vengan de las bases de datos relacionales les puede resultar confuso. Por ejemplo, para guardar los comentarios de un post de un blog podríamos utilizar este tipo de ordenación perfectamente, ya que podemos utilizar el id del post como key de la super column (el ‘databases’ de la imagen anterior se sustituiría por el id del post) y el timestamp (como este 1337787675.32246500) para la key de los registros. De esta forma tendríamos ordenados los comentarios por tiempo y por post. Si quisieramos recuperar los comentarios de un post concreto solo tendríamos que pasarle al método correspondiente el id del post como key de la super column.

¿Y si quisieramos guardar los post del blog? En este caso una column family super nos lo podría resolver indicando como key de la super column ‘posts‘  y utilizando como key en los registros el timestamp. Pero si quisieramos hacer busquedas utilizando indices secundarios una column family super no nos valdría, ya que los indices secundarios no funcionan en ellas.

Para ello habría que crear una column family standard para los post, que nos permitirá usar los indices secundarios, y una column family super para guardar las keys de los post dentro de una super column con key, por ejemplo, ‘key_posts‘. Para hacer la consulta habría que recuperar las keys de los posts a mostrar en primer lugar, y después, utilizando un método de PHPCassa que aun no hemos usado recuperar los registros correspondientes a esas keys.

El método que deberíamos añadir a nuestro archivo cassandra.php sería el siguiente:

 

[codesyntax lang=»php»]

<?php

  function obtenerMultiplesRegistros($name_columnFamily, $multiKeys, $super_column = ''){

      if (!empty($super_column)){
        $column_family = new SuperColumnFamily($this->conexion, $name_columnFamily);
        $result = $column_family->multiget_super_column($multiKeys, $super_column);
      }
      else{
        $column_family = new ColumnFamily($this->conexion, $name_columnFamily); 
        $result = $column_family->multiget($multiKeys);
      }

      return $result;

  }

[/codesyntax]

 

A este método le pasamos el nombre de la column family standard donde hemos guardado los posts y un array con las keys a recuperar, nos devolverá un array con los datos de cada uno de los posts que le hemos pedido… y en el orden en el que le hayamos pasado las keys a recuperar.

Existe otra forma de ordenar registros, pero además de que en versiones posteriores de Cassandra desaparecerá y provoca problemas de rendimiento, yo no la recomiendo, ya que pierdes todos los beneficios que ofrece Cassandra. Aun así os dejo un link para que le echéis un ojo xD:

http://ria101.wordpress.com/2010/02/22/cassandra-randompartitioner-vs-orderpreservingpartitioner/

Y os dejo otro link para que tengais algo más de información respecto a ordenar registros en Cassandra:

http://ayogo.com/blog/2010/04/09/sorting-in-cassandra/

 

CREAR CLAVES O KEYS PARA LOS REGISTROS

Como has podido ver en el apartado anterior, para ordenar los registros es muy importante tener una key de cada registro que sea única y siempre vaya en orden. Esto las bases de datos relacionales nos lo dan ya hecho, sin embargo en las bases de datos no-sql esto no es así.

Las bases de datos no-sql se crearon para optimizar la lectura y escritura de los registros en la base de datos, esto provocó que algunas funcionalidades muy útiles en las bases relaciones no tuvieran cabida en las no-sql. Por tanto para mantener en orden los registros debemos crear nosotros nuestras propias claves.

PHPCassa dispone de un método para crear una clave aleatoria basada en el timestamp.

Para utilizarla primero añadiremos la clase a nuestra lista:

[codesyntax lang=»php» highlight_lines=»11″]

<?php

use phpcassa\Connection\ConnectionPool;
use phpcassa\ColumnFamily;
use phpcassa\SuperColumnFamily;
use phpcassa\ColumnSlice;
use phpcassa\SystemManager;
use phpcassa\Schema\StrategyClass;
use phpcassa\Index\IndexExpression;
use phpcassa\Index\IndexClause;
use phpcassa\UUID;

[/codesyntax]

Ahora crearemos un nuevo método en nuestro archivo cassamdra.php que devolverá la clave:

 

[codesyntax lang=»php»]

<?php

  public function obtenerUuid(){

      $util = new UUID;

      return $util->import($util->uuid1());
  }

[/codesyntax]

 

Como me está quedando un post muy largo os voy a dejar algo de deberes xD. Sería interesante probarlo tanto con column families standard y super, además de con un tipo de comparador UTF8Type y TimeUUIDType.

Como el chorro de letras y números que devuelve es muy poco legible yo suelo utilizar mi propio sistema de claves, normalmente utilizo el microtime() de php y un par de ids de lo que se esté guardando: el id del usuario, el id de lo que se ha creado, etc. Algo que lo diferencie del resto. Para la clave primero pongo los segundos que devuelve microtime() y después los microsegundos. Para que os hagais una idea sería algo así:

$key = $segundos . ‘.’ . $microsegundos . ‘_’ . $id_post . ‘_’ . $id_usuario;

De esta forma le estamos dando una clave para los ejemplos del anterior apartado, más concretamente para los comentarios en un post.

 

CONTAR REGISTROS

El último apartado de este post. Contar registros. Esto es algo que Cassandra no lleva muy bien, sobre todo con grandes cantidades de información.

Cassandra cuando recibe una petición de lectura/escritura utiliza unas tablas en memoria llamadas memtables (el que le puso el nombre de rompió la cabeza pensando). Cuantas más peticiones reciba Cassandra más memtables creará, de esta forma permitirá una cierta consistencia de la información almacenada en la base de datos.

Cuando le pedimos a phpCassa que nos devuelva el número de registros en una column family o en una super column concreta, lo que está haciendo en realidad es hacer una petición a Cassandra de todos los registros que haya en la column family o en la super column. Cuando esto ocurre Cassandra guardará estos registros en la RAM del servidor antes de enviarlos a phpCassa, y sí Cassandra no cuenta los registros, porque no está pensada para eso, es phpCassa la que cuenta los registros y te devuelve el número concreto.

El método que utiliza phpCassa para contar registros es el que os muestro a continuación, dentro de un método para añadir al archivo cassandra.php:

 

[codesyntax lang=»php»]

<?php

  public function contar_registros($name_columnFamily, $key, $super_column='', $range_start='', $range_end=''){

      $column_slice = new ColumnSlice($range_start, $range_end);

      if (!empty($super_column)){
        $column_family = new SuperColumnFamily($this->conexion, $name_columnFamily);
        $result = $column_family->get_subcolumn_count($key, $super_column, $column_slice);
      }
      else{
        $column_family = new ColumnFamily($this->conexion, $name_columnFamily); 
        $result = $column_family->get_count($key, $column_slice);
      }

      return $result;

  }

[/codesyntax]

 

Esta forma de contar registros provoca que Cassandra consuma todos los recursos de RAM del servidor, con lo que no os la recomiendo.

La mejor manera de contar registros con Cassandra es utilizar una column family con contadores, de tal forma que en nuestro código cada vez que se guarde un registro en la bd se aumente el contador que lleva la cuenta de los registros guardados. En el caso de que se eliminen, habría que disminuirlo. Y en el caso de que el registro se esté actualizando controlar que no aumente el contador xD.

Cualquier duda que tengais intentaré responderla lo mejor posible en los comentarios.

Logo Cassandra

Cassandra 1.x y PHP para desarrolladores SQL: Cassandra Cluster Admin, el phpMyAdmin de Cassandra

3
hace 11 años
by Mikel en

En el anterior post expliqué el funcionamiento de la consola de Cassandra y como trabajar con ella. En este post explicaré como hacer lo mismo de una forma más rápida y fácil.

La razón de que no haya empezado ha explicar como se utiliza Cassandra desde PHP, es que primero hay que conocer cómo funciona Cassandra, su modelo de datos (que ya hemos visto) y algunos comandos básicos para ir aprendiendo a guardar y recuperar datos. El próximo post ya trataré el funcionamiento de PHPCassa y empezaremos a programar.

Este post será bastante ligerito. Explicaré principalmente como hacer lo mismo que hicimos por consola pero de modo gráfico. CassAdmin, como yo le llamo, tiene más opciones de edición para los keyspaces y column families de los que vamos a ver (igual que ocurría con la consola), pero solo tocaremos las opciones más habituales.

 

INSTALACIÓN

Lo típico en estos casos. Descargar. Descomprimir y ejecutar. Descargamos los archivos desde el repositorio de git: https://github.com/sebgiroux/Cassandra-Cluster-Admin, o a través de git o como archivo comprimido. Como más te guste.

Proceso para descargar Cassandra Cluster Admin

Página de descargas del administrador

Ahora descomprimimos a una carpeta dentro de nuestro servidor web, ya que trabajamos con una aplicación programada en PHP.

Si tienes Cassandra instalado en otro equipo que no sea en local, una máquina virtual por ejemplo, tendrás que cambiar la ip a la que se conecta cassAdmin. Es bastante sencillo. Para ello debes modificar el archivo includes/config.inc.php y sustituir la ip de localhost (127.0.0.1)  por la ip del equipo en el que tengas instalado Cassandra:

Archivo config.inc.php

Como verás en la captura, yo utilizo la ip local 192.168.1.10 que pertenece a una máquina virtual. Si tuviera instalado Cassandra en  el mismo equipo la ip a la que debería apuntar sería 127.0.0.1. El puerto no lo modificamos.

Una vez instalado y configurado (si fuese el caso) probamos a acceder desde nuestro navegador. Debería mostrarte algo como esto:

Página principal de Cassandra Cluster Admin

CREAR KEYSPACES

Como has podido ver, en la página principal del administrador ya aparece un keyspace, llamado system, perteneciente a Cassandra, con lo que lo mantendremos como está.

Justo encima tenemos un botón para crear un nuevo keyspace (Create a new keyspace). Lo pulsamos.

Formulario para crear un keyspace

Solo nos pide tres parámetros a rellenar:


Keyspace name: El nombre del keyspace a crear.
Replication factor: Es el número de servidores o instancias de Cassandra de los que se debe guardar un registro u obtener una respuesta al recuperar algún registro.
Strategy: Es la estrategia que seguirá Cassandra para guardar los datos. En el caso de tener varios servidores o centro de datos diferenciados entre sí, se aplicará una estrategia u otra para que los datos no se pierdan. Más info: http://answers.oreilly.com/topic/2408-replica-placement-strategies-when-using-cassandra/ 

En nuestro caso escribiremos los siguientes valores:

Formulario para crear un keyspace con datos

Pulsamos en Create keyspace y nos llevará a la página principal:

Página principal mostrando el keyspace que acabamos de crear

Pulsamos sobre el keyspace que acabamos de crear y nos llevará a la siguiente página:

Página de detalle del keyspace my_keyspace

Aquí podemos ver información relativa al keyspace y al anillo (o cluster) en el que se encuentra guardado. También nos permite editar el keyspace o eliminarlo, pero la opción más interesante es la de crear nuevas column families (Create a new column family).

 

CREAR UNA COLUMN FAMILY

Dentro del keyspace pulsamos sobre el botón Create a new column family, nos mostrará lo siguiente:

Formulario para crear una column family

 

Primero crearemos una column family standard con los siguientes datos:

Datos para crear la primera column family

Para crear una column family solo son necesarios tres parámetros:


Column Family Name: El nombre de la column family que vamos a crear.
Column Type: El tipo de column family que vamos a crear (Standard o Super).
Comparator Type: El comparador principal de las columnas. Es decir, la codificación que tendrán los datos dentro de la column family.

Pulsamos en Create Column Family y en la página de nuestro keyspace se habrá añadido una nueva column family:

Detalle de la column family creada

 

AÑADIR REGISTROS A UNA COLUMN FAMILY STANDARD

Ahora toca guardar registros en la BD.
Como comenté en post anteriores Cassandra no necesita conocer los campos de las tablas (nuestras column families) ya que los creamos cada vez que añadimos un registro.

Primero en la página principal del keyspace haz click en el nombre de la column family. Te aparecerá lo siguiente:

 

Detalle de la página principal de la column family creada

En esta página te aparecerá, además de la información referente a la column family, los siguientes botones:


Browse Data: Para mostrar un listado de los registros que contiene la column family.
Create Secondary Index: Para crear indices secundarios. Parecido a los indices de MySQL.
Get Key: Para buscar una clave o registro concreto.
Insert Row: Para insertar un nuevo registro.
Edit Column Family: Para editar los parámetros de la column family.
Truncate Column Family: Para eliminar los registros de la column family sin eliminar esta.
Drop Column Family: Para eliminar la column family y su contenido.

Pulsamos en Insert Row. Nos aparecerá lo siguiente:

Formulario para insertar registros

Siempre que añadamos un nuevo registro deberemos indicar una key diferente que deberá ser única, sino cassAdmin pensará que lo que quieres hacer es actualizar ese registro. Añadimos los siguientes datos al formulario:

Formulario para insertar registros con datos

 

Para añadir otra fila de cuadro de texto solo tienes que pulsar el botón Add…
Volvemos a la página principal de la column family y pulsamos en Browse Data. Aquí veremos un listado con los registros que hayamos añadido:

 

Listado de registros

 

CREAR UNA COLUMN FAMILY SUPER Y AÑADIR REGISTROS

El proceso para crear una column family Super es idéntico a las column family Standard, solo hay que cambiar un valor a la hora de crearla:

Creación de una column family Super

Entramos en la página principal de la nueva column family y pulsamos en Insert Row. Aquí veremos que el formulario a cambiado un poco, nos aparece un nuevo campo llamado Super Column Name y un nuevo botón encima del formulario, Add Super Column:

Formulario para insertar registros de una column family super

Las column family Super son como las muñecas matrioskas, esas figuras que si las abrías había otra igual dentro, y dentro de esa otra más, y otra, etc. Algo parecido sucede con estas column family. Disponemos de una key (nuestra primera matrioska) que contiene a las super columns (segunda matrioska), que a su vez contienen las columnas clave:valor.

Añadamos un registro para verlo:

Datos para crear una super column

Si nos vamos a Browse Data:

Listado de registros en una column family Super

Como ves, ahora las columns se agruparían dentro de la super column. Añadiré más registros para que lo veas mejor:

Listado de registros en una column family Super

¿Ves? Las keys agrupan a las super columns y estas a su vez a las columns.

 

Creo que esto es suficiente para que conozcas el funcionamiento de Cassandra Cluster Admin. Quedarían algunas cosillas, como editar registros, hacer búsquedas o eliminar registros, pero eso es bastante sencillo (a excepción de las Secondary Index y las Counter Columns que trataré más adelante).

Para cualquier duda o problema déjala en los comentarios.

Logo Cassandra

Cassandra 1.x y PHP para desarrolladores SQL: El modelo de datos

5
hace 11 años
by Mikel en

Si has trabajado con una base de datos relacional tal vez te resulte algo confuso al principio comprender el modelo de datos que usa Cassandra, intentaré ser lo más claro posible, pero si te surgen preguntas no dudes en dejarlas en los comentarios.

 

Columnas

El elemento más básico de la base de datos Cassandra es la columna, se compone de tres elementos: nombre de la columna, valor y timestamp. Os muestro un ejemplo como un array:

array(
  "nombre" => "email",
  "valor" => "webmaster@localhost.com",
  "timestamp" => time(),
);

 

Super columnas

Es el conjunto de columnas con sus correspondientes valores:

array(
  "nombre_superColumna" => array(
    "usuario1" => array(
      "nombre" => "email",
      "valor" => "webmaster@localhost.com",
      "timestamp" => time()
    ),
    "usuario2" => array(
      "nombre" => "email",
      "valor" => "email@email.com",
      "timestamp" => time()
    ),
    "usuario3" => array(
      "nombre" => "email",
      "valor" => "otroemail@otroemail.com",
      "timestamp" => time()
    ),
  ),
)

 

Familia de columnas

Es el conjunto de columnas o super columnas. Me explico:

Las column Family o  familia de columnas se puede configurar de dos maneras: como Super o como Standard. Si se elige la opción Standard, en la column family solo se podrán guardar columnas no super columnas. En cambio si la column family está configurada como Super podrá guardar, además de las columnas, las super columnas. Esta flexibilidad permite jugar con la base de datos y adaptarla a nuestras necesidades.

Ejemplo:

array(
  "name" => "ColumnFamily",
  array( "name" => "SuperColumn",
    array( "colums" )
  ),
)

Keyspace

El keyspace es nuestra base de datos, donde alojaremos todas las columFamilies que necesitemos.

Ejemplo:

array(
  "name" => "keyspace",
  array("name" => "columnFamily",
    array(
      [...]
    ),
  ),
)
Logo Cassandra

Cassandra y PHP para desarrolladores SQL: phpCassa (III)

0
hace 11 años
by Mikel en

Ya he tratado casi en su totalidad las funciones más básicas de phpCassa y Cassandra, con lo que ya tendrás un conocimiento suficientemente amplio de lo que se puede hacer con phpCassa y Cassandra, el resto dependerá de la evolución de la BD y de las librerías (y de la experiencia que tengas xP).

Hoy trataré varios temas que por las consultas realizadas por varios usuarios se merece un post aparte en el que se pueda tratar de una forma más amplia. Estos temas son: ordenar registros, crear keys para los registros y contar registros.

 

ORDENAR REGISTROS

Cassandra dispone de varios tipos de comparadores y subcomparadores para ordenar los registros. El más habitual es UTF-8 pero hay varios más. Si vamos a Cassandra Cluster Admin y accedemos al formulario de creación de columns family, podremos pasar el ratón por los interrogantes que hay a la izquierda de los campos para poder ver los diferentes tipos de comparadores:

Tipos de comparadores

Tipos de comparadores

Como puedes ver, estos comparadores le dicen a Cassandra como ordenar los registros. Si has seguido este tutorial ya conocerás al menos uno de los comparadores (utf-8) por tanto vamos a ver como ordena Cassandra los registros con este comparador.

Para este primer ejemplo vamos a crear una column family llamada column_family_order_utf8 de tipo standard y el tipo de comparador UTF8Type.

Vamos a nuestro archivo test.php y escribimos el siguiente código:

[codesyntax lang=»php»]

<?php

$data = array();
$data[5] = array(
    'title' => 'Apache Cassandra',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[3] = array(
    'title' => 'MongoDB',
    'license' => 'Open Source',
    'category' => 'no-sql'
);
$data[1] = array(
    'title' => 'Neo4j',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[4] = array(
    'title' => 'MySQL',
    'license' => 'Open Source',
    'category' => 'sql'
);
$data[2] = array(
    'title' => 'MariaDB',
    'license' => 'Open Source',
    'category' => 'sql',
);

foreach($data as $key => $value){
  $cass->guardar('column_family_order_utf8', $key, $value);
}

[/codesyntax]

Este código guardará un array desordenado en nuestra column family. Una vez ejecutado el script accedemos a Cassandra Cluster Admin y visualizamos los registros de column_family_order_utf8, nos mostrará el siguiente resultado:

Listado de los registros guardados

Listado de los registros guardados

Como puedes observar los registros no se han ordenado, sin embargo cada una de las columns de cada registro sí están ordenadas por orden alfabético. Esto sucede porque los comparadores no ordenan por keys o claves de los registros sino por columns, aunque hay un caso especial, si la column family es super los registros si estarán ordenados. Veamoslo.

Creamos una column family llamada column_family_utf8_super con el tipo de comparador UTF8Type y el tipo de column family como super. En nuestro archivo test.php añadimos el siguiente código:

[codesyntax lang=»php»]

<?php

$data = array();
$data[5] = array(
    'title' => 'Apache Cassandra',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[3] = array(
    'title' => 'MongoDB',
    'license' => 'Open Source',
    'category' => 'no-sql'
);
$data[1] = array(
    'title' => 'Neo4j',
    'license' => 'Open Source',
    'category' => 'no-sql',
);
$data[4] = array(
    'title' => 'MySQL',
    'license' => 'Open Source',
    'category' => 'sql'
);
$data[2] = array(
    'title' => 'MariaDB',
    'license' => 'Open Source',
    'category' => 'sql',
);

$cass->guardar('column_family_order_utf8_super', 'databases', $data);

[/codesyntax]

Una vez ejecutado este script nos vamos a nuestra column family y nos mostrará lo siguiente:

Listado de registros en la column family

Listado de registros en la column family

Como puedes observar ahora sí están ordenados los registros, pero claro ahora están dentro de una super column.

En Cassandra la ordenación se realiza a las columnas del registro o los registros dentro de las super columns, si creasemos otra super column, esta no se ordenaría con respecto a la ya creada, ‘databases’.

Aunque esta ordenación puede ser útil y totalmente funcional, para los desarrolladores que vengan de las bases de datos relacionales les puede resultar confuso. Por ejemplo, para guardar los comentarios de un post de un blog podríamos utilizar este tipo de ordenación perfectamente, ya que podemos utilizar el id del post como key de la super column (el ‘databases’ de la imagen anterior se sustituiría por el id del post) y el timestamp (como este 1337787675.32246500) para la key de los registros. De esta forma tendríamos ordenados los comentarios por tiempo y por post. Si quisieramos recuperar los comentarios de un post concreto solo tendríamos que pasarle al método correspondiente el id del post como key de la super column.

¿Y si quisieramos guardar los post del blog? En este caso una column family super nos lo podría resolver indicando como key de la super column ‘posts‘  y utilizando como key en los registros el timestamp. Pero si quisieramos hacer busquedas utilizando indices secundarios una column family super no nos valdría, ya que los indices secundarios no funcionan en ellas.

Para ello habría que crear una column family standard para los post, que nos permitirá usar los indices secundarios, y una column family super para guardar las keys de los post dentro de una super column con key, por ejemplo, ‘key_posts‘. Para hacer la consulta habría que recuperar las keys de los posts a mostrar en primer lugar, y después, utilizando un método de phpCassa que aun no hemos usado recuperar los registros correspondientes a esas keys.

El método que deberíamos añadir a nuestro archivo cassandra.php sería el siguiente:

[codesyntax lang=»php»]

<?php

  function obtenerMultiplesRegistros($columnFamily, $multiKeys){

      $column_family = new ColumnFamily($this->conexion, $columnFamily);

      $result = $column_family->multiget($multiKeys);

      return $result;

  }

[/codesyntax]

A este método le pasamos el nombre de la column family standard donde hemos guardado los posts y un array con las keys a recuperar, nos devolverá un array con los datos de cada uno de los posts que le hemos pedido… y en el orden en el que le hayamos pasado las keys a recuperar.

Existe otra forma de ordenar registros, pero además de que en versiones posteriores de Cassandra desaparecerá y provoca problemas de rendimiento, yo no la recomiendo, ya que pierdes todos los beneficios que ofrece Cassandra. Aun así os dejo un link para que le echéis un ojo xD:

http://ria101.wordpress.com/2010/02/22/cassandra-randompartitioner-vs-orderpreservingpartitioner/

Y os dejo otro link para que tengais algo más de información respecto a ordenar registros en Cassandra:

http://ayogo.com/blog/2010/04/09/sorting-in-cassandra/

 

CREAR CLAVES O KEYS PARA LOS REGISTROS

Como has podido ver en el apartado anterior, para ordenar los registros es muy importante tener una key de cada registro que sea única y siempre vaya en orden. Esto las bases de datos relacionales nos lo dan ya hecho, sin embargo en las bases de datos no-sql esto no es así.

Las bases de datos no-sql se crearon para optimizar la lectura y escritura de los registros en la base de datos, esto provocó que algunas funcionalidades muy útiles en las bases relaciones no tuvieran cabida en las no-sql. Por tanto para mantener en orden los registros debemos crear nosotros nuestras propias claves.

phpCassa dispone de un método para crear una clave aleatoria basada en el timestamp, para utilizarla crearemos un nuevo método en nuestro archivo cassamdra.php que devolverá la clave:

[codesyntax lang=»php»]

<?php

  public function obtenerUuid(){

      $util = new CassandraUtil();

      return $util->import($util->uuid1());
  }

[/codesyntax]

Como me está quedando un post muy largo os lo voy a dejar como deberes xD. Sería interesante probarlo tanto con column families standard y super, además de con un tipo de comparador UTF8Type y TimeUUIDType.

Como el chorro de letras y números que devuelve es muy poco legible yo suelo utilizar mi propio sistema de claves, normalmente utilizo el microtime() de php y un par de ids de lo que se esté guardando: el id del usuario, el id de lo que se ha creado, etc. Algo que lo diferencie del resto. Para la clave primero pongo los segundos que devuelve microtime() y después los microsegundos. Para que os hagais una idea sería algo así:

$key = $segundos . ‘.’ . $microsegundos . ‘_’ . $id_post . ‘_’ . $id_usuario;

De esta forma le estamos dando una clave para los ejemplos del anterior apartado, más concretamente para los comentarios en un post.

 

CONTAR REGISTROS

El último apartado de este post. Contar registros. Esto es algo que Cassandra no lleva muy bien, sobre todo con grandes cantidades de información.

Cassandra cuando recibe una petición de lectura/escritura utiliza unas tablas en memoria llamadas memtables (el que le puso el nombre de rompió la cabeza pensando). Cuantas más peticiones reciba Cassandra más memtables creará, de esta forma permitirá una cierta consistencia de la información almacenada en la base de datos.

Cuando le pedimos a phpCassa que nos devuelva el número de registros en una column family o en una super column concreta, lo que está haciendo en realidad es hacer una petición a Cassandra de todos los registros que haya en la column family o en la super column. Cuando esto ocurre Cassandra guardará estos registros en la RAM del servidor antes de enviarlos a phpCassa, y sí Cassandra no cuenta los registros, porque no está pensada para eso, es phpCassa la que cuenta los registros y te devuelve el número concreto.

El método que utiliza phpCassa para contar registros es el que os muestro a continuación, dentro de un método para añadir al archivo cassandra.php:

[codesyntax lang=»php»]

<?php

  public function contar_registros($columnFamily, $key){

      $column_family = new ColumnFamily($this->conexion, $columnFamily);

      return $column_family->get_count($key);

  }

[/codesyntax]

Esta forma de contar registros provoca que Cassandra consuma todos los recursos de RAM del servidor, con lo que no os la recomiendo.

La mejor manera de contar registros con Cassandra es utilizar una column family con contadores, de tal forma que en nuestro código cada vez que se guarde un registro en la bd se aumente el contador que lleva la cuenta de los registros guardados. En el caso de que se eliminen, habría que disminuirlo. Y en el caso de que el registro se esté actualizando controlar que no aumente el contador xD.

Cualquier duda que tengais intentaré responderla lo mejor posible en los comentarios.

Logo Cassandra

Cassandra y PHP para desarrolladores SQL: Cassandra Cluster Admin, el phpMyAdmin de Cassandra

4
hace 11 años
by Mikel en

En el anterior post expliqué el funcionamiento de la consola de Cassandra y como trabajar con ella. En este post explicaré como hacer lo mismo de una forma más rápida y fácil.

La razón de que no haya empezado ha explicar como se utiliza Cassandra desde PHP, es que primero hay que conocer cómo funciona Cassandra, su modelo de datos (que ya hemos visto) y algunos comandos básicos para ir aprendiendo a guardar y recuperar datos. El próximo post ya trataré el funcionamiento de phpCassa y empezaremos a programar.

Este post será bastante ligerito. Explicaré principalmente como hacer lo mismo que hicimos por consola pero de modo gráfico. CassAdmin, como yo le llamo, tiene más opciones de edición para los keyspaces y column families de los que vamos a ver (igual que ocurría con la consola), pero solo tocaremos las opciones más habituales.

 

INSTALACIÓN

Lo típico en estos casos. Descargar. Descomprimir y ejecutar. Descargamos los archivos desde el repositorio de git: https://github.com/sebgiroux/Cassandra-Cluster-Admin, o a través de git o como archivo comprimido. Como más te guste.

Repositorio de Cassandra Cluster Admin

Página de descargas del administrador

Ahora descomprimimos a una carpeta dentro de nuestro servidor web, ya que trabajamos con una aplicación programada en PHP.

Si tienes Cassandra instalado en otro equipo que no sea en local, una máquina virtual por ejemplo, tendrás que cambiar la ip a la que se conecta cassAdmin. Es bastante sencillo. Para ello debes modificar el archivo includes/config.inc.php y sustituir la ip de localhost (127.0.0.1)  por la ip del equipo en el que tengas instalado Cassandra:

Archivo config.inc.php

Como verás en la captura, yo utilizo la ip local 192.168.1.10 que pertenece a una máquina virtual. Si tuviera instalado Cassandra en  el mismo equipo la ip a la que debería apuntar sería 127.0.0.1. El puerto no lo modificamos.

Una vez instalado y configurado (si fuese el caso) probamos a acceder desde nuestro navegador. Debería mostrarte algo como esto:

Página principal de Cassandra Cluster Admin

CREAR KEYSPACES

Como has podido ver, en la página principal del administrador ya aparece un keyspace, llamado system, perteneciente a Cassandra, con lo que lo mantendremos como está.

Justo encima tenemos un botón para crear un nuevo keyspace (Create a new keyspace). Lo pulsamos.

Formulario para crear un keyspace

Solo nos pide tres parámetros a rellenar:


Keyspace name: El nombre del keyspace a crear.
Replication factor: Es el número de servidores o instancias de Cassandra de los que se debe guardar un registro u obtener una respuesta al recuperar algún registro.
Strategy: Es la estrategia que seguirá Cassandra para guardar los datos. En el caso de tener varios servidores o centro de datos diferenciados entre sí, se aplicará una estrategia u otra para que los datos no se pierdan. Más info: http://answers.oreilly.com/topic/2408-replica-placement-strategies-when-using-cassandra/ 

En nuestro caso escribiremos los siguientes valores:

Formulario para crear un keyspace con datos

Pulsamos en Create keyspace y nos llevará a la página principal:

Página principal mostrando el keyspace que acabamos de crear

Pulsamos sobre el keyspace que acabamos de crear y nos llevará a la siguiente página:

Página de detalle del keyspace my_keyspace

Aquí podemos ver información relativa al keyspace y al anillo (o cluster) en el que se encuentra guardado. También nos permite editar el keyspace o eliminarlo, pero la opción más interesante es la de crear nuevas column families (Create a new column family).

 

CREAR UNA COLUMN FAMILY

Dentro del keyspace pulsamos sobre el botón Create a new column family, nos mostrará lo siguiente:

Formulario para crear una column family

 

Primero crearemos una column family standard con los siguientes datos:

Datos para crear la primera column family

Para crear una column family solo son necesarios tres parámetros:


Column Family Name: El nombre de la column family que vamos a crear.
Column Type: El tipo de column family que vamos a crear (Standard o Super).
Comparator Type: El comparador principal de las columnas. Es decir, la codificación que tendrán los datos dentro de la column family.

Pulsamos en Create Column Family y en la página de nuestro keyspace se habrá añadido una nueva column family:

Detalle de la column family creada

 

AÑADIR REGISTROS A UNA COLUMN FAMILY STANDARD

Ahora toca guardar registros en la BD.
Como comenté en post anteriores Cassandra no necesita conocer los campos de las tablas (nuestras column families) ya que los creamos cada vez que añadimos un registro.

Primero en la página principal del keyspace haz click en el nombre de la column family. Te aparecerá lo siguiente:

 

Detalle de la página principal de la column family creada

En esta página te aparecerá, además de la información referente a la column family, los siguientes botones:


Browse Data: Para mostrar un listado de los registros que contiene la column family.
Create Secondary Index: Para crear indices secundarios. Parecido a los indices de MySQL.
Get Key: Para buscar una clave o registro concreto.
Insert Row: Para insertar un nuevo registro.
Edit Column Family: Para editar los parámetros de la column family.
Truncate Column Family: Para eliminar los registros de la column family sin eliminar esta.
Drop Column Family: Para eliminar la column family y su contenido.

Pulsamos en Insert Row. Nos aparecerá lo siguiente:

Formulario para insertar registros

Siempre que añadamos un nuevo registro deberemos indicar una key diferente que deberá ser única, sino cassAdmin pensará que lo que quieres hacer es actualizar ese registro. Añadimos los siguientes datos al formulario:

Formulario para insertar registros con datos

 

Para añadir otra fila de cuadro de texto solo tienes que pulsar el botón Add…
Volvemos a la página principal de la column family y pulsamos en Browse Data. Aquí veremos un listado con los registros que hayamos añadido:

 

Listado de registros

 

CREAR UNA COLUMN FAMILY SUPER Y AÑADIR REGISTROS

El proceso para crear una column family Super es idéntico a las column family Standard, solo hay que cambiar un valor a la hora de crearla:

Creación de una column family Super

Entramos en la página principal de la nueva column family y pulsamos en Insert Row. Aquí veremos que el formulario a cambiado un poco, nos aparece un nuevo campo llamado Super Column Name y un nuevo botón encima del formulario, Add Super Column:

Formulario para insertar registros de una column family super

Las column family Super son como las muñecas matrioskas, esas figuras que si las abrías había otra igual dentro, y dentro de esa otra más, y otra, etc. Algo parecido sucede con estas column family. Disponemos de una key (nuestra primera matrioska) que contiene a las super columns (segunda matrioska), que a su vez contienen las columnas clave:valor.

Añadamos un registro para verlo:

Datos para crear una super column

Si nos vamos a Browse Data:

Listado de registros en una column family Super

Como ves, ahora las columns se agruparían dentro de la super column. Añadiré más registros para que lo veas mejor:

Listado de registros en una column family Super

¿Ves? Las keys agrupan a las super columns y estas a su vez a las columns.

 

Creo que esto es suficiente para que conozcas el funcionamiento de Cassandra Cluster Admin. Quedarían algunas cosillas, como editar registros, hacer búsquedas o eliminar registros, pero eso es bastante sencillo (a excepción de las Secondary Index y las Counter Columns que trataré más adelante).

Para cualquier duda o problema déjala en los comentarios.

Logo Cassandra

Cassandra y PHP para desarrolladores SQL: El modelo de datos

8
hace 12 años
by Mikel en

Si has trabajado con una base de datos relacional tal vez te resulte algo confuso al principio comprender el modelo de datos que usa Cassandra, intentaré ser lo más claro posible, pero si te surgen preguntas no dudes en dejarlas en los comentarios.

 

Columnas

El elemento más básico de la base de datos Cassandra es la columna, se compone de tres elementos: nombre de la columna, valor y timestamp. Os muestro un ejemplo como un array:

 array(
«nombre» => «email»,
«valor» => «webmaster@localhost.com»,

«timestamp» => time()

,

)

 

Super columnas

Es el conjunto de columnas con sus correspondientes valores:

array(
«nombre_superColumna» => array(

 

«usuario1» => array(
«nombre» => «email»,
«valor» => «webmaster@localhost.com»,
«timestamp» => time()
),
«usuario2» => array(
«nombre» => «email»,
«valor» => «email@email.com»,
«timestamp» => time()
),

 

«usuario3» => array(
«nombre» => «email»,
«valor» => «otroemail@otroemail.com»,
«timestamp» => time()
),

),

)

 

Familia de columnas

Es el conjunto de columnas o super columnas. Me explico:

Las column Family o  familia de columnas se puede configurar de dos maneras: como Super o como Simple. Si se elige la opción Simple, en la column family solo se podrán guardar columnas no super columnas. En cambio si la column family está configurada como Super podrá guardar, además de las columnas, las super columnas. Esta flexibilidad permite jugar con la base de datos y adaptarla a nuestras necesidades.

Ejemplo:

 array(
«name» => «ColumnFamily»,
array( «name» => «SuperColumn»,
array( «colums» )
),
)

Keyspace

El keyspace es nuestra base de datos, donde alojaremos todas las columFamilies que necesitemos.

Ejemplo:

array(
«name» => «keyspace»,
array(«name» => «columnFamily»,
array(
[…]
),
),
)

Optimización de WordPress

Mi última pesadilla: Optimizar el VPS para WordPress

16
hace 13 años
by Mikel en

Pesadilla… de tres semanas y pico. Anoche soñé con la lista de procesos del comando top de Linux. Apache consumía cada vez más y más memoría. Por consumir, consumió el Kernel de Linux y se transformó en el Kernel de Windows. Y no se porqué antes de despertarme entre sudores fríos apareció Bill Gates descojonandose a moco tendido. Dios, ¡Qué imagen!, no se me quita de la cabeza.

Durante este tiempo me he didicado a «intentar» optimizar tanto el VPS como WordPress para reducir el consumo de memoría. Aunque he hecho algunas mejoras (pocas por desgracia) sigue cayendose Apache; pero comenzaré por el prinicpio:

¿Porqué un VPS?

  1. Por el precio: Ví un VPS más o menos al mismo precio que un hosting y apliqué el dicho «burro grande ande o no ande».
  2. Por aprendizaje: Nunca había probado un VPS y quería saber como poder administrarlo, que se puede hacer con él. No jodes tantas cosas como con un dedicado y hasta cierto punto tienes menos responsabilidad y es mucho más barato. Y es el paso lógico antes de administrar un dedicado, en el que ahí estas solo completamente.
  3. Por unificar mis proyectos web: Dispongo de cinco dominios. Para cada uno tengo planes para crear una web con ellos,o en algunos casos ya está creada y online, en otro, estoy esperando a ver que pasa con el VPS y otros solo estan proyectados. Disponer de todas las webs en un solo servidor, ya que no tienen muchas visitas, es muy pero que muy cómodo, además de económico.
  4. Por ahorar costes: Cinco dominios, cinco hostings. Aunque los hay muy baratos (desde un euro) siempre te limitan alguna cosa y no me convencian.
  5. Por libertad: La posibilidad de hacer y deshacer a mi antojo, en definitiva, de tener el control de la máquina (virtual) es una gozada.

Características del VPS

  • Memoría RAM: 256 MB
  • Espacio en disco: 5 GB
  • Transferencia mensual: 150 GB
  • Sistema operativo: CentOS 5
  • Panel de control: Plesk
  • Y obviamente el resto de características habituales: Perl, PHP, MySQL, etc, etc, etc.

El principio

Cuando contraté este VPS, era un puto ignorante, así de claro, desconocía muchas cosas sobre la administración de servidores, su optimización, y sobre todo, las características que había que observar detenidamente antes de contratar nada (en VPS. En hosting, tengo bastante idea). Menos mal que era el más barato xD.

Desde el tercer o cuarto día comenzó a fallar Apache. Los datos que obtenía tanto de Plesk como de Virtuozzo me indicaban que la memoría se saturaba y paraba los servicios. Claro, como un ignorante creé un ticket al proovedor. La respuesta fué rápida (y ahora la más lógica), «actualice su VPS a uno superior». No comprendía como me podían decir eso. ¡Que sólo es un blog! ¡Que el día que llega a 100 visitas monto la fiesta padre! !Coño, que no es Digg, ni el Mundo! ¿Cómo podía ser que con solo al acceder a la página principal de la administración (el escritorio de WordPress), Apache ya se viniese abajo? ¿Cómo era posible?.

Sólo había una idea en mi cabeza: «Estos del hosting quieren sacarme más pasta» (Viendolo ahora, en cierto sentido, tenía razón). Pero esa idea no soluciona el problema, aunque mi cabezonería la convirtió en  mantra y como con levantar Apache o reiniciar el contenedor volvía todo a funcionar, se quedo así durante meses.

Primeros intentos

No soy una persona que se rinda fácilmente. Yo siempre digo que en informática no hay nada imposible, sino poco presupuesto. Así que comencé a informarme sobre VPS, WordPress, Apache, etc. De esto puede dar fe mi navegador (uso Opera) que ahora mismo tengo abiertas unas 50 pestañas.

Lo primero fue buscar una forma para averiguar cuánta memoría consumía WordPress. Encontré el siguiente código:

$memoria_usada = round(memory_get_usage(1) / 1024,1);
echo ‘Memoria usada: ‘ . round(memory_get_usage() / 1024,1) . ‘ KB de ‘ . $memoria_usada . ‘ KB’;

Este código indica la memoría que había antes de ejcutar el script (que se guarda en la variable $memoria_usada y se pone al inicio del archivo) y la memoría consumida después de ejecutar el script (que se pone al final). Los datos en local que saqué fueron los siguientes:

9 plugins: Memoria usada: 27462 KB de 67.1 KB
Sin plugins: Memoria usada: 20468.8 KB de 67.2 KB
Actualizando el theme: Memoria usada: 21049.1 KB de 67.1 KB (Utilizando el theme que tengo en el blog actualmente, sustituyendo al theme por defecto)

Siento no tener los datos del VPS, pero no varían mucho. Ahora mismo consume 29,5 MB con ocho plugins activos (no son los mismos plugins han variado desde entonces) más el theme.

Las pruebas las realicé con WordPress 3.0.1 con la base de datos tal cual se instala, bajo Windows con la suit de AppServ sin modificaciones.

Yo, cuando ví las cifras, me quedé alucinado: ¡Wordpress consume casi 20,5 MB!. Realicé pruebas con otras versiones de WordPress para verificar que esto era así, es decir, comprobar que con el paso de las versiones el consumo de memoria había aumentado. Que no era cosa mía, sino que es así de chupón. Aunque aquí puede variar el consumo de memoría dependiendo de las reglas de mod_rewrite de Apache, de como esté optimizado PHP y MySQL, etc. El único culpable no es WordPress, pero acojona.

Viendo lo visto, era hora de actuar.

WordPress a dieta

Sabía que existian varios plugins que permitian cachear las páginas del blog y reducir el consumo de memoria y procesador, pero simpre lo había visto en blogs con miles de visitas, no en uno cutre con theme gratuito que no llega a las cien visitas diarias (triste pero cierto).

El primero en activar en el blog, wp-cache, me costó un poco instalarlo, más por mi inexperiencia con cachés que otra cosa (mira que es sencillito el plugin). Al final no se lo que me paso, no lo recuerdo, que lo desactivé. Busqué otro.

WP Super Cache, no mienten los que hablan bien de él, funciona estupendamente, es un poco más complicado de configurar que wp-cache pero el resultado es magnífico. Pero el blog seguía consumiendo casi 30 MB de memoría y Apache se caía. Mejoró la estabilidad del blog un poco, al menos de cara al visitante sí. Pero seguía con el mismo problema: en cuanto entraba en el Escritorio Apache se escoñaba.

Antes de esto probé cada uno de los plugins para ver cual era el que hacía que Apache se cayera nada más entrar en las administración del blog. WordPress.com Stats era el culpable, la establidiad mejoró sustancialmente teniendo este plugin desactivado. Durante unos días pensé que estaba solucionado el problema, nada más lejos de la realidad. Aunque el blog consumia menos memoría, en cuanto hacía algo que requiriese más esfuerzo por parte de la RAM, Apache se venía abajo. Simplemente con entrar varias veces en el escritorio del blog o activar un plugin, Apache caía. Fue frustrante.

Un plugin del que no conocía su existencia es DB Cache Reloaded. Como su nombre indica, permite cachear las consultas a la base de datos, evitando que se conecte a la base de datos cada vez que haya una petición a esta. Reduce el consumo de recursos. Bien. Activado está y funciona de maravilla, aunque de momento no termina de cachear todas las consultas. Tendré que mirar porqué.

Pero el problema continuaba, Apache se caía. Había que entrar en el servidor.

SSH

Tengo que admitir que no me había conectado nunca a otro ordenador a través de SSH, si a través de VNC y VPNs.

Trabajo con Windows XP SP3 principalmente, pero no le hago ascos a las distribuciones linux, todo lo contrarío: en VirtualBox tengo instalados Debian, CentOS, Ubuntu y ChromeOS, y excepto para el tema de configurar la tarjeta gráfica que aun no he conseguido (creo que VirtualBox es el que no la reconoce y por algún motivo envía al SO una tarjeta gráfica compatible con la que tengo, pero me obliga a estar con una resolución de 800×600).

Bien, ¿porqué cuento esto?. Además de por que quería contarselo a alguien xD, por que así comprenderás que después de varios intentos por conectarme al servidor con varios programitas para Windows, arrancase una máquina virtual para conectarme por la consola de linux. ¡Bendita seas!. Hasta que descubrí que lo que me fallaba era el puerto para poder acceder. ¡La ignorancia da la felicidad!.

Una vez conectado al servidor lo primero que hice fue un top de la máquina para conocer el consumo de RAM (la leche no) en tiempo real.

Me indicaba que tenía 512 MB de RAM total y la memoría consumida oscilaba entre los 170 y los 220 MB, aunque en algunos podía llegar a 270 MB. El problema radica en que el VPS no tiene 512 MB de RAM sino 256 MB; los otros 256 es memoría compartida, con lo que no puedo contar con ella para realizar el cálculo.

También hice un free -m para comprobar la memoria, pero top me ofrece más datos.

Observé que cuando se pide al servidor una página apache ejecuta cuatro procesos de sí mismo llegando en varios casos a consumir un 12 por ciento de memoría RAM. Lo normales un 10 por ciento.

A por Apache

Optimizar Apache. Me costó un huevo y medio encontrar la ubicación de los archivos de configuración, pero cuando me enpeño… (/etc/httpd/conf en CentOS). Bien, leí que si realizaba ciertas modificaciónes en el archivo httpd.conf de Apache podría reducir el consumo de memoría. Por defecto la configuración de Apache era la siguiente:

<IfModule prefork.c>
StartServers                     8
MinSpareServers              5
MaxSpareServers            20
ServerLimit                   256
MaxClients                   256
MaxRequestsPerChild   4000
</IfModule>

Se quedo así:

<IfModule prefork.c>
StartServers                      5
MinSpareServers               5
MaxSpareServers             10
ServerLimit                     30
MaxClients                     30
MaxRequestsPerChild 40000
</IfModule>

No solucionó mucho, o por lo menos yo no lo noté. Reduje también varios parámetros más, como el tiempo que espera Apache para cerrar una conexión permanente, etc.

Esto seguía sin mejorar. Probemos con la base de datos

MySQL

Poca optimización realicé aquí, la verdad. Me limite a añadir la configuración para habilitar la caché de la BD, pero no ha hecho mucho. También puede deberse a que el plugin de WordPress que cachea las consultas ya lo está haciendo. No sé. La configuración quedo del siguiente modo:

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 8M

PHP

Para optimizar PHP necesitaba instalar en el VPS Eaccelerator y el Zend Optimizer, mis pocos intentos me han llevado a pensar que no puedo instalar nada que no sea a través de Plesk o que necesite el comando yum. Por tanto, a día de hoy, PHP está sin optimizar, habrá que enviar un ticket a ver si ellos me lo isntalan…

VPS

CentOS consume memoría, como todos los SO, las veces que he podido ver el consumo de memoría sin Apache, está rondaba entre 60 y 80 MB. Pero no sólo es el sistema operativo el que consume RAM, Plesk también consume lo suyo (unos 50 MB), he deshabilitado el antivirus que me consumía 70 MB cada vez que se iniciaba. Pero aunque el VPS se ha estabilizado hay momentos en los que Apache tiene cuatro procesos abiertos de 50-60 MB cada uno (según el comando top). Excesivo.

Intenté crear un archivo SWAP pero el comando swapon no lo tengo permitido, al menos por SSH.

CONCLUSIONES

  • Sigo valorando distintas opciones respecto a la optimización del VPS, ahora mismo mi mejor baza es Eaccelerator y que me lo instalen en el VPS para reducir la memoría.
  • Seguiré probando con algunnos plugin de WordPress a ver que tal.
  • Si estas interesado en la contratación de un VPS andate con ojo con la RAM.
  • Me he planteado incluso cambiar de VPS o ampliarlo con la misma empresa o marcharme a otra, ya se verá en septiembre.
  • Lo mejor de todo esto: lo aprendido por el camino. No solo conozco un poco mejor los sistemas Linux, sino también Apache, PHP, MySQL y Plesk, y su administración.
  • Bueno, ¿Y vosotros?¿Qué experiencia habeis tenido con los VPS?¿Qué consejos podeis darme? o simplemente ¿Qué opinais? Los comentarios son vuestros… mientras Apache lo permita xD.

LINKS

Os dejo unos links y así libero al navegador de carga, pobre.

Optimización del VPS

Optimización de WordPress

Optimización de PHP

Optimización de Apache

    Ir arriba