DEBIAN PRO

DEBIAN PRO
DEBIAN

martes, 19 de junio de 2012

Productos/Servicios


Hasta hace poco y teniendo una necesidad informática, mis conocidos preguntaban "Para hacer esto como se hace en sql?" , "Como se hace en Oracle?"
Algunos otros preguntaban "Que producto de Microsoft hace eso?"

Pero, ahora existen miles de productos pequeños, sobretodo bajo linux, que resuelven necesidades puntuales, ya no hace falta tener un SQL Server para cubrir las necesidades de gestión de información.
Aparecieron muchos programas/servicios con codigo abierto y gratuitos que resuelven esos problemas.

Apareció hace unos años el concepto NoSQL, que YO prefiero denominar "Not Only SQL", ya que en algunos casos los productos NoSQL tienen un tipo de comunicación "MUY SQL".

Gracias a Pablo, que me pasó el link este es uno de ellos
http://gigaom.com/cloud/ex-facebookers-launch-memsql-to-make-your-database-fly/

El resúmen sería, una especie de MySQL que se carga en RAM y que anuncian que da un 20x de mejora de velocidad.


Otro de los productos que estamos probando estos dias es COACHBASE
http://www.couchbase.com/download
Fácil de instalar, en Windows o Linux (y otros S.O.), en los próximos dias probaremos como se accede a él desde .NET.

martes, 12 de junio de 2012

NoSQL, RDBMS, SQL, Oracle y datos. Parte II


PARTE II

Se estaba haciendo laaaargo y pesado...

Aparecieron varias soluciones de las empresas mas grandes de internet, donde debían dar un servicio a millones de personas y los servidores RDBMS no resolvían los volúmenes de peticiones requeridas.
Aparece entonces el NoSQL, con varios frentes para dar servicio a diferentes necesidades y como un complemente a un RDBMS tradicional, que existen, seguirán existiendo y que convivirán seguramente durante mucho tiempo mas.

Un banco que debe restar 5 €ruos de una cuenta y agregar esos mismos 5 €uros en otra, usa y usará un RDBMS. En los servicios donde hay gente en el fondo, se cobran por ellos y hay dinero en medio, un RDBMS es el producto que "cumple las espectativas" del cliente, del gestionador, de proveedores y todos contentos.
Han crecido muchisimo algunos productos como MySQL, Postgresql, SQLite y otros motores pequeños y sencillos que tratan de dar servicios ACID y SQL. En el caso de MySQL existen varios motores de acceso a datos para necesidades distintas (Maria, Falcon, Innodb, MyIsam, etc)

Al mismo tiempo servicios como TWITTER/Whatsapp, donde millones de personas agregar contenidos permanentemente y otros millones de personas quieren leer esos contenidos ahora mismo y NO HAY dinero en medio (del estilo cuenta bancaria) se admite que si pido los twitts de un amigo mio, alguno de sus últimos no se vean y puede que demore minutos en verlos. (en que yo los vea) Su twitt puede ser importantísimo pero TWITTER no garantiza casi nada... y se reserva muchos derechos (has leido el texto completo ? seguramente no....) donde básicamente pueden hacer lo que quieran y no garantizan nada.

Para esa necesidad de millones de transacciones cada segundo, los RDBMS no escalan correctamente. Las grandes empresas nuevamente dan soporte, meten dinero, motivan, compran, impulsan desarrollones pequeños de todo tipo (siempre relacionados a NoSQL), ver nuevamente la página de la Wikipedia porque necesitan de un tipo de servicio que no existía y nos pilló a todos "SIN ESE RECURSO".

Como ejemplo, prueba entrar a tu cuenta Twitter, cambia tu foto y refresca tu página... verás que en cada twitt la foto puede ser la anterior o la nueva, y en forma arbitraria se irán actualizando a las fotos hasta que un rato después verás únicamente la foto nueva. Porqué ?
Porque hay cientos de servidores que almacenan contenido sin respetar una secuencia y sin garantizar conceptos ACID... La información está o estará cuando se pueda.

Volviendo al tema NoSQL, existen productos que almacenan información de una manera sencilla, utilizar un hardware antiguo, dan un servicio "lo mejor posible", mueven datos de un sitio a otro según lo pidan, tienen redundancia según peticiones y brindan algo denominado "ESCALAMIENTO HORIZONTAL", que significa crecer en cantidad de cajitas una al lado de otra, en lugar de actualizar hardware por otro mucho mas potente, con mas memoria, con mas CPUs, con mas placas de red...

El pensamiento es cientos de servidores almacenan "algo", en cualquier lugar del mundo y cuando alguien lo pida alguno de ellos se lo enviará, si uno se cae otro dará el mismo servicio.
COPIO TEXTUALMENTE LA WIKIPEDIA


* Estos sistemas responden a las necesidades de escalabilidad horizontal que tienen cada vez más empresas.
* Pueden manejar enormes cantidades de datos.
* No generan cuellos de botella.
* Escalamiento sencillo.
* Diferentes DBs NoSQL para diferentes proyecto.
* Se ejecutan en clusters de máquinas baratas.

Un buen artículo para leer es este.
hay otro link muy bueno aqui también.

Estoy probando MongoDB, Redis, Cassandra y SQLite (RDBMS) en unos servidores Linux virtuales (con MintLinux). Algunos necesitan máquinas Java, otros son ejecutables, algunos mas sencillos para acceder y otros un poco mas diferentes a lo que yo conocía hasta ahora (desde 96 trabajando como DBA)...

Por ahora no tenemos tiempo para probar Azure, al menos por ahora...
Sobre Bigtable, hay un doc muy bueno para leer.

En las próximas semanas, intentaremos encajar alguno de estos productos en un APP que tenemos desarrollado, y que dará servicio a millones de personas y que está desarrollado en .NET, LINQ, SQL Server, Reporting Services y otros productos adicionales. Cualquier solución NoSQL puede resolvernos el problema de "millones de usuarios".

RESÚMEN DE MIS PENSAMIENTOS
No todo es blanco o negro, hay grises y trataré de poner "MIS" grises, las cosas dependen de otras, de la implementación, de las necesidades, del tipo de datos, etc.etc... lo siguiente NO SON LAS VERDADES DEL UNIVERSO ni LOS 10 MANDAMIENTOS... son ideas y tendencias.

* Creo que seguirán existiendo RDBMS y servicios de tipo NoSQL.
* Una cosa no reemplaza la otra, son complementos.
* Los NoSQL están madurando mucho, pero aún se ven betas con algunos fallos. Algunos de ellos justamente en escalamiento.
* Un aplicativo "tradicional" no necesita que el 100% de sus datos estén en un RDBMS, como ejemplo, la tabla PAISES no cambia en años. Podría ser un candidato a meter en un NoSQL.
* Permitirán dar servicio geo-blogal, multiidioma, multiplataforma y su escalamiento será "el que necesitemos".
* Hay empresas globales, como Amazon, Microsoft, Google, IBM que ofrecen (alquilan) sus estructuras para tener estos servicios.
* Los productos se pueden probar sin pagar nada.
* Algunas aplicaciones NO DEBEN ser preparadas para un NoSQL !!!
* Algunos estar dentro de nuestro proyecto .NET, otros son Java y otros EXEs.
* Puede que tengamos servidores que dan el "servicio" de acceso a determinados datos.
* NoSQL es muuuuuy rápido en lectura, pero tiene algunas demoras y problemas en las grabaciones.
* COMO SIEMPRE, usar la mejor herramienta para cada problema. No tratar de encajar huevos en cajas cuadradas.
* NO SER FANATICO
* Un servidor MySQL con MyISAM puede ser tan rápido como soluciones NoSQL.
* COMO SIEMPRE, no creas lo que leas, has tus propias pruebas con tus datos, en tu escenario, con tus características y vuelve a probar todo de nuevo varias veces.
* Y LUEGO CONSULTA a otras personas para que opinen al respecto, internet es un GRAN CEREBRO GLOBAL en el que todos aportamos conocimiento.


AGREGADOS.........

Un texto para leer.
ACABO DE VER VOLDEMORT.
PostgreSQL ofrece un servicio Cloud.
BitNami ofrece soluciones Cloud, a probarlas...

NoSQL, RDBMS, SQL, Oracle y datos. Parte I


Estos dias pasados hablando con Pablo, reviví varios temas que tenía descuidados por el trabajo.

HISTORIA BREVE y RESUMIDA
Allá lejos y hace tiempo existían las "cintas" para almacenar información. Medios magnéticos de acceso secuencial.
También existían las tarjetas perforadas y luego aparecieron los discos con 32 megas... (si, megas).
Toda la información de un banco latinoamericano se almacenaba en 80 megas, incluyendo clientes, cuentas, saldos, movimientos...
En la evolución aparecieron los discos, aumentos de memoria, aumento de ciclos de CPU, luego avances en la tecnología de discos, llegan los SSD, QUADs cores en CPU, memorias de 64 gb muy baratas... Todo fue evolucionando a nivel físico.
En paralelo la información que se buscaba almacenar crecía y también fueron apareciendo "soluciones", ficheros planos, ficheros indexados, btrees y otras soluciones que evolucionaron, hasta que por los 70 aparece "Ted Codd", a quien cariñosamente llamamos el abuelo de las bases de datos, que definió idéas para el modelado de datos y algo "relacional", que fué el punto de creatividad porque la información que se almacena, suele tener que ver con otro tipo de información que se almacena, dicen que IBM no le prestó atención, y que L.Ellison creó "Relational Software"intentan cumplir normas ANSI para hacernos la vida un poco más fácil en la comunicaciones con los motores (interfaz, lenguaje de programación SQL, objetos existentes en un RDBMS).
En esos productos y salvando las distancias entre ellos, todos manejan datos de una manera relacional y similar entre sí (Tabla, índice, vista, espacio de almacenamiento, comunicaciones, SQL, querys)

Que debe tener un RDBMS ? Ver link.

Desde los 90 en adelante y con la explosión de Internet, se comienzan a almacenar infinidad de datos, fotos, ficheros y todo aquello que se podía digitalizar, aparecen millones de portales web, aparecen servidores Gopher, FTP, DNS y SMTP que nacían cada minuto, recuerdo amigos en los 90 que eran los dueños de 200 webs distintos, algunos tenían información, otros era simplemente portales para "vender luego"...
El volúmen de crecimiento de Internet en el mundo y de los datos que se almacenan en internet (ahora denominado NUBE.... que es mucho mas fashion) se duplica permanentemente.

Algunos ejemplos son Tucows, Blogspot (99), Google (98) y tengo la certeza que comienzan a pensar en "como manejar" tandos datos y dar servicio a decenas de miles de usuarios de todo el mundo y al rítmo que crecían los accesos a esos servicios, debieron pensar que alternativas de "gestión de información" se podían implementar.

Recuerdo una charla por el 98 en la costa con Daniel S. sobre cual sería el volúmen de datos que podría almacenar un servidor Oracle... Y si eso se duplica cada dia que hacemos?
Respuestas que no encontramos y donde la idea de "poner mas servidores" y dividir los datos parecía la solución.

Los RDBMS crecieron pensando en particionar los datos de diferentes maneras, siempre manteniendo sus principios SQL, en un mundo de soluciones conocidas. También existen soluciones de almacenamiento de información fuera de un motor SQL, siendo el propio motor el que gestione ese fichero en un almacenamiento donde pueda acceder el mismo servidor SQL.

Por el 98 comienza a aparecer un concepto "NOSQL"
donde para resumir decimos que la información se almacena de una manera distinta a como se gestiona con un REDBMS. De ser un concepto evolucionó (y pasaron varios años...) en varias direcciones, hablamos de "servicios" que sirven para almacenar información de tipo Documento, grafo, clave/Valor, tabulares, formatos xmls y otros.
Estos productos (tengo que decir que varios todavía están en modo Beta) son usados por los mas grandes portales en internet, Facebook, Twitter, Flick.er y ahora cambiamos el foco y entramos en "otra dimensión".

viernes, 1 de junio de 2012

SQL SERVER migraciones.


Como con cada versión (desde SQL 2005) Microsoft invierte un poco de tiempo es tratar de ayudar en las migraciones de los motores a las últimas versiones.

En este sitio, hay un texto explicando una herramienta gratuita que se puede descargar.


Como siempre es recomendable probar la herramienta en un servidor que NO SEA EL PRODUCTIVO, muchisimo mejor generar una máquina virtual VMWARE del server real y probar esta herramienta en el equipo virtual (100% igual al real).

Hay una versión para 32 bits y otra para 64bits.


Hay varias versiones, para migrar de 2000 a 2005, de 2005 a 2008 y la última para ser usada en 2008 a 2012.