Qué Velneo incluía en su plataforma de desarrollo una base de datos rápida, fiable y fácil de administrar es algo que todos los usuarios de Velneo conocíamos.
Ahora la Escuela Técnica Superior de Ingeniería Informática de la Universidad de Vigo ha publicado un estudio sobre el rendimiento de Microsoft SQL Server, Oracle y Velneo.
Descarga el informe elaborado por la Universidad
A los usuarios de Velneo no nos sorprenden estos resultados y, si aún no conoces Velneo, este puede ser un buen momento para que te animes a conocerlo
Habrás podido comprobar que en los test de búsquedas Velneo es el claro vencedor. Sin embargo, Microsoft SQL Server es mucho más rápido en todas las operaciones transaccionales.
La base de datos de Microsoft utiliza transacciones en memoria mientras que Oracle y Velneo siguen usando el sistema tradicional de transacciones en disco, sistema más seguro pero que penaliza el rendimiento.
Esta característica puede ser útil en muchas de las transacciones que no sean críticas. Un sistema transaccional en memoria es menos seguro que en disco pero mucho más efectivo.
Según ha comentado Velneo a sus betatesters, Velneo, incorporará también esta posibilidad de gestionar transacciones tanto en memoria como en disco consiguiendo así mejorar enormemente sus rendimientos actuales en operaciones transaccionales.
Hola Jesús,
Lo primero que sigo tu blog y me parece muy intersante todo lo que escribes.
Sólo tengo una preguntilla … Entiendo que SQL Server al realizar las transacciones en memoria sea más rápido que en disco … pero no se por qué es más SEGURO realizar la transacción en disco.
Gracias Jesús, un saludo.
Gracias a tí Carlos,
Al guardar las transacciones en disco en caso de una caída del sistema es posible deshacerlas. Si esas mismas transacciones las tienes en memoria y el sistema sufre una caída sin posibilidad de bajarlas a disco esas transacciones se pierden sin posibilidad de ser deshechas.
Si las transacciones que estás llevando a cabo no son críticas, al gestionarlas en memoria y, siempre que no se produzca lo comentado en el párrafo anterior, su gestión es mucho más rápida pero también menos segura. Sin embargo, en muchos casos no es crítico que una transacción quede a medias si existen procedimientos para rehacerlas o completarlas.
Por este motivo puede ser muy interesante disponer de ambos sistemas para conseguir en unos casos rendimientos como los de Microsoft SQL Server y en otras la máxima seguridad tal y como pueden hacer los 3 sistemas con transacciones en disco.
Saludos.
Hola Jesús,
Hay una cosa que no entiendo mucho. ¿qué quieres decir exactamente cuando dices «utiliza transacciones en memoria»? Hasta donde yo sé, SQL Server utiliza un mecanismo «Write Ahead», que implica que antes de realizar el commit de una transacción y enviar por tanto el ACK a la aplicación que la ejecuta, la escribe en el log de transacciones, archivo que está almacenado en disco.
Muchas gracias por tu blog y por tus respuestas.
Un saludo.
Gracias a tí Rakel,
Voy a tratar de aclarar tu duda explicándote como funciona transaccionalmente Velneo respecto a como lo hace SQL Server, que como muy bien explicas en el momento del commit escribe el log de transacciones en disco.
Antes de comentar las diferencias quiero aclararte que el comentario que hago del sistema transaccional de SQL Server no lo hago como crítica, sino todo lo contrario, como un sistema más moderno con unas prestaciones que el informe ha dejado bien claras y que deseo que Velneo lo contemple para poder conseguir los mismos rendimientos. También te comento que conozco mucho mejor el sistema transaccional de Velneo que el de SQL Server por lo que cualquier aportación que hagas será muy bien recibida.
La primera diferencia entre ambos sistemas es que cuando programas las operaciones de base de datos de SQL Server puedes hacerlas o no transaccionales. En Velneo eso no es posible, es decir, todas las altas, bajas y modificaciones transaccionan siempre. Puede parecer excesivamente estricto inicialmente pero con el tiempo lo agradeces.
La segunda diferencia es que en Velneo derivado de la primera diferencia no es necesario escribir código para indicar el comienzo o fin de una transacción pues el servidor se encarga de hacerlo automáticamente al detectar operaciones de escritura.
La tercera diferencia es que las operaciones en Velneo no se realizan al final de la transacción, es decir, cuando estás dando 100.000 altas. En el momento que estás dando de alta el segundo registro el primero ya está accesible. Es decir se procesan las operaciones individualmente y a la vez se actualiza el fichero de transacciones (el log de transacciones de Velneo en disco). Aunque se procesen las operaciones individualmente en caso de que la transacción no termine se deshacen todas. En SQL Server como bien indicas es al final de la transacción cuando se escribe el log y se ejecutan las operaciones. No voy a entrar a valorar que es mejor o peor, lo que sí está claro es que el sistema de SQL Server obtiene mejor rendimiento.
¿Por qué lo denominé transacciones en memoria? Tal vez tras esta aclaración me comprendas mejor. La gran diferencia entre Velneo y SQL Server es que el fichero en disco con extensión .TRN de Velneo, en el que se guarda toda la información de las transacciones, se actualiza con cada operación. El log de las transacciones de SQL Server se escribe antes de realizar el commit, por lo tanto, durante la ejecución de la función o procedimiento que está generando las operaciones de la base de datos toda la información que se enviará a log de transacciones en disco se almacena en memoria hasta la llegada del commit.
Que las operaciones transaccionales sean rápidas, seguras es muy importante. Pero yo le doy más importancia a la explotación de la información ya que en la mayoría de las aplicaciones empresariales el nº de veces que se graba o actualiza un registro es muy inferior al nº de veces que se lee. Por eso aprecio mucho que las bases de datos optimicen al máximo las búsquedas.
Un saludo.
No comprendo lo que quieres decir. Jarboleya.
«Al guardar las transacciones en disco en caso de una caída del sistema es posible deshacerlas. Si esas mismas transacciones las tienes en memoria y el sistema sufre una caída sin posibilidad de bajarlas a disco esas transacciones se pierden sin posibilidad de ser deshechas»
Pero es que si la transacción se ejecuta en memoria, y se pierde, al completo, eso es precisamente lo que debe ocurrir. Una transacción por definición se debe ejecutar entera o no ejecutarse. Si todos sus resultados se obtienen en memoria, no habría ningún inconveniente en que se pierdan al completo. De hecho es lo que debería producir el rollback.
Desde mi punto de vista, el hecho de que la transacción se ejecute en disco, es tan solo la consecuencia de una inferior optimización de la aplicación.
Por cierto, Jarboleya. Tengo una duda sobre el funcionamiento de Velneo. Dices que el programdor no decide en que momento se inicia y termina una transacción. ¿Que ocurre con las operaciones que deben ser atómicas y que incluyen varias operaciones simples, como una actualización de varias tablas?. No conozco Velneo, pero imagino que debe tener alguna forma para resolver este tema tan común en el desarrollo de aplicaciones. Probablemente no haya entendido a que te refieres.
Hola tristan,
Gracias por tus comentarios
Te respondo a las dos cuestiones a la vez.
Lo que dices, es cierto, se pierde por completo y no es necesario deshacerlas, pero eso lleva implícito que las operaciones parciales no se van produciendo con lo que hasta finalizar la transacción no dispones de esos registros, modificaciones o bajas lo que en algunos casos te puede obligar a modificar tu programación. Todo tiene sus pros y sus contras. Si hablamos de información interactiva durante la transacción tenemos que hablar de transacciones en disco, si lo que buscamos es optimización para mejorar el rendimiento estamos de acuerdo que es mejor en memoria.
Cuando digo que un programador no decide cuando inicia y termina me refiero a que no tiene instrucciones de código para indicarlo, no puedes decidir en que punto de proceso comienza un transacción y cuando termina, un proceso o transacciona o no transacciona en su totalidad. Un programador lo que si puede hacer conociendo como funciona el sistema automático de transacciones de Velneo es utilizarlo de la siguiente forma:
En Velneo la transacción la crea automáticamente el servidor en el momento en que en un proceso, función o demonio detecta una operación de escritura en disco. Eso es algo que va implícito en el gestor de transacciones del servidor y el programador no puede decidir que no se genere la transacción. Es decir toda alta, baja o modificación genera transacción, siempre.
Si un programador en Velneo quiere generar varias operaciones simples cada una con su transacción individual lo tiene muy fácil. Desde el proceso principal (que no genere transacción) puede llamar a otros procesos que sí transaccionan. En ese caso cada proceso llamado crea su propia transacción.
Si por el contrario lo que buscas es crear una única transacción que garantice la ejecución correcta de todas las operaciones (de una tabla, varias tablas o lo que necesites programar) lo tienes muy fácil o bien lo ejecutas todos en un único proceso que transacciona o desde un proceso (que sí transaccione) puedes llamar a otros procesos que también transaccionan. En ese caso los procesos llamados utilizan la transacción «padre» y todas las operaciones quedan englobadas en la misma y en caso de deshacerse lo hace en su totalidad.
Espero haberte aclarado algo como se pueden plantear las transacciones en Velneo. Como ves conociendo su funcionamiento resulta sencillo aplicar la solución que más te convenga en cada caso.
Una de las grandes ventajas de que las transacciones están automatizadas es que cuando tu programas un proceso no tienes que preocuparte si éste va a ser ejecutado de forma directa o llamado por otro proceso ya que es siempre en el proceso principal en el que vas a decidir como programador la forma en que transaccionará y el gestor de transacciones del servidor de aplicaciones ya hace el resto. Reitero lo mismo que dije antes, todo tiene sus pros y sus contras con otros lenguajes tienes un control manual que te permite mayor libertad, sin embargo, con este sistema el programador se olvida totalmente de las transacciones y de los bloqueos ya los gestiona directamente el servidor lo que supone una descarga para el programador.
Saludos.
Buenísimos estos dos videos relacionados con la noticia:
http://es.youtube.com/results?search_query=reggaeton+del+programador&search=Buscar
Hola alores,
Ya había publicado uno de los vídeos en el artículo sobre programadores con buen humor
Gracias por el otro vídeo. Muy bueno también. No sabría por cual decidirme, jeje.
Un saludo.