Bases De Datos Libres 4436v

Bases de Datos Libres Ricardo Di Pasquale Dijo John Maynard Keynes “Todo el mundo sabe que es mejor, para la reputación, errarle como todos, que salirse de la norma”. Parece una norma para los IT Managers la compra obligatoria de software propietario. Sobre todo en el caso de las bases de datos. Esto no invalida la posibilidad de que en algunos casos se trate de una decisión apropiada. Pero todo Manager parece abrir el paraguas ante eventuales desastres con la frase “No echaron a nadie por comprar x” siendo x alguno de los grandes vendedores de software (IBM, Microsoft, Oracle, etc.). Si se analiza la lógica de este argumento, parece tener un arraigo conservador (bajo la forma “compro lo que otros compran en todo el mundo”), pero no parece estar focalizado en una solución particular para un tema también particular. Otra norma que parece inviolable, además de la “marca” del DBMS1, es la tecnología. En el ambiente IT cuando hablamos de DBMS se lee entre líneas que estamos hablando de RDBMS2. Parece no haber otro paradigma. Pero claramente los hay. Lo mismo sucede con el lenguaje de consulta, parece no haber otro lenguaje que el SQL. Pero claramente los hay. En atención a los párrafos anteriores, hemos decidido focalizar nuestra exposición no en el hecho de dirimir si las bases de datos libres son mejores o peores que los productos privados, sino en sacarlas de la invisibilidad a las que las somete el “sentido común” del ambiente de los IT Managers y también exponer las falacias más comunes demostrando que sólo pueden sustentarse por prejuicios, sometiéndolas a un somero proceso de deconstrucción. Intentaremos rastrear algunos desatinos. Por lo tanto presentamos un breve Manual de Zonceras sobre Bases de Datos Libres mientras introducimos algunas tecnologías impulsadas por bases de datos libres.

1 2

Data Base Management System Relational Data Base Management System

Manual de Zonceras sobre Bases de Datos Libres

“El dinero es el único Dios sin ateos en la Tierra. Muy callado sería el bosque si sólo cantaran los pájaros amigos del guardabosque” Aforismos de Ernesto Esteban Etchenique Roberto Fontanarrosa







La madre de todas las zonceras o El modelo relacional es lo suficientemente flexible como para modelar cualquier dominio. Zonceras por razones de inseguridad psicológica o No me da ninguna tranquilidad. o ¿Y quién me da soporte? o ¿Y quién me garantiza que anda? o Más vale comprar algo de marca. o ¿Te parece que va a andar ese programita? Zonceras por ignorancia o En cuanto al desarrollo tecnológico, el software libre no hizo ningún aporte a las bases de datos. o Nadie lo usa. En los países serios no se usa



Zonceras de índole económica o Nuestra base de datos es de bajo mantenimiento. No necesita DBA. o Lo barato sale caro o Es muy caro capacitar a alguien.

La madre de todas las zonceras El modelo relacional es lo suficientemente flexible como para modelar cualquier dominio El modelo relacional ha sido la norma en el mercado de bases de datos por casi cuarenta años. Ha habido modelos alternativos como los jerárquicos y de redes, que tuvieron su pequeño nicho de mercado. Durante ese desarrollo las bases de datos orientadas a objetos emergieron como una solución natural para las aplicaciones orientadas a objetos, aunque no lograron ubicarse en un lugar central en la industria por motivos que exceden este trabajo, pero que van desde los más endogámicos (no hay aún hoy un standard fuerte de lenguaje de consulta de una base de datos orientada a objetos) a los más exógenos (no lograban competir con el rendimiento de las bases de datos relacionales). El modelo relacional está centrado en un modelo matemático que lo hace consistente y flexible al mismo tiempo. Permite el modelado Entidad-Relación (no es lo mismo modelo relacional que modelado Entidad-Relación) que consistió en una metodología de análisis de sistemas data-céntrica de vital importancia para la ingeniería del software. El modelo relacional ite un conjunto de operaciones procedimentales llamada Algebra Relacional que nos permite operar con este modelo. En el marco del análisis estructurado surge SQL (como consecuencia del desarrollo de Codd, el modelo relacional, a principios de la década del ’70) como un lenguaje estructurado de consultas. Rápidamente se convirtió en el standard para las bases de datos relacionales y más adelante fue impensable hablar de bases de datos relacionales sin hablar de SQL. Hasta los nombres de los RDBMS suelen contener estas tres letras (MySQL, SQL Server, Postgre SQL, etc.). Rápidamente surgieron críticos del lenguaje SQL que fueron acallados por el éxito del mismo en la industria, aunque sus argumentos, en gran medida, eran válidos. Si bien SQL es un lenguaje relacionalmente completo (todo lo que se expresa en Algebra Relacional puede expresarse en SQL), presenta problemas de representación. Solo para ilustrar este punto vamos a decir que una sentencia correcta de SQL ite dos maneras de representar una junta interna (inner ), a saber, vía el operador Inner y via el operador “=”. Esto que parece trivial introduce un problema de representación, se confunde la semántica de la operación de Selección y de Junta del álgebra relacional. Pero el principal problema es la confusión entre el modelo y la representación. Cuando modelamos un dominio (hablando en términos de datos, en otra oportunidad hablaremos en términos de objetos) hacemos una abstracción de la realidad que debemos plasmar en un modelo. Ese modelo tiene las reglas intrínsecas del modelo relacional, y itimos una representación SQL

(dado que la industria nunca implementó el álgebra relacional). El problema se da cuando nuestros analistas confunden modelo y representación. Es común ver como muchos analistas entran en problemas al intentar resolver problemas relacionales (que finalmente son problemas de conjuntos) directamente sobre la representación (SQL), sin recordar el isomorfismo que debe existir entre el modelo y la representación. Confundir modelo con representación constituye un problema grave y es más frecuente de lo que parece. Volviendo al hilo principal de este punto, muchos problemas iten soluciones relacionales, pero que por diversas circunstancias obligan a la implementación física a ir saliéndose del modelo relacional (denormalización, utilización de herramientas no transaccionales en bases de datos transaccionales, etc.) dejándonos en una situación en la que estamos obligados a utilizar un modelo relacional a través de una representación (que muchos piensan que es un modelo en sí) para una solución que se aleja cada vez más del modelo relacional. Eso es atentar contra la mantenibilidad del software. Tomar un problema y darle martillazos hasta que encaje en un patrón de diseño, es en sí, un antipatrón. Hay modelos que encajan mejor con determinados problemas. Hay modelos de bases de datos que encajan mejor con el entorno y ciclo de vida del proyecto, como por ejemplo las bases de datos orientadas a objetos encajan mejor con el desarrollo orientado a objetos3. Existe un movimiento desde fines de la década del ’90 llamado No SQL4 que principalmente se centraron en los problemas de escalabilidad horizontal de las bases relacionales, y están muy relacionados con el desarrollo de la Web 2.0. Los desarrollos dentro de esta iniciativa tienen la particularidad de no cumplir con alguna de las cuatro propiedades ACID5 que sí cumplen las bases de datos relacionales, además de que muchos de los proyectos se originó en el ámbito de la computación distribuida, por lo que no es casual que en el año 2002 se haya presentado una demostración formal del teorema de Brewer6. Dentro de esta iniciativa hay desarrollos de todo tipo, no sólo abiertos, incluso de licencias duales. Vamos a explorar algunos modelos y desarrollos Open Source de dicho movimiento: 

3

Orientación a grafos: ite una ascendencia de los antiguos modelos en red, pero en la práctica trabajan más integrados con los lenguajes de programación. Este tipo de bases de datos almacena la información en grafos, una de las estructuras de datos más flexibles existente. Si lo que modelamos tiene muchas relaciones, con un nivel de multiplicidad

Cabe destacar que la industria impuso las bases de datos relacionales, por lo que en los últimos 15 años han surgidos especificaciones de ORM (JPA de Java) y herramientas Open Source como Hibernate (la más popular) que pueden disimular las diferencias de modelos. 4 Que a veces es interpretado como Not Only SQL y que a veces se sugiere que debiera ser No Rel. Y que según sus integrantes vino a compartir como ellos habían logrado derrocar la tiranía de las lentas y caras bases de datos transaccionales a favor de una manera más eficiente y barata de manejar datos. 5 Atomicidad, Consistencia (Integridad), Aislamiento y Durabilidad. 6 También conocido como Teorema CAP, establece que es imposible que un sistema distribuido pueda dar simultáneamente estas tres garantías: Consistencia (todos los nodos ven la misma información), Disponibilidad (la falta de un nodo no impide al resto seguir funcionando) y Tolerancia a Fallos (Partition Tolerance, el sistema sigue funcionando a pesar de pérdidas arbitrarias de información o fallas parciales del sistema). Según el teorema sólo se pueden satisfacer dos simultáneamente de las tres.

alto, las bases de datos orientadas a grafos pueden ser una solución. Suelen, además ser embebibles, es decir, correr en forma nativa en nuestra plataforma de programación. Las áreas de aplicación son múltiples, ya que a veces son utilizadas como bases de datos orientadas a objetos por su facilidad de utilización, en inteligencia artificial y modelado del conocimiento y en web semántica. Algunos proyectos interesantes: o Neo4J: Es una base de datos orientada a grafos (y multigrafos7) que puede correr como server (a partir del segundo server tiene licencia dual) o ser embebida dentro de nuestra solución (GPL). Es transaccional (ACID). No requiere un schema o metadata para estructurar la información que almacena. En cuanto a la estabilidad hay implementaciones de 2003 24x7. En un hardware común tiene una tasa de iteración de 1.000.000 de relaciones por segundo. En una prueba de benchmark se ha generado un grafo con 20.000.000 de nodos representando lugares, 62.000.000 de arcos representando caminos entre los lugares, en promedio encuentra un camino promedio en 100ms, y en el peor de los casos probado, el camino óptimo tenía 5500 tramos y fue encontrado en menos de 3 segundos. ite varias maneras de hacer consultas:   

La API SPARSQL Gremlin: Lenguaje de consultas especialmente diseñado para el análisis y manipulación de multigrafos de propiedades de tipo key/value.

Tiene la habilidad de simplificar algunas operaciones sobre grafos que serían inmensamente complejas sobre bases de datos relacionales, como los algoritmos de grafos:





7 8

 Clausura transitiva  Camino más corto  Routing o HyperGraphDB: Es una base de datos orientada a grafos (multigrafos e hipergrafos8) extensible, distribuible, portable y embebible en entornos Java. Orientación a objetos: o Db4o: Es una base liviana de licencia dual embebibles para entornos Java y dot Net. ite el uso de Linq (dot Net) como lenguaje de consulta así como la utilización de la API en los contextos embebidos. Posee esquemas de replicación complejos utilizables para la extracción de datos a esquemas Business Intelligence. Es ampliamente utilizado en dispositivos móviles. Orientadas a columnas (Wide Column Stores): Son bases de datos optimizadas para procesar en forma distribuida. No poseen una metada como en el caso de las relacionales,

Un multigrafo es un grafo que ite más de un arco entre dos nodos. Un hipergrafo es un grafo que te hiperarcos, es decir, arcos que pueden unir más de dos nodos.





9

por lo que cada entrada puede tener una estructura completamente diferente a la anterior. Se basan sobre mapas (3-uplas) que contienen una clave, un valor (una colección de columnas) y un timestamp. o Hadoop/HBase: Hadoop es un framework del proyecto Apache pensado para el procesamiento distribuido de grandes volúmenes de datos. HBase es la base de datos dentro del framework Hadoop. Más adelante se desarrollarán características de la misma. o Cassandra: Es una base de datos distribuida del proyecto Apache utilizada por Facebook. Más adelante se desarrollarán características de la misma. o BigTable: Es el proyecto de Google con las mismas características. Key-Value Stores: Son bases de datos que poseen un modelo muy sencillo en forma de mapas (o diccionarios) y que son fácilmente distribuibles. Deben ser pensadas como un hashing gigantesco distribuido de alta disponibilidad. o Voldemort: Es un proyecto desarrollado para LinkedIn en Java con licencia Apache basado en los principios de Amazon’s Dynamo. No pretende cumplir las propiedades ACID. Posee un potente esquema de caching en memoria que le otorga un alto desempeño. Como particularidad vale añadir que posee un esquema de versionado automático, que sirve tanto como para versionar datos, como para suplir consistencia. o Riak: También basada en los principios de Amazon’s Dynamo, es un proyecto Open Source de la empresa Basho. Especialmente orientada al procesamiento en la nube. Posee una ventaja notable sobre otros productos: en la declaración de principios de la empresa enumera en qué casos no debería usarse. Fue escrita en Erlang y C. Una particularidad de Riak es que posee implementaciones Masterless, es decir, ningún nodo del cluster funciona como Master de la implementación. Orientadas a Documentos: o MongoDB: Es una implementación Open Source de una empresa (10gen inc) que da servicios relacionados con MongoDB. Consiste en una base de datos documental implementada en C++. Es utilizada por SourceForge, The New York Times y la red social “Diáspora”. Majea esquemas de replicación. Tiene un soporte dinámico para clusterización lógica. No tiene un esquema de multiversionado nativo, en pos de una mejor performance y simplificación del desarrollo. Posee un soporte nativo para tipos de datos geoespaciales (en dos dimensiones) habilitando la posibilidad de consultas de cercanía. o CouchDB: Proyecto Apache de una base de datos documental desarrollada con Erlang9. ite un antecedente en Lotus Notes, dado que parte del equipo que desarrolló para IBM ha constituido la base de este proyecto. Ubuntu One está implementado con CouchDB. Lógicamente es una extensión de las bases de datos

Erlan es un lenguaje de programación utilizado para construir software en tiempo real con requerimientos de alta disponibilidad. Originalmente impulsado por Ericsson.

tipo key-value pair. El manejo de versiones es un punto destacable dentro de CouchDB. Posee un esquema de replicación comparable con Lotus Notes. Y para su interfaz, implementa Web Services ResfFul vis HTTP.

En cuanto al desarrollo tecnológico, el software libre no hizo ningún aporte a las bases de datos. Las empresas fabricantes de bases de datos como Oracle le deben bastante (económicamente hablando) al software libre. De hecho el 40% de las instalaciones de la base de datos Oracle corre sobre Linux. La maximización de la ganancia hizo que el paradigma reinante en bases de datos (relacional) no acompañe al paradigma de desarrollo (orientación a objetos) durante fines de la década del 80’ y principios de los ’90. Tanto así, que la solución a dicha situación (una diferencia de impedancia entre los modelos) se zanjara con ORM10. Pensado desde la ciencia, un ORM no tiene razón de ser, pero en la práctica de la industria fueron enteramente necesarios para poder desarrollar software realmente orientado a objetos. En estos momentos de concentración económica, claramente las bases de datos libres tensionan para mejorar la tecnología. En particular las bases de datos libres NO SQL11 son las que obligan a las privadas a mejorar continuamente. De hecho la batalla cambió de paradigma cuando Oracle comenzó a disponer de Sun. Con el hardware de Sun, Oracle desarrollo una caja de base de datos (montada sobre Linux) llamada Exadata (cuya versión ligth cuesta medio millón de dólares) que por fuerza bruta de pilas de tecnología corre la barrera de lo “No Procesable” más allá de las fronteras existentes. Computacionalmente no es un mérito, es un mérito desde el punto de vista ingenieril. El mérito computacional corresponde a las bases No Rel que permiten que plataformas como Twitter o Facebook puedan correr prácticamente en tiempo real, bajando el orden de complejidad del procesamiento de datos.

Zonceras por ignorancia Nadie las usa. En los países serios no se usan. Esta es una falacia que tiene tanto que ver con ignorancia como con coloniaje mental. Siempre que alguien cite contradicciones entre países serios y no serios hay que preguntar dónde funcionan los tribunales del universo. No hay tales países serios y no serios, hay otras categorías de países, pero esa es inadecuada. Por otro lado, es también falso que no se usen bases de datos abiertas. Las principales redes sociales tienen en el centro de su estrategia IT bases de datos abiertas, vamos a explorar someramente el ejemplo de Twitter.

10 11

Object-Relational Mappers. Que en realidad debieran llamarse NO Rel.

En diciembre de 2010 Twitter generó una gran cantidad de datos que estaba en el orden de los 12 terabytes diarios. Al principio utilizaron para recolectar información el protocolo Syslog12 a través de la herramienta syslog-ng (licencia dual). Syslog funciono correctamente al principio pero a medida que iba aumentando la demanda, en situaciones de sobrecarga comenzó a perder información. Facebook también tuvo este problema, y para solucionarlo crearon un sistema llamado Scribe. Scribe es un servidor para la acumulación o colección de datos. Está diseñado para que sea escalable a una gran cantidad de nodos y ser lo suficientemente robusto para soportar fallas en la red y en los nodos. A pesar de este cambio, hay casos particulares en los que Scribe puede sufrir una pérdida de datos, por lo que tuvieron que tomar ciertas decisiones de diseño, como mejorar la confiabilidad de la infraestructura con la disposición de los servidores en forma de grafo dirigido. Una vez solucionado el problema de la recolección de datos surgió otro diferente. Como se hace para almacenar 12TB de datos cuando un disco rígido tiene una velocidad de escritura de 80MB/s? Linealmente implica 43 hs para almacenar los datos recolectados en un solo día. Por este motivo necesitaron un cluster, y cuando se tiene un cluster se agregar nuevas capas de complejidad, ya que los datos se empieza a escribir en diferentes lugares, que datos se van a guardar en cada lugar, como se van a particionar estos datos, que pasa si las maquinas se caen son algunos de los problemas que hay que solucionar. Con el fin de mejorar estos puntos, el equipo ha utilizado Hadoop, que es un framework open source para escribir y correr aplicaciones distribuidas que procesan grandes cantidades de datos. Hadoop corre en clusters de gran tamaño en máquinas comunes y corrientes sin necesidad de ningún hardware específico, es por eso que la arquitectura de Hadoop asume que van a haber muchos problemas de hardware. Hadoop permite escribir código que corra de manera paralela muy fácilmente. Está formado por una colección de subproyectos relacionados entre sí, que tienen como objetivo común crear una infraestructura para la computación distribuida:  

12

Abro: Es un sistema para serializar datos que permita realizar de manera eficiente RPC entre diferentes lenguajes y el almacenamiento de datos. MapReduce: Es un modelo de procesamiento de datos distribuido introducido por Google que corre en clústeres de máquinas comunes y corrientes. La mayor ventaja que posee es la facilidad de escalar el procesamiento sobre múltiples nodos. Bajo el modelo MapReduce las primitivas para el procesamiento de datos son llamadas mappers y reducers. Descomponer un problema en mappers y reducers puede no ser algo trivial, pero una vez que la aplicación fue escrita es muy fácil escalarla para que corra en miles de nodos o incluso más. Cada operación “Map” es independiente del resto y por lo tanto pueden ser realizadas en paralelo. Lo mismo sucede con el “Reduce”, es realizado en paralelo, lo único que se necesita para que suceda esto es que las respuestas a todos los sub-problemas sean devueltos de forma simultánea.

estándar utilizado para el almacenamiento de mensajes que permite separar el software que genera los mensajes del que los almacena y del que los analiza



   



HDFS: (Hadoop Distributed FileSystem) Es un file system distribuido diseñado para correr en hardware común. Las diferencias con el resto de los DFS son significativas. Tiene una gran tolerancia a fallas y no se necesita hardware especial ni costoso, tiene un muy buen rendimiento para la lectura y escritura y es excelente para aplicaciones que manejan grandes cantidades de datos. Está diseñado para almacenar de manera confiable archivos grandes a lo largo de diferentes maquinas en un cluster. Las aplicaciones que corren en un HDFS tienen grandes conjuntos de datos. Un archivo típico almacenado en un HDFS está entre los gigabytes y los terabytes. Por este motivo el file system está ajustado para soportar grandes archivos. Pig: Es un lenguaje y ambiente de ejecución para la exploración de grandes cantidades de datos. Pig corre en HDFS y en clusters MapReduce. HBase: Es una base de datos no relacional. HBase usa para el almacenamiento de datos HDFS. ZooKeeper: Es un servicio para la coordinación de sistemas distribuidos. Hive: Es un data warehouse distribuido. Los datos están almacenados utilizando HDFS y provee un lenguaje para realizar consultas, basado en SQL (que luego es traducido a jobs de MapReduce). Chukwa: Es un sistema distribuido de colección y análisis de datos. Chukwa corre colectores de datos que los almacenan en HDFS y luego utiliza MapReduce para generar los reportes.

Además de Twitter, Hadoop es usado por: 



Yahoo: Más de 100.000 Us en más de 36.000 computadoras o El cluster más grande tiene 4.000 nodos. o El 60% de los trabajos de Hadoop son programados con Pig. Facebook: Actualmente tienen dos clusters o 1.100 máquinas con 8.800 núcleos y 12 PB de almacenamiento. o 300 máquinas con 2.400 núcleos y 3 PB de almacenamiento.

Respecto a la performance, Hadoop logró ordenar un Petabyte de datos en 16,25 horas y un Terabyte en 62 segundos. Para entender la velocidad que tiene esto se podría comparar contra lo que se tardaría en acceder a todo un Terabyte de datos sin hacer ningún tipo de ordenamiento, solo leer. Los discos SATA I tienen una velocidad de lectura de aproximadamente 150 MB/s, a esta velocidad se tardaría prácticamente dos horas en solamente leer el disco.

HBase es la base de datos de Hadoop, ambos están escritos en Java. Es una base de datos orientada a columnas que está construida sobre HDFS. Esta aplicación debe ser utilizada cuando se requiere realizar escrituras/lecturas en tiempo real sobre grandes conjuntos de datos. Fue pensado con la idea de la escalabilidad, la posibilidad de que el sistema crezca simplemente agregándole nodos. Es una base de datos no relacional y no soporta SQL, pero aplicándola al problema adecuado es capaz de hacer lo que una base de datos relacional no puede: capaz de guardar grandes tablas con datos esparcidos en clústeres hechos de hardware común y corriente. Paralelamente cabe destacar el caso de Cassandra, una base de datos utilizada por Facebook y Twitter, que es un proyecto de Apache diseñado para manejar grandes cantidades de datos separados por varios servidores mientras provee con alta disponibilidad de servicio sin ningún punto de falla. Es una solución NoSQL que fue inicialmente desarrollada por Facebook para el buscador de mensajes. De hecho, en Twitter, Cassandra reemplazó a la instalación de MySQL13. Como en todo sistema NoSQL, cada uno tiene sus ventajas y desventajas. Actualmente en Tweeter conviven ambos sistemas donde cada uno cumple un rol diferente. HBase se encarga de los análisis y la generación de las bases de datos, y Cassandra se encarga de los sistemas online. Actualmente Microsoft piensa delegar varias funciones de la base de datos SQL Server 2012 en Cassandra.

Todos los productos mencionados anteriormente no lograban solucionar el problema real que Twitter tenía que enfrentar en el momento de guardar, procesar y mostrar los datos que producía el sistema online. Por esta razón crean como producto propio el FlockDB, el cual es una base distribuida en tiempo real de un grafo social. FlockDB no está optimizado para hacer minería de datos (DM). Pero en cambio, está construida para solucionar un problema específico, que son los cálculos con el grafo de un nivel. El problema más grande de este tipo es buscar una solución óptima para todos los nodos, sean nodos (s) con 8 conexiones (8 followers), o nodos con 6 millones de conexiones. También sus intersecciones ya que en tiempo real y baja latencia tiene que solucionar la intersección de dos nodos sin importar la cardinalidad de cada uno.

Zonceras por razones de inseguridad psicológica o o o o o

13

No me da ninguna tranquilidad. ¿Y quién me da soporte? ¿Y quién me garantiza que anda? Más vale comprar algo de marca. ¿Te parece que va a andar ese programita?

MySQL solo permite particiones verticales y horizontales. Casandra tiene un esquema descentralizado lo cual permite particionar las tablas donde sea necesario y a prueba de fallos.

En IT, el sentido común plantea lugares seguros e inseguros sobre datos aportados, no por la realidad, sino por las publicaciones que hace la industria, que obviamente sesgan de imparcialidad la cuestión. Respecto al soporte, las mismas organizaciones que construyen los proyectos viven de dar soporte y capacitar (o hacer consultoría), es por eso que si dan un mal soporte, directamente desaparecen del mercado. La lógica extraída de la realidad nos dice que una empresa que vive del soporte debiera dar un mejor soporte de una que vive de las ventas de licencias y terceriza el soporte. Respecto de las garantías, un IT Manager se queda tranquilo si viene un funcionario de una multinacional y le dice “Quedate tranquilo, mi software funciona”. Lo que debiera hacer es leer la letra chica de los contratos, en donde se dan garantías absolutamente limitadas y legalmente discutibles del producto que se está licenciando. En este caso, están en igualdad de condiciones con las bases open source. Hay algo que el software privativo no puede superar: Veamos el ejemplo de una base de datos SQL in Memmory: HSQLDB. Gran cantidad de software open source redistribuye HSQLDB, por tanto los testers (directos o indirectos) de HSQLDB son exponencialmente superiores a los que posee una base privativa. Vale decir, los commiters de HSQLDB no se pueden permitir introducir un error al código de HSQLDB, sin que millones de testers directos o indirectos sufran sus consecuencias. Respecto al “Más vale comprar algo de marca”, hay que recordar que en muchas organizaciones un IT Manager no compra una base de datos, se hace socio tecnológico de su explotación. Esto implica no solamente comprar, sino contar con el personal idóneo para desarrollar y operar los negocios. Hay un sentido despectivo cuando un IT Manager habla de “programita” refiriéndose a un software. Llegado el caso, el software open source está en igualdad de condiciones que el software privativo. En tales casos uno debe rechazar los términos y condiciones de la pregunta: “No puedo responder esa pregunta porque sus términos son falaces”14. No es exclusivo de los IT Managers, ocurrió a lo largo de toda la historia occidental:  

14

Los europeos tienen religiones, en cambio los habitantes originarios del continente americano poseen “creencias” o “supersticiones”. Los europeos desarrollaron el arte, en cambio los habitantes originarios del continente americano hacen “artesanías”.

Sirva como ilustración una ilustración a una pregunta con cuyos términos no podemos acordar: “Usted, en tanto estúpido ¿qué opina del desempeño de SQL Server?

Zonceras de índole económica Lo barato sale caro “Lo barato sale caro” es una frase que deja entrever que por amarretes hemos comprado algo de mala calidad y que hemos tenido que suplementarlo, o tirarlo directamente a la basura. Pero, en este caso, está únicamente comparando costos de licenciamiento. Cero contra x miles siempre es más barato, pero no siempre de peor calidad. Recordemos que mucho software libre no tiene costo de licencia porque los autores consideran que es cobrar por humo, pero los mismos autores o colaboradores suelen ser autores de libros, capacitadores, consultores o socios estratégicos de calidad. El hardware y la infraestructura sobre la que corre software libre no es gratis. Muchas empresas que no escatiman en gastos de licenciamiento (a veces literalmente humo) de software, restringen su presupuesto de hardware, dándole una experiencia al de muy baja calidad. Pero los IT Managers no van a decir “Lo barato sale caro” en cuanto al hardware que compran para sus s, pero sí en el caso del software libre.

Nuestra base de datos es de bajo mantenimiento. No necesita DBA. Esta zoncera tiene origen en la estrategia de Marketing de Microsoft, que para hacer competitivo SQL Server frente a Oracle enarboló la bandera del costo bajo de mantenimiento y de configuración. Esto, sumado a los fanáticos, que todavía hoy estiman que no es estrictamente necesario un DBA, generaron el sentido común de que determinadas bases de datos no necesitan . Esto es completamente falso. Cualquier sistema productivo montado sobre bases de datos que se precie de ser estable y confiable necesita de la intervención de un DBA aunque sea PartTime.

Es muy caro capacitar a alguien El sentido común de la dirección de IT dicta que el software open source (encabezado por Linux) es “más difícil” que el software privativo. Veamos el caso de los DBA, todo DBA debe tener un nivel de conocimiento compatible con una carrea universitaria del área informática. Debe además adquirir conocimiento de istración de bases de datos en el área práctica y debe especializarse en un producto específico. Es decir, si hablamos de 5 años de carrera, más 2 años de experiencia con bases de datos, estamos en el orden de los 7 años. Si a eso le agregamos la especialización en un motor específico, hablamos de un par de meses (según el programa de carrera de los motores comerciales). Ahora, en el caso de las bases Open Source, ese par de meses se sigue

manteniendo. No hay una diferencia significativa. Y si la hubiese sería del orden de meses, que en siete años no tiene relevancia.