Hacía tiempo que tenía ganas de escribir algo sobre NoSQL ( Not only SQL ), y algunos clientes me han pedido que les programara una red social varias veces,…desde que Twitter empezó a usar este tipo de base de datos porque MySQL ya tenía hacía un tiempo algunos problemas de latencia, debido a la gran cantidad de datos nuevos a indexar, …pensad que en un día como hoy se generan más de 12 TeraBytes de información de los twitts, es decir, aproximadamente 4 PetaBytes al año, estamos hablando del 2010 y estos datos se doblan cada año, pues multiplicad por 6…casi ná!
Me pregunté , ¿Cómo debería un programador php freelance construir una red social como Twitter o Facebook?
¿Qué hacer con semejante volumen de datos y tenerlo todo ordenado e indexado?, es una tarea colosal, ¿verdad? ,pues bien, los chicos de Twitter nos contaron en el evento Strange Loop de 2010 ( video + audio | pdf ) que diseñaron estrategias mixtas de bases de datos con NoSQL ,donde MySQL no llegaba a ser suficiente, imagino que los cortes en el servicio de por aquellos entonces tuvieron mucho que ver con esto…normal. Estas estrategias se basan en construir un sistema o arquitectura de sistemas de información integrados…pero…Por qué llegaron a usar NoSQL en Twitter: porque necesitaban recoger todos los datos de forma eficiente de millones de usuarios, guardarlos y analizarlos, algoritmos capaces de «aprender» acerca de la información de estos datos para saber cómo tratarla y optimizarla – indexarla, análisis de grafos sociales, etc.
Luego los problemas a solucionar eran: 1. recoger datos, 2. guardar y analizar los datos, 3. aprendizaje rápido de datos masivos
Ahora comentaré un poco esta presentación:
Empezando por el escritor de logs, empezaron usando syslog pero no era escalable, se colgaba y se perdían datos, por lo que usaron Scribe montado sobre Apache Thrift que si es escalable y también usado por Facebook, es un framework de código abierto que escribe líneas de datos en categorías y hace mucho trabajo por nosotros, ya que colecciona datos de diferentes máquinas en un clúster funcionando de forma local y en red, de forma que se administra para no perder los datos de los nodos, es escalable, jerárquico y permite conectar salidas externas de los datos fácilmente…de modo que usar esta tecnología solucionó el primero de los problemas. Como en Twitter son muy majos, extendieron el framework opensource mejorando la escritura, compresión, monitorización y escritura en HDFS continuando el trabajo con parches de FB lo que hizo posible almacenar más de 12TB al día sin que fuera un drama.
Sí, el que escribe ha mencionado HDFS que viene de Hadoop, un framework para guardar los datos de forma distribuída, es decir, una técnica que permite escribir todos esos datos masivos en un clúster de máquinas, porque ,en fin, ya sabéis que no hay disco duro que pueda escribir tantos datos tan rápido, …por ahora…
Guardar los datos
Esto es algo complejo porque un sistema así necesita replicación automática y tolerancia a fallos, algo que soporta Hadoop. Hay que pensar que esta arquitectura de información funciona como un gran disco duro compartido entre diferentes nodos.
Analizar los datos
Además permite MapReduce una tecnología de Google ( ya sabéis que este tiene servidores de alta replicación y aplicaciones distribuidas –google app engine– ) , basado en computación paralela y el par llave-valor de amplio rango…por ejemplo Yahoo! tiene un clúster de 4000 nodos, es capaz de ordenar 1 TB de números aleatorios (índices) en 62 segundos, y además permite empaquetar fácilmente gracias a Cloudera RPM (donde está ahora el creador de Hadoop).
Un ejemplo del uso de MapReduce sería una consulta para saber cuántos tweets tiene un usuario, obteniendo los datos de la tabla de tweets, se le pasa una llave que es la columna y el valor es la información del tweet, el mapa de salida tiene una llave que es el id de usuario y un valor numérico, se barajan los datos ordenándolos por este id de usuario y se reducen por la misma razón, una máquina puede hacer esto fácilmente, varias máquinas nos devuelven los datos más rápido, mientras más se usen más rápidamente se devuelve el resultado, la cuestión es cómo balancear la carga…
Uno de los retos sería analizar datos de grafos sociales en relaciones entre usuarios, por ejemplo, los seguidores de alguien, es imposible hacer una consulta MySQL con un self join de una tabla con n-millones de filas…entonces se usa el clúster para hacer más fácil distribuir cálculos que se trata de la diversión que proporciona la computación paralela :D
Hacerlo de esta forma significa que puedes contar todos los tweets, es decir, los más de 20 millones en 5 minutos aproximadamente…
Obtener datos rápidamente de datos masivos
¿Cómo están estructurados los datos almacenados?, están los datos semi-estructurados: logs de apache, logs de consultas, logs RoR, tests A/B, etc., y luego están los datos estructurados: tweets, usuarios, bloques, teléfonos, favoritos, búsquedas guardadas, etc. , por último están los datos complejos: grafos sociales, esto último me pareció lo más interesante pues es algo que usamos todos en twitter, cuando buscamos en la red social información sobre un meta-tag o un usuario o una palabra por ejemplo (conteno, mínimo, máximo, etc.), se devuelve un resultado basado en cientos o miles de capas de información por los que viajan indagando en nuestra consulta…
En este caso, el sistema que utilizan en Twitter para hacer la indagación es conocido como Apache Pig , basado en un lenguaje de alto nivel , capaz de transformar datos de conjuntos y registros y procesarlos mediante transacciones, el lenguaje de pig es un poco diferente al SQL que conocemos…y es normal ya que cuando tienes un fichero muy grande, y que se ha transformado en un conjunto de registros, hay que especificar algunas cosas ,aunque es bastante fácil de entender, veamos un ejemplo de un script que nos propone Kevin Weil en su presentación:
es un script para contar los 5 primeros tweeteros entre 18 y 25 años ordenados por mayor número de seguidores y agrupados por urls, se hace un joint, un group y un order limitándolo a 5…esta consulta realizada en Hadoop ocuparía como 100 veces más en código lo cual es algo que nos dice lo que nos estamos ahorrando, de hecho…Pig democratiza el análisis de datos a gran escala, lo que significa usar el 5% del código y el 5% del tiempo que se tardaría normalmente además está optimizado hasta un 20% en tiempo de ejecución, pero, y siempre hay un pero xD, depende del tipo de consulta que hagas, claro,…debido a lo importante que es ahorrar recursos se preparan muy bien las preguntas, aún así, se utilizan mecanismos automáticos de medida de latencia media, distribución geográfica, etc. que ayudan a recuperar la respuesta más eficientemente…
Aquí un ejemplo de script para buscar con Pig una url
Aprendizaje
Es precisamente saber qué consulta hacer lo que le da valor al sistema,y esto sirve para promover la innovación que necesita cada iteración ,al ingeniero, de forma que mientras mejores preguntas y más personas integren el equipo de mejora, más rápido mejorará el sistema.
Resumiendo, en el eco-sistema de Twitter tienen Cloudera: es una distribución libre que se usa desde 2010 en combinación con CDH2 y Hadoop, esto junto con Scribe y LZO, que es ideal para comprimir los datos que se escriben en el HDFS; y, MapRedude implementado en Java (HBase, Hadoop streaming, etc)
Para que las máquinas sepan relacionar mejor los datos se utilizan algoritmos probabilísticos , de covarianza e influencia, algunos criterios por ejemplo serían el uso por parte de clientes de escritorio, móviles y web, correlaciones importantes cuando hablamos de grandes volúmenes de datos.
¿Cómo se puede aprender de lo que los usuarios escriben en twitter?
Evidentemente los fallos del sitio son oportunidades únicas para aprender,
conociendo las preguntas, entonces se pueden buscar correcciones y sugerencias de cambios como respuestas.
Para aprender, las preguntas correctas que debemos formular serían:
y etc.,…estas preguntas generan un gran flujo de información que resulta, entre otras cosas, en la creación de grafos sociales y que nos dan una idea directa de información como puede ser la reputación de ese usuario, de su influencia, en definitiva lo que se aprende son datos aplicables al aprendizaje que pueden ejecutar computadoras.
Estos datos se pueden analizar para buscar patrones, por ejemplo, se puede usar el programa de la FOCA de nuestro hacker español Chema Alonso y descubrir el patrón de movimiento de un usuario gracias a los tweets con meta-información que nos permiten estar geolocalizados, de manera que en un mapa aparecerán nuestras rutas por semana y cosas por el estilo. Otro ejemplo práctico para los administradores de la red social es poder encontrar bots, este script es un ejemplo de cómo se haría:
Y hasta aquí he hablado un poco sobre lo que dijo Kevin en 2010 pero si tenéis ganas de más, hay mucho más!, de hecho dentro de muy poco dará lugar un evento acerca del estado actual de NoSQL, en la NoSQL Now! 2013 Conference. Con ponentes de Amazon (que da soporte a Apple y su iCloud por ejemplo), GitHub, RackSpace, etc., y allí contarán las cosas que están de moda jeje
Para nosotros simples mortales con proyectos webs que no alcanzan los millones de visitas al día, ¿qué podemos utilizar?, pues bien, hay varias soluciones, entre las que cabe destacar, además de las utilizadas por Twitter ( Cassandra y Cloudera ), está MongoDB, HyperTable, etc., depende del uso que se le vaya a dar, más información acerca de las más de cien implementaciones de NoSQL en nosql-database.org , de hecho se estuvo estudiando el uso de este tipo de base de datos para WordPress pero como se requiere un grado mayor de relaciones entre entidades no sería tan eficiente y se descartó…
Si lo que queréis es usar PHP y una base de datos NoSQL hay una implementación de API’s para muchas de ellas, por ejemplo para HyperTable, CouchDB, etc., para esta última tenemos PHPillow, pero lo importante es preguntaros para qué las váis a usar, si es para guardar
cada una tiene una disponibilidad de los datos (ver teorema de CAP), consistencia y tolerancia de particiones (fallos) diferente, por ejemplo para una bd distribuida basada en pares de llave/valor como Redis se podría escribir un script como este en PHP:
$redis = new PredisClient(9; $redis->set('miLlave', 'Un valor'); $valor = $redis->get('miLlave');
ok, pues extrapola esto y constrúyete tu propio clon twitter con Redis jaja.
Sin embargo con la aproximación por columnas se puede crear un modelo relacional a medida, tomando como base dimensiones o categorías:esto se puede hacer con Cassandra, deberías usarla siempre que necesites guardar más que leer, y que los datos tengan una gran disponibilidad, además trae soporte de Hadoop como hemos visto antes. Hay diferentes implementaciones en PHP como es el caso de phpcassa.
Aquí un ejemplo del uso de los índices de columna de Cassandra escrito en PHP:
//Conectar con el espacio de llaves $basedatos = new ConnectionPool('mi-bd-twitter'); //Crear la familia de columnas de usuarios $usuarios = new ColumnFamily($basedatos, 'usuarios'); //Crear un usuario $usuarios->insert('6', array('name' => 'Juan Belon', 'nick' => 'juaxix' )); //Obtener usuario $usuario = $usuarios->get('6');
Ok, hasta ahí para las bases de datos por columnas, como véis es bastante sencillo, de hecho hay algunas implementaciones por ejemplo para MongoDB que usan JSON para comunicarse con las API’s e incluso han creado fáciles administradores en PHP…,ahora, para el caso de usar una base de datos distribuida orientada a almacenar documentos, sin ningún esquema, donde tienes un «cubo» de pares de llaves/valor dentro de un objeto, es uno de los casos en los que se puede usar un lenguaje más conocido por nosotros amantes del SQL, y MongoDB es lo que a los programadores PHP puede que les guste más porque se pueden escribir líneas de código tales como
$post -> where ( ‘id’ , $id ),
y cosas así, muy parecidas al modelo de datos persistentes de Google App Engine, de hecho hay bastantes implementaciones y herramientas para MongoDB ,supongo que porque es el tipo de base de datos NoSQL más divertida XD …hay un caso para usar con el framework y cms CakePHP, CodeIgniter, Symfony, etc, …veamos un ejemplo con ActiveMongo:
ActiveMongo::connect('mi-bd-twitter', 'localhost'); class Usuario extends ActiveMongo { public $nombre; public $usuario; } $usuario = new User(); $usuario->nombre = 'Juan Belon'; $usuario->usuario = 'juaxix'; //Insertar usuario $usuario->save(); // XD qué fácil es ,eh //Actualizar el nombre $usuario->nombre = 'Juan Belon Perez'; $usuario->save();
así que sería fácil montar un sistema de bibliotecas para almacenar millones de entradas, en el caso de usar CouchDB, echadle un vistazo al link de herramientas de CouchDB con PHP, veréis que es muy parecido y la diferencia radica en que ésta tiene replicación bi-lateral (maestro-maestro) y una API JSON por defecto (en MongoDB es una extensión)…
En el caso en que te decidas por usar una base de datos distribuida basada en grafos (modelo de grafos construído con nodos con propiedades y relaciones ), tienes Neoj4por ejemplo que es totalmente transaccional y tiene una API muy flexible, pero es un poco más complejo de entender y puede que no la entiendas a la primera jeje pero úsala siempre que quieras establecer grafos de relaciones sociales, mapas de carreteras, topologías de red, etc. En PHP tienes NeojPHP, REST API, Thrift, etc. pero como digo, es algo más complejo y menos divertido.
¿Qué base de datos NoSQL usarás para crear tu clon de twitter ahora que sabes todo esto?
[…] generción como Pig, para más información de esto escribí un artículo de cómo funciona Twitter aquí. Diseñar mecanismos autómaticos que reúnan a grupos de usuarios para realizar tareas conjuntas […]
[…] que escribí el post acerca de twitter, de cómo las bases de datos NoSQL revolucionaron las webs con masivas cantidades de datos tenía […]