Vertica vs RDBMS y la base de datos tipo noSQL

Las bases de datos de documentos o valores-clave suelen ser buenas para los datos sin estructuras. Por lo general, los casos en que no necesita definir explícitamente su esquema al frente y puede incluir nuevos campos sin ninguna ceremonia.

A menudo es muy fácil escalar bases de datos de documentos / valores-clave. Solo por más partes de los mismos ( conocidos como nodos ) y asi replican los datos para ofrecer más protección contra la pérdida de datos o corrupcion de las seudo relaciones.

En contraparte, las consultas complejas, o enfoque en informes, las consultas dinámicos se sirven mejor desde un RDBMS. 

Sin embargo las bases de datos relacionales al tener muchos datos empiezan a ser lentas e incluso tener deficiencia en la busqueda de datos dado el tamaño de los mismos, efectos que no sufren las bases de datos basadas en documentos o clave-valor.

Introducción a Vertica DB

Vertica rompe el escenario de la base de datos para dos cosas que son lo primero los gerentes de tecnología realmente ven, su nivel de compresión de datos y la rapidez brutal de consulta ( ambos en datos almacenamiento y transmisión ); así como el servicio semi-libre que están ofreciendo. Pero todos esos son geniales solo si la compañía que implementa su tecnología ya es también una empresa de tecnología.

Pero, ¿qué pasa si la compañía intenta crear un nuevo software de alta redacción de datos con alto el almacenamiento de datos por volumen no se centra principalmente en la tecnología y no puede gastar eso mucho sobre tal cosa? Pero parte de la información no es tan cierta, es No de código abierto per se. También tenemos que tener en cuenta el mundo actual de tensión política compulsiva!

Sin embargo Vertica tiene varias factores limitantes, aparte de ser un producto enteramente cerrado, vendiendose falsamente como producto abierto. Esto es aclarado en las secciones finales.

Introcuccion a Percona + Myrocks

Puede pensar en Percona como un distribuidor que recopila, coordina y mantiene parchea y distribuye una versión mejorada del servidor MySQL.

Esto es porque se puede inicialmente emplear MySQL de manera tradcional y despues migrar la data tranquilamente a RocksDB, sin cambiar el engine y permitiendo que cualquier desarrollo sigua el mismo curso. Este es el camino de la gerencia de tecnologia de los grandes de los datos.

Inspirado en RocksDB, myrocks es un plugin del motor Mysql mejorado de percona que actualmente es empleado en Faceebook y twitter. Ofrece las capacidades de compresion de un  engine tipo documento/clave-valor, compresion y menos espacio utilizado y una mayor resistencia del almacenamiento a lo largo del tiempo, pero falta de rendimiento si el subyacente el hardware de almacenamiento no es SSD, por lo que RocksDB necesita varios sistemas operativos clave + HArdware características para tener resultados.

La biblioteca es mantenida por el Equipo de Ingeniería de Base de Datos de Facebook. Es una bifurcación del LevelDB de Google optimizado para explotar muchos núcleos de CPU, y hacer un uso eficiente del almacenamiento rápido, como unidades de estado sólido ( SSD ), para cargas de trabajo vinculadas de entrada / salida ( I / O ).

Consideraciones

En ambos casos hay que tomar consideraciones antes de tener las conclusiones: tanto para Percona como para Vertica, especialmente cuando Vertica es un hibrido realmente y no es abierto como lo venden.

Consideraciones para sabores de Percona

Percona XtraDB es compatible con InnoDB de forma predeterminada. Puedes leer y escribir el mismos archivos de datos, y todas las consultas SQL se ejecutan exactamente igual. Ni siquiera te darás cuenta la diferencia.

Percona PosggreSQL no tiene muchas diferencias, solo una mejor integración y fácil de usar para administradores. Esto es PostgreSQL es tan complejo y tan escalar ya.

Las mejoras en Percona Mysql XtraDB son sutiles. Son soluciones internas para resolver cuellos de botella de escala específicos. Estos cuellos de botella no necesariamente afectan sus aplicaciones o entorno, en cuyo caso Percona XtraDB funcionaría exactamente como stock InnoDB. Algunas de las mejoras en Percona XtraDB demostraron son útiles, por lo que las versiones posteriores de Oracle MySQL y MariaDB implementaron y hoy XtraDB e InnoDB son muy similares.

    • El mutex de la piscina de amortiguación se divide en cuatro subtipos de mutex, para reducir la contención cuando tienes una gran cantidad de clientes concurrentes. 

    • Inserte las opciones de búfer para el tamaño máximo y la velocidad de fusión. Bueno cuando tienes mucho índices y una tasa muy alta de operaciones de inserción / actualización / eliminación. 

    • El hash adaptativo puede dividirse en múltiples particiones. Bien si tienes un alto cantidad de subprocesos que ejecutan consultas concurrentes sobre índices no primarios, tanto que está causando contención en el índice de hash adaptativo mutex. 

    • Algoritmo de suma de verificación de página más rápido. Bueno si tienes una alta tasa de enjuagues de página en almacenamiento SSD. Esta característica es obsoleta en MySQL 5.6. 

    • Maneje las tablas corruptas emitiendo una advertencia y marcando la tabla inutilizable, en lugar del comportamiento predeterminado de bloquear deliberadamente el servidor MySQL. 

consideraciones para Vertica DB

La mayor ventaja de Vertica es la velocidad bruta. Es extremadamente rápido cuando en comparación con otras bases de datos analíticas, y cuenta con características que hacen uniones extremadamente rápido. Las compensaciones son los altos costos de licencia, actualizaciones lentas y necesidad insaciable de comer a través de toneladas de espacio en disco. Si, esto ultimo es ironico.

Vertica nunca sobrescribe el archivo de datos en las actualizaciones, por lo que cada vez que actualiza y nueva escritura SO sucederá. Este es un inconveniente de la filosofía de almacenamiento de valor clave, y para una base de datos relacionales, esta no es la buena opción.

Vertica no se utilizará para reemplazar sus datos relacionales en la base de datos OLTP, esto está ahí para hacer el trabajo pesado y ayudarlo a hacer el análisis con menos gasto ( tiempo, dinero ). Vertica es más para BI que para almacenamiento de información.

Vertica tiene datos comprimidos y datos codificados, los datos comprimidos requerirán algunos ciclos adicionales de cpu mientras se recupera, pero la mayoría de las veces Vertica usa la codificación como describe la siguiente fuente http://www.aodba.com/tut_output_mysql.php?tut=6&page=vertica la codificación crea huellas más pequeñas y al hacer esto la recuperación de datos será más rápida.

Para un software inventivo de almacenamiento o libro de productos no es la elección correcta. Vertica es una herramienta de BI básicamente.

Vertica es extremadamente costosa, no es código abierto, la versión de código abierto sí no tiene todas estas características clave; precios que comenzó con aproximadamente 100K $ por terabyte, y después de que se hizo popular ahora cuesta 10K $ por terabyte, aún así esto es caro, un servidor totalmente protegido vale menos de 500 $ por mes, incluidos varios terabytes en Alemania.

Vertica miente y no es código abierto 

La versión comunitaria solo permitirá crear un clúster de 3 nodos y un máximo de 1 TB (no hay bkp disponible y otras cosas tampoco son posibles), todos los sitios de desarrollo, homologación o desastre (están bajo la licencia de producción inicial, sin dinero extra) )

Conclusiones

SQL funciona bien como un sistema de procesamiento de transacciones, funciona horrible cuando tratando de consultarlo con fines informativos / analíticos. Este es el caso de Vertica, y toda su forma de almacenamiento de columnas, pero sucede que Vertica es realmente y primeramente un engine relacional tambine, solo que en su manejo internamente emplea nodos para empalar la informacion, es un frankeinstein bastante complejo de desarrollar lo que explica porque su sistema de actualizaciones de seguridad es tan lento y engulle tanto espacio en disco.

Debe elegir Vertica si necesita funciones de informes y consultoría, principalmente inteligencia de negocios, pero no como base de datos para casos de un sistema de software de informacion de productos, ya que no maneja bien las consultas complejas y no se enfoca en relaciones si se escoge el mismo engine Vertica con su capacidad de llave-valor o tipo documento. Esto porque vertica realmente es tambine un sistema de base de datos relacional que puede escoger guardar distinto (documento) la data.

Esto significa que cualquier base de datos basada en columna / clave es simplemente complementaria, no sustituta, y es la razón por la cual Vertica realmente todavía es un RDBMS