Como después de cada evento al que asisto, aquí está la retrospectiva. En este caso consiste en un OpenSpace dedicado a la Persistencia y, como está de moda, a hablar de NoSQL a muerte.

Llegué sin tener ni idea y me voy con un montón de conceptos que tengo que revisar en casa. Es probable que haya mezclado cosas o que otras las explique fatal. Tomé mogollón de notas y es gracias a éstas que voy a escribir este artículo, pero no creo que sirvan para aprender nada, sino como guía de aquéllo que hay que aprender.

Llegada

El OpenSpace tuvo lugar en las oficinas de Tuenti que tan bien me conozco :D. Me sorprendió la cantidad de gente conocida que encontré allí: aproximadamente una cuarta parte de los asistentes.

El hecho de dividirnos en salas fue algo casi anecdótico, ya que los mismos términos surgían una y otra vez. Además, en más de una ocasión terminó habiendo una única sala. Cuando comenzaba la siguiente charla podía verse como una continuación de lo que se estaba hablando antes. Fue un acierto poner (y asistir, por mi parte) la charla de “NoSQL (luz, gracias)” la primera de todas.

Las charlas

NoSQL (luz, gracias)

Presentada por Enrique Amodeo. Siempre es genial asistir a las charlas con Enrique, porque siempre se aprende mucho.

Cuando un sistema no da suficiente chicha, solo hay dos maneras de solucionar el problema: la primera es cambiar la máquina por una más gorda. La segunda, añadir más máquinas. Esta segunda opción añade tolerancia a fallos.

Si lo que se está intentando es tener un sistema escalable, no es posible que sea consistente. Por eso está el teorema CAP (Consistency, Availability, Partition tolerance), de las que sólo se pueden elegir dos:

• CA (Consistente y disponible): 1 nodo y todo en memoria.
• CP (Consistente y escalable): N nodos y se solicita la información siempre a todos, devolviendo lo que diga la mayoría (N+1)
• AP (Disponible y escalable): NoSQL.

Parece que Cassandra y los últimos MongoDB soportan la elección de esto mediante un parámetro (configurable por cada request; en Cassandra se puede distinguir entre las lecturas y las escrituras). Si este parámetro vale 1, será CA; si vale “majority”, será CP; y si vale cualquier número menor, será AP (bueno, más o menos era algo así).

Guillermo recomendó un paper de Amazon sobre DynamoDB que tengo que leerme.

Alfredo citó una frase que había oído pero no recordaba dónde: “SQL devuelve un hecho; NoSQL, una opinión”.

La elección del tipo de BD depende de los requisitos que se tengan. De acuerdo con la agilidad, la BD es lo último que debe elegirse, ya que es un plugin de la aplicación que puede reemplazarse. Debe elegirse en el último momento responsable (Lean).

Por aquí también salieron palabros como “Agregaciones”, “DDD” y “less” o “schema-less”. También aparecieron los tests como una red de seguridad.

Hubo una intensa discusión sobre si hay o no esquema, y parece que la conclusión fue que siempre hay un esquema, solo que éste puede estar en los tests o en el script de la BD, pero siempre existe. Lo que es un error es duplicarlo. En el caso del Active Record, mandará la BD sobre el resto de la aplicación.

Libros que aparecieron: “Lean architecture”, de James O. Coplien y “NoSQL Distilled”, de Pradmod J. Sadalage y Martin Fowler.

MongoDB

Parece que las BBDD pueden clasificarse en 4 tipos:

• Clave-valor
• documentales
• grafos
• Orientadas a columnas

MongoDB pertenece al grupo de las documentales. Resulta muy sencilla de comprender y con Python resulta muy natural.

Concepto de Sharding: compartir y distribuir la información de la BD entre los distintos nodos.

De los presentes, nadie lo ha utilizado como core de un programa.

Al parecer, se puede establecer que una relación implica una jerarquía, mientras que una composición implica una agregación (redundancia de datos). También apareció el concepto de herencia pero debo admitir que no entendí nada de esto. Por esta razón pensé que tal vez me había equivocado y debía haber ido a la otra charla.

MongoDB permite documentos anidados, y… bueno, como en toda BD, los índices elegidos son clave para el rendimiento. Un punto bueno es que se pueden tener índices sobre columnas que no tienen por qué tener todos los elementos. Estos índices están optimizados para lecturas.

MongoDB parece funcionar muy bien cuando hay pocas escrituras y muchas lecturas. Para realizar las queries, están trabajando en un pseudo-lenguaje de consulta que mapee a map-reduce, pero es algo que todavía es un proyecto.

Se pueden paralelizar las búsquedas utilizando varios nodos, pero en un mismo nodo son bloqueantes.

Lo normal es utilizar los IDs que te ofrece por defecto, ya que puede afectar al sharding.

Tiene un tipo especial para binarios, ya que el tamaño por defecto del “documento” está limitado (4Mb). Las fechas pueden ser un problemas porque hay que andar con conversiones que no se hacen automáticamente.

El tema de los backups incrementales está muy verde. Hay que parar el nodo para poder hacerlo.

Git como NoSQL / Híbridos

En esta ocasión, Guillermo nos estuvo hablando sobre una idea loca: utilizar Git como base de datos. En este caso sería una base de datos NoSQL de tipo documental.

Lo de utilizar un sistema de control de versiones como BD no es una idea nueva: ya la había oído en alguna empresa anterior. Por eso decidí asistir.

Al utilizar Git como persistencia, la primera característica que tienes es que es inmutable. Es cierto que puedes cambiar la historia, pero no debe ser lo habitual, ya que pueden surgir muchos problemas.

Al utilizar Git se tienen dos tipos de claves: por un lado, una referencia a la última versión de un “documento”, que es el path (tree en terminología Git) de la misma; por otro lado, una referencia única a un documento que permanecerá a través del tiempo, como es el Sha1 o identificador único del blob.

La sincronización entre distintos nodos resulta terriblemente sencilla: puede utilizarse un simple pull. Esto también facilita la creación de un nuevo nodo y no importa si en un momento dado no hay sincronización entre dos de los nodos: se sincronizará en el siguiente pull.

Las principales ventajas de un sistema así son:

• Resolución de conflictos proporcionada por Git.
• Es transaccional. Y para operaciones complejas pueden utilizarse ramas.
• Hay versiones. Es implícito.

Sin embargo también tiene algunas desventajas:

• No hay queries.
• Concurrencia.

Hay varias librerías que pueden utilizarse para crear un sistema como éste: libgit2 y grit.

Como referencias, hay un hilo de correo sobre el uso de GIT en repositorios muy grandes (gracias, Guillermo).

La otra parte de la charla, los híbridos, generó una conversación muy interesante: memcached vs redis. En concreto se planteaba el problema de guardar sesiones. Había gente que defendía que Redis funciona mejor que Memcached bajo determinadas características de concurrencia, y que tenía la ventaja añadida de la tolerancia a reinicios gracias a su persistencia. La oposición defendía que Memcached, al guardarlo todo en memoria, debía ser más rápido siempre.

Otro punto que se trató fue lo que se debe guardar en la sesión, con la conclusión de que no tiene por qué ser un mapping directo de ninguna tabla, sino información útil que puede evitar accesos a la capa de datos.

Tuenti

Y aprovechando que jugábamos en casa, se propuso un ejemplo de uso de bases de datos NoSQL: Tuenti. En este caso, Luis estuvo contando cómo funcionaba Tuenti por dentro. Esta charla se comió el otro track.

Luis dio una visión general del sistema, que puede resumirse en que utilizamos MySQL, pero con una capa de abstracción propia por encima que asemeja a un sistema NoSQL. El resto del tiempo se dedicó a responder preguntas.

En una de estas preguntas, surgió el tema del despliegue blue/green. Consiste en tener el sistema replicado y así poder cambiar a la nueva versión con un simple redireccionamiento, pudiendo volver atrás en segundos. Este sistema tiene el problema de que, salvo cuando estás desplegando, tienes la mitad de los recursos detenidos. Tuenti no utiliza este sistema, ya que significaría tener “más de mil” máquinas paradas (en palabras de Luis).

Otra característica es que utiliza Memcached por UDP. Se cae de vez en cuando, pero no es un problema mientras no se caigan todos los memcached al mismo tiempo.

No sólo de NoSQL vive el hombre

Y nos fuimos a comer.

En mi mesa estábamos Guillermo, Kiko, Ismael (¿O era Israel?) y yo.

Éramos un grupo curioso: uno decidió cambiar su visión de la vida al ir a un OpenSpace, dos asistían por primera vez a un evento así, uno padre de familia, uno en una multinacional, otro autónomo… Y surgió la duda de “cómo se comienza a ir a un sitio así”, lo que me resultó curioso, porque ya habían comenzado XD

Active Record y otros patrones

Básicamente, la charla consistió en un tira y afloja entre el uso de Active Record o evitarlo. Todos parecían estar de acuerdo en que el uso de AR obliga a elegir la persistencia al principio. Esto permite soluciones muy rápidas, con muy buen TTM (Time To Market), pero poco escalables.

Otro tema es el de los tests unitarios aislados: es muy dificil realizarlos con AR, ya que es el propio framework quien debe proporcionarte un sistema. De esta manera, no solo dependes del framework para el código, sino también para las pruebas.

Surgieron dos temas interesantes: Actualizar la versión del framework puede ser muy doloroso si se ha utilizado AR, por lo que debe existir una buena razón para ello. Por otra parte, ¡Cobol utilizaba ya un sistema NoSQL!

Como curiosidad, se trató de responder a la pregunta “¿Qué es código legacy?”. Me gustó una definición: “Aquél código que se puede romper si lo tocas”. Por definición, es lo mismo que decir “el código que no tiene tests”.

Entre bastidores

La siguiente charla me la salté, hablando con Juanma, Antonio y Guillermo. El tema fue “metodologías ágiles”, nada relacionado con persistencia. ¡Siempre es interesante charlar con gente así! El problema es que no cogí apuntes y no sabría concretar los puntos que hablamos, salvo buscar la definición de Scrum Master y qué roles se realizan en un scrum.

Geoposicionamento

El título original de la charla me resulta un poco extraño, así que lo dejo con este título. Total, también se comió al otro track.

Por lo visto, MongoDB funciona estupendamente para guardar los datos de posicionamiento. Además, permite calcular una aproximación de distancias 2D teniendo en cuenta la curvatura de la tierra. Alguien propuso como otra opción Solr.

Surgió la duda de si estos cálculos pertenecen a la capa de persistencia o a la de negocio, ya que cada una de éstas tiene sus ventajas.

Para facilitar la búsqueda, hay que utilizar facetas, cuadrículas o capas, lo que permite búsquedas en un conjunto menor de datos.

También hay que tener en cuenta que los cálculos son muy diferentes si se quiere encontrar el camino más cercano en tiempos, distancias, teniendo en cuenta la altitud (3D vs 2D), …

Un ejemplo de uso: positren

Surgió un término curioso: HTMLDB, haciendo referencia a los datos extraidos de la red mediante spiders (nada relacionado con ningún producto comercial).

Despedida y cierre

En este caso no hubo retrospectiva. Sinceramente, creo que fue un acierto, ya que no veo ninguna conclusión que pudiéramos sacar. Fueron charlas entre amigos, exposiciones de puntos de vista. Todos queríamos aprender y queríamos aprender de todo. No creo que hubiéramos sacado mucho de una retrospectiva cuando lo que nos llevamos es todo un día de conclusiones.

De lo que sí se habló fue de hacer otras charlas. En concreto, os adelanto que Madrid-qa y Madrid-ágil quieren hacer una charla sobre “Calidad de Software” el día 16 de febrero. El formato será OpenSpace. Aún no han confirmado el lugar.

Otra excusa para juntarnos son unas jornadas que están preparando en la UPM, que pretende dialogar sobre la profesión de informática y quieren juntar a profesores, alumnos y empresarios. Todo se irá hablando…

También se eligieron algunos temas para futuros OpenSpaces:

• Legacy dojo
• Arqueología de software
• Frontend

Mis conclusiones

Mi conclusión más inmediata surgió al ver el panel: no tengo ni puta idea. Así que tengo que leer sobre el tema.

Después de hablar con @pasku1, tengo que leerme el libro “NoSQL Distilled” tal que ya XD

Por lo demás, un día genial entre amigos y profesionales. Ojalá nos fuera posible juntarnos más a menudo en estos términos.