Encontré pocas afirmaciones de que el uso de CacheDB en lugar de RDBMS comprobado. ¿Pero no podría entender cómo es mejor que RDBMS? si es así, ¿por qué tienen el prefijo Cache?¿Has utilizado Intersystems Caché? ¿Cuál es tu experiencia?
¿Se trata de un servidor RDBMS o Caché? ¿Podría escribir notas breves sobre el caso de uso en su proyecto?
caché es una bestia única, dependiendo de cómo lo usa, entonces podría ser descrito como una base de datos SQL No, un RDBMS, o un objeto base de datos orientada. Por supuesto, no es todo para todas las personas, por lo que saber de qué manera es cada uno necesita alguna explicación.
Todo está construido sobre un lenguaje de procedimiento pre-relacional llamado MUMPS (nombre de marketing terrible que también es terrible para Google, así que ahora solo usan Caché, que es solo terrible para Google). Este lenguaje incluye operaciones para persistir datos como comandos nativos, por lo que el motor de persistencia se puede optimizar sin afectar el código de la aplicación.
Este idioma tiene un tipo de colección, un diccionario de clave/valor con 0 o más claves ordenadas, y un tipo de datos, que tiene operadores para hacer cosas fibrosas y otros para hacer muchas cosas. Todas las claves y valores son instancias de ese tipo de datos.
Esto ha estado por mucho tiempo, y las aplicaciones de hace décadas escritas encima de esto todavía se ejecutan.
Este lenguaje es anterior al primer RDBMS, pero los implementadores posteriores del lenguaje agregaron el soporte RDBMS. Cache compila SQL (estática o dinámicamente) en una versión más moderna de MUMPS, que luego controla el motor de almacenamiento. Si esto suena raro, en realidad no es así: cada RDBMS compila o interpreta SQL en instrucciones para su motor de almacenamiento.
La memoria caché se ha convertido en un lenguaje orientado a objetos (como muchos otros lenguajes lo han hecho a lo largo del tiempo), lo que significa que ahora hay 2 tipos de datos, el original más el tipo de objeto. Los objetos no se pueden almacenar como claves o valores directamente en el disco, pero pueden heredar o implementar métodos de persistencia.
Para que las personas que usan Cache puedan usar código orientado a objetos, SQL o código de procedimiento, o combinarlos como lo deseen.
¿Cuáles son las ventajas y desventajas?
Para las personas que ejecutan aplicaciones MUMPS heredadas, prácticamente no tienen otra opción, así que me centraré en todos los demás.
Una gran desventaja es que tiene una pequeña cuota de mercado (en comparación con otros RDBMS, aunque podría compararse con otros productos) y tiene un precio en el mismo estadio que un RDBMS comercial (aunque es probablemente mucho más fácil elaborar un trato individual para un uso peculiar particular de él), por lo que debe haber algún tipo de razón convincente para comprarlo.
Además, la pequeña cuota de mercado significa un mercado más pequeño para los desarrolladores. Además, las diferentes maneras en que puede usarse significa que no todos los desarrolladores de Cache son adecuados para todos los proyectos: alguien que mantenga una aplicación heredada (desde antes de la programación estructurada) durante los últimos 20 años podría no ser muy útil al usar Cache para web orientada a objetos aplicaciones.
Otro problema es que prácticamente no hay bibliotecas de códigos fuera de lo que proporciona Intersystems (el proveedor), y esas no pueden competir con algo como .NET o Java en tamaño.
Una gran ventaja es que Cache Object Script (el moderno lenguaje MUMPS) es mucho más lenguaje de lo que usualmente se obtiene dentro de una base de datos. Esto es más una ventaja cuanto más lógica de negocios tenga en la base de datos.
En realidad, en mi humilde opinión, la mayoría de las ventajas de la memoria caché se obtienen si la usa para su lógica comercial. La combinación de su base de datos y la lógica de negocio es mucho más simple, más fácil de obtener un alto rendimiento, y no conduce particularmente a problemas de mantenimiento a largo plazo cuando el entorno lo soporta tanto.
La desventaja de combinar bases de datos y lógica de negocios en Caché es que portarlos será bastante difícil, y generalmente su lógica comercial está escrita en un lenguaje libre y no necesita una licencia de ningún tipo para ejecutarla. Aquí está prácticamente en el mismo barco que si su lógica comercial está en TSQL, excepto que es aún más difícil de transportar.
Si es O.K. con eso, sin embargo, muchas cosas son encantadoras. Sin ORM: comercial o codificado a mano. El SQL se compila en un código que se puede ver (se genera para que esté optimizado para velocidad sobre legibilidad y los nombres de variables pueden ser cosas como 'T32', pero aún así es legible si es necesario), incluso paso a paso o punto de interrupción. El costo de escribir cursores de SQL es muy bajo. Puedes escribir código orientado a objetos. Se interpreta, por lo que es más fácil desarrollarse rápidamente. Si desea velocidad, puede desactivar las transacciones e ir a No SQL.
También he encontrado que es muy fácil de administrar. En la mayor parte de mi experiencia con él, no existe un DBA, simplemente no necesitas uno.
Intersystem's Cache se puede definir como Base de Datos Orientada a Objetos.
La forma en que lo pienso es que es una base de datos RDBMS regular con un motor de scripts orientado a objetos. Oracle tiene procs almacenados, Cache tiene un script Object.
Estamos migrando a Intersystems Cache para aprovechar sus herramientas de informes BI &. Todavía no me he encontrado con una situación que no se puede resolver con el procedimiento almacenado de MySQL u Oracle todavía. Prefiero escribir todo en los procedimientos de SQL para evitar futuros dolores de cabeza en la migración.
Las personas con un fuerte fondo orientado a objetos pueden preferir el uso de ObjectScript.
En caso de que no lo han visto, aquí está their documentation
No es RDBMS por diseño. Es una base de datos de objetos. puede usar la interfaz sql y ver datos como procedentes de RDBMS tradicionales.
Lo estaba intentando hace unos años, solo para un proyecto de pasatiempo, principalmente para aprender.
Una cosa notable es que antes de 'todas esas cosas en la nube' ya tenían un sistema, donde puedes almacenar datos a través de un nodo, y lo replicará para muchos otros nodos. Entonces, si necesita escalar, puede hacerlo. Fue hace 10 años cuando la replicación de datos entre las bases de datos fue realizada por herramientas internas, afaik. Afirman que hay un sistema con 50 mil personas más que trabajan en línea con una base. La replicación se puede hacer de varias maneras.
Los datos se almacenan en árboles, lo llaman globales. Y todo lo que almacenas es árbol. Tienen acceso a objetos, en realidad los objetos en la base de datos son objetos en su idioma (Objectscript, creo que tenían soporte para Java). Hay una herencia real en los datos (los globales, llamarlo tabla no sería correcto). Entonces no hay necesidad de hibernate/orm/jpa/... cosas.
Sin embargo, el lenguaje es hmm. Si te gustan los revestimientos Perl one, estás bien. De lo contrario, está desafiando.
No estoy de acuerdo con el comentario final de que no hay un DBA. Simplemente se incluye normalmente en el rol del equipo de programación, que tiene que hacer las tareas generales de DBA. Dentro de mi empresa, el rol del DBA se divide esencialmente entre 3 personas 1 programas Cambios de base de datos, 1 implementa estos cambios, otro mantiene copias de seguridad y ajustes de rendimiento. Como hay pocas herramientas de rendimiento, hemos tenido que contratar Intersystems en múltiples ocasiones para las tareas de optimización de DBA. La principal desventaja es que los programadores de caché son raros y, por lo tanto, los costos de mantenimiento del producto aumentan. – Andrew
@Andrew: solo puedo hacer lo que he escuchado o escuchado a la gente, y tal vez eso sea atípico. Nunca he tenido tanto trabajo como describe en implementación, copia de seguridad y ajustes de rendimiento. Pero estoy de acuerdo en que hay pocas herramientas de rendimiento y los programadores son raros. – psr
Bueno, en cierto sentido, diría lo mismo sobre MySQL, MS SQL, etc. Conozco muchas organizaciones que tienen una o más de estas bases de datos ejecutándose sin un DBA. Tiende a encontrar la "necesidad" de un DBA en función del tamaño de los datos en los que está trabajando, la frecuencia de las actualizaciones y su importancia relativa (y tal vez más importante) para su empresa. Tenemos una base de datos de caché y 2 personas realizan tareas de DBA. Tenemos muchas bases de datos MySQL que después de la instalación han tenido una participación de 0 DBA. – Andrew