style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Escalabilidad y paradigmas de almacenamiento de datos

No hace muchos años que empezamos a hablar de el Cloud computing y en pensar en todos los beneficios que esto nos traería, todo mundo habla del tema y pareciera que sera todo fabuloso, aunque hay un pequeño grupo de gente que vamos a tener que pensar diferente para enfrentar estos nuevos cambios.

Paradigmas en el almacenamiento de datos.

Quería nombrarle "Nuevos Paradigmas en el almacenamiento de datos", pero la verdad es que muchos de los paradigmas que resurgen hoy en día son mas viejos que los mismos que hemos utilizado quizás desde que desarrollamos, aunque no los conozcamos O.O

   
Es interesante destacar que las <a href="http://es.wikipedia.org/wiki/NoSQL">NoSQL</a> existen desde hace muchos años (1970), con experimentos en universidades europeas y norteamericanas, sobre sistemas de almacenamiento abiertos. Los almacenamientos de par Clave/Valor, vieron la luz en 1979 con el proyecto DBM, y mas tarde BerkeleyDB (1986). Si consideramos que LotusDB es una base de datos orientada a documentos, tenemos que la empresa Lotus dió a luz este proyecto en 1989.

Las bases de datos orientadas a objetos nacen formalmente por allá de 1985, entonces no es extraño pensar que NoSQL existe desde antes que SQL (quién arrancó en 1977 de la mano de IBM, que no lo hizo comercial sino hasta 1983 con DB2 y el ANSI no lo hizo estándar sino hasta 1986).

Bueno y todo esto que tiene que ver? Me imagino que ya se imaginan :D

La escalabilidad es la clave.

Fácil, La web 2.0 radica en ofrecer servicios que tengan alta interoperabilidad, lo cual requiere de servicios de almacenamiento de datos mucho mas ágiles y escalables.

 El problema para cualquier sistema distribuido, como una base de datos replicada, fue explicado por el Prof. Eric Brewer en su Teorema C.A.P. (inglés): Ninguna base de datos puede disfrutar de Consistencia, Disponibilidad y Tolerancia a Particiones al mismo tiempo.

Sumado a que el uso que se le da al modelo relacional en la web es mínimo, hoy las NoSQL están teniendo una gran ingerencia en los websites.

En estos últimos tiempos, mas con el auge de open source y el hecho de que varias compañías como Facebook, Yahoo!, Amazon y Google nos contaron cómo hacen para administrar millones de solicitudes por segundo y cómo adoptaron para estas soluciones hardware barato (y no es con SQL precisamente), comenzaron a recordarse o construirse, otras formas de almacenamiento masivo alrededor del mundo, incluso en la forma de "cachear" datos y evitar el uso del disco, como memcached y repcached, y otros proyectos propietarios de open source.

La tendencia esta marcada, y todo se apuesta para que los móviles y tablets sean lo que el usuario prefiere para comunicarse casi con cualquier tipo de aplicación, en países lejanos cambiaron a las meseras por iPads, por un simple ejemplo. Esto me lleva a pensar en que tipo de cambios pueden darse dentro de la industria del desarrollo de software para los que deberemos estar preparados y poder ofrecer al cliente una nueva gama de servicios de calidad sin perecer en el intento.

O tal vez ni siquiera nos enteremos del asunto :D ???

Algunos proyectos NoSQL

Brewer's CAP Theorem


La Ventanita.net - Lo imprescindible en la red

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Y llegó el Hype a javaMexico

NoSQL tiene sus usos. Pero esta moda de NoSQL y de que todo mundo quiere construir cualquier aplicación web como si fuera el siguiente Facebook, pensando desde el principio en que tiene que ser capaz de atender millones y millones de peticiones por segundo, me parece absurdo.

Más que sitios grandes, me parece que los que más están impulsando NoSQL son gente nueva en la industria, que no ha tenido experiencia con bases de datos relacionales (o pseudo-relacionales como les quieran decir, antes que llegue luxspes con su Rel). Soluciones como MySQL, PostgreSQL, DB2, Oracle, MS SQL Server, Informix etc han funcionado perfectamente bien durante años, manejando tablas con millones de registros, en ambientes de alta concurrencia, para aplicaciones de misión crítica. Cuando la consistencia y la integridad de los datos es fundamental en un sistema, NoSQL simplemente no es una opción.

Las soluciones actuales sacrifican integridad y consistencia en nombre de la velocidad; eso está muy bien para Facebook porque si de repente entro a mi página y no tengo status o no veo actualizaciones de algunos amigos, no pasa nada. Pero una situación similar no es aceptable si entro a la página de mi banco y que simplemente no me aparezcan algunas cuentas, o movimientos, o que mi saldo está mal porque la base de datos es "eventualmente consistente".

No es fácil diseñar bien una aplicación para escalabilidad, ni implementarla bien. Ya hemos visto varios ejemplos de malas implementaciones o malos diseños incluso en los sitios grandes: Facebook se ha caído durante varias horas por alguna configuración mal hecha, Foursquare estuvo 11 horas fuera del aire por fallas en MongoDB (no se supo ya bien si fueron defectos en la base de datos o en la configuración que tenía 4sq), lo de Digg y sus 500 servers para atender 200 millones de peticiones en contraste con StackOverflow y sus 5 servers para 60 millones de peticiones; Twitter se cae a cada rato.

Menciono estos ejemplos porque esos sitios utilizan estas tecnologías de escalabilidad, y aún así tienen sus problemas. Eso para que tomen en cuenta que su sistema no será invulnerable a caídas o a problemas de escalabilidad simplemente porque usan MongoDB, CouchDB, Cassandra, HBase. Hay que leer bastante documentación de estas tecnologías antes de decidir que son la bala de plata para todos los desarrollos de hoy en adelante, porque tienen varias limitaciones (la falta de transaccionalidad es la principal para mí, porque los sistemas siguen necesitando operaciones atómicas y la capacidad de rollback).

No estoy en contra de NoSQL, pero sí estoy en contra de que ahora se considere que es la solución a todos los problemas de almacenamiento y que digan que las bases de datos tradicionales apestan, eso no tiene ningún sentido.

Algo similar pasa con la programación funcional.

Existe desde 1960, pero en recientes fechas ha tenido muchisima atención por que el modelo ayuda para la programación distribuida.

La programacion funcional se basa ( como su nombre lo dice ) en funciones que promueven la falta de estado y que no haya efectos secundarios después de llamarlas, por ejemplo llamar a la funcion suma ( 1 , 2 ) debe de regresar 3 siempre, sin importar el número de veces que sea invocado.

Esto facilita la ejecución de programas que corren en paralelo en miles de servidores. Pero eso no implica que no pueda hacerse en lenguajes Orientado a Objetos o en procedurales. Simplemente, complementa el conjunto de conocimientos que debemos de tener para saber que puede aplicarse en que caso.

Tampoco implica que la programación funcional vaya a sustituir a la orientada a objetos ni nada por el estilo, sucede hay tecnologías que cobran relevancia por que existen algunos escenarios donde se aplicó con éxito.

Imagen de greeneyed

No hay mucho más que añadir...

Suscribo totalmente el comentario de ezamudio y no hay mucho más que decir. Sólo recordar que "todo sirve para algo pero nada sirve para todo".
S!

Imagen de 043h68

Toda la razón

Tal vez y la gente que promueve o ha creado tanta expectativa acerca de estas tecnologías vamos guiados en parte por la ignorancia de estas y por comentarios que vamos tomando de diferentes fuentes y así caer en el error de querer "utilizar un toro para cruzar el desierto", jajaja, ahora me queda mas claro y cito a @greeneyed "todo sirve para algo pero nada sirve para todo".

Saludos!

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">