caching - ¿Has usado Intersystems Caché? ¿Cuál es tu experiencia?
rdbms intersystems-cache (3)
Me encontré con 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?
¿Es un servidor RDBMS o Caché? ¿Podría escribir notas breves sobre el caso de uso en su proyecto?
La memoria caché de Intersystem se puede definir como base de datos orientada a objetos.
La forma en que pienso es que es una base de datos RDBMS regular con un motor de scripting orientado a objetos. Oracle tiene procs almacenados, Cache tiene un script Object.
Estamos migrando a Intersystems Cache para aprovechar sus herramientas de informes y 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 antecedentes orientados a objetos fuertes pueden preferir utilizar ObjectScript.
En caso de que no lo haya visto, aquí está su documentación
La memoria caché es una bestia única, dependiendo de cómo la use, podría describirse como una base de datos sin SQL, un RDBMS o una base de datos orientada a objetos. 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 (un terrible nombre de marketing que también es terrible para Google, así que ahora solo usan Caché, lo cual es 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 lenguaje 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 aún 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.
Entonces, las personas que usan Caché pueden 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 probablemente sea mucho más fácil encontrar un individuo tratar con algún particular uso peculiar 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 para usar Cache para web orientada a objetos aplicaciones.
Otro problema es que prácticamente no hay librerías de código 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 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 Cache 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 tu lógica de negocio está escrita en un lenguaje libre y no necesitas 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.
Sin embargo, si estás de acuerdo con eso, 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 me pareció muy fácil de administrar. En la mayor parte de mi experiencia con él, no existe un DBA, simplemente no necesitas uno.
No es RDBMS por diseño. Es una base de datos de objetos. puede usar la interfaz sql y ver datos como los provenientes del RDBMS tradicional.
Lo intenté hace unos años, solo para un proyecto de hobby, principalmente para aprender.
Una cosa notable es que antes de ''todo eso de la nube'' ya tenían sistema, donde puedes almacenar datos a través de un nodo, y lo replicará para varios 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.