Sergio Navarro

Blog

The WP7 Databases Cup: Siaqodb vs SQLCE. Part 1: Inserts (Spanish)

Posted on January 30, 2012 at 3:25 PM

Hola de nuevo!

 

Ya llevo un mes queriendo escribir este post y por fin ha llegado el día, ... hoy el post es una comparativa entre dos bases de datos muy populares para WP7.

Por un lado a finales de 2011 Josue Yeray, comenzaba una serie de posts en los que estudiaba diferentes aproximaciones utilizables para la inserción de datos masivas en una base de datos SQLCE para WP7.

http://geeks.ms/blogs/jyeray/archive/2011/12/21/windows-phone-7-5-inserciones-masivas-en-sql-server-ce-vs-sql-server-vs-mongodb.aspx

http://geeks.ms/blogs/jyeray/archive/2011/12/21/windows-phone-7-5-inserciones-masivas-en-sql-server-ce-vs-sql-server-vs-mongodb-y-ii.aspx

 

Y por otro lado unos meses antes yo me había visto en la obligación de decidir entre Siaqodb y SQLCE. Y mi elección fue Siaqodb. De ahí que me propusiera responder al "reto" lanzado por Josue Yeray. ;)

 

Los motivos principales para tomar mi decisión fueron los siguientes :

  1. Los conjuntos de unit tests de la capa de datos de una pequeña aplicación corrían el doble de rápido cuando utilizaba Siaqodb que cuando utilizaba SQLCE.
  2. Siaqodb es multiplataforma (Silverlight, WPF, WindowsForms, WP7, WindowsMobile, Android and iOS).
  3. Siaqodb dispone de la instrucción Include para establecer en cada consulta que objetos anidados dentro de otro objetos deseamos cargar junto con cada objeto devuelto. SQLCE dispone de una funcionalidad parecida, pero sólo permite establecer que objetos anidados se cargaran al cargar un objeto padre en el momento de creación de un dbcontext. No pudiéndose variar este comportamiento dependiendo de la situación en la que se vaya a utilizar la consulta.

Dicho esto y a pesar de mi manifiesta preferencia por Siaqodb algo que reconozco que se echa en falta en la lista es un test de benchmarking que muestre cuál de las dos bases de datos es más eficiente para los diferentes tipos de operaciones posibles. Al menos un test más fiable que un pequeño conjunto de unit tests para una aplicación.

El artículo lo he dividido en una serie de 4 posts: Inserts, Inserts con Objetos Anidados, Consultas y Updates. Siendo este el primer artículo de la serie.

Para los tests me he basado en el ejemplo de Josue Yeray Misile 1 al cuál he incorporado las mejoras específicas para SQLCE descritas en su Misile 2. Me refiero a la eliminación del campo IsVersion para acelerar las inserciones y la utilización del método InserAllOnSubmit.

He deshechado el uso de hilos pues he considerado que al fin y al cabo es una mejora que beneficia a ambas bases de datos por lo que no debería aportar diferencias significativas entre ambas que es lo que al fin y al cabo trato de sacar a la luz con estas pruebas.

El código fuente utilizado para las pruebas se puede descargar desde el enlace indicado al final del post y los resultados han sido obtenidos usando el emulador de WP7. Apuntar también que los valores de tiempos indicados en las tablas de resultados son dados en minutos.

Las pruebas llevadas a cabo se pueden encuadran en dos ejes. El primer eje se refiere a si la actualización de la base de datos se lleva a cabo de una vez para todos los registros insertados o una vez por registro insertado :

  • 1 Flush: La actualización de la base de datos se lleva a cabo de una sóla vez para todos los registros a añadir. Esta es la estrategia más eficiente y reproduce un escenario en el cual se dispone de todos los datos a insertar en una tabla de la base de datos.
  • N Flushes: Por cada registro de la base de datos a añadir se lleva a cabo una actualización del archivo de la base de datos. Esta estrategia es menos eficiente pero reproduce un escenario en el que los datos van incorporándose gradualmente a la base de datos. Sería un escenario similar al que se dio para los unit test de la capa de datos que ejecuté en su día y en general es muy similar a un escenario en el que los datos vayan a añadirse de forma gradual durante el ciclo de vida de la aplicación.

El segundo eje de pruebas se refiere a las condiciones que debe cumplir la clase de test a guardar en la base de datos. Por ejemplo mientras que SQLCE obliga a que definamos una clave primaria de entre los campos de la clase a guardar, Siaqodb no nos obliga a ello pero si que nos obliga a que definamos un campo OID que es una especie de campo autonumérico que hace las veces de clave primaria y es gestionado por Siaqodb. A partir de estas restricciones y partiendo de la propuesta de clase de test establecida por Josue Yeray, estos son los grupos de pruebas que he definido:

  • Condiciones SQLCE: La clase de test usada debe tener como clave primaria un campo Guid, independientemente de si tiene o no además definido un campo autonumérico OID.
  • Condiciones Siaqodb: La clase de test usada debe tener una clave autonúmerica, el campo Guid es un simple campo más no es ni indexado ni con restricción unique.

En cuanto a la forma de decidir el ganador me ha parecido divertido plantearlo como una eliminatoria de la copa del rey a ida y vuelta con sus correspondientes primera y segunda parte :P.

Partido de ida: Condiciones SQLCE

Primera Parte: 1 Flush

Comienza la eliminatoria en la cancha de Microsoft. Ambos equipos arrancan el partido con todo por delante y buscando no defraudar a sus respectivas aficiones ...

Las ejecuciones de SQLCE:

  • SQLCE (1 Flush) Index + Unique + Guid : Utiliza el campo OID autonumérico como clave primaria y el campo Guid como campo indexado con restricción Unique.
  • SQLCE (1 Flush) Index + Unique + Guid + No Autonumeric : Utiliza el campo Guid autonumérico como clave primaria. Se prescinde del campo autonumérico OID por no ser necesario para SQLCE.

Las ejecuciones que utilizan Siaqodb son:

  • SIAQODB (1 Flush) Index + Unique + Guid : La tabla de test utiliza el campo Guid indexado y con restricción Unique, además de el campo OID autonumérico obligatorio para Siaqodb.
  • SIAQODB (1 Flush) Index + Unique + Guid : Se utiliza la misma tabla de test que la anterior ejecución pero en lugar de utilizar el método estándar de almacenamiento en bd, se utiliza un método específico de Siaqodb para acelerar las inserciones masivas.


A la vista de los resultados no es fácil decidir cuál de las dos bases de datos se ha adelantado en el marcador. En términos absolutos, por poca diferencia Siaqodb a conseguido el mejor tiempo para 500.000 elementos insertados en la base de datos pero a muy poca distancia de los resultados obtenidos por las ejecuciones de SQLCE. Sin embargo si hablamos de un número de elementos insertados en la base de datos algo inferior, 100.000 elementos, los resultados se invierten.

 

Por tanto considero que el resultado de la primera parte es un empate a 0 pues ninguna de las dos bases de datos a conseguido imponerse claramente a su contrincante.

 

Con esto nos vamos al descanso ...


Segunda Parte: N Flushes

En el campo de Microsoft se respira la tensión en los minutos previos al comienzo de la segunda parte. Al fin y al cabo Siaqodb no es más que un recién llegado a la competición y nadie esperaba que le pusiera las cosa tan difíciles a un líder de la competición como SQLCE.

 

Hay que tener claro que la segunda parte será para aquella base de datos que mejor comportamiento tenga para la mayoría de inserciones que se realizan a lo largo del ciclo de vida de la aplicación, me refiero a aplicaciones con numerosas inserciones pero de pocos elementos cada una. Veamos que cambios han habido en las alineaciones de ambos equipos.

 

Ejecuciones con SQLCE:

  • SQLCE (N Flush) Index + Unique + Guid : Utiliza el campo OID autonumérico como clave primaria y el campo Guid como campo indexado con restricción Unique.
  • SQLCE (N Flush) Index + Unique + Guid + No Autonumeric : Utiliza el campo Guid como clave primaria. Se prescinde del campo autonumérico OID por no ser necesario para SQLCE.

Ejecuciones con Siaqodb :

  • SIAQODB (N Flush) Index + Unique + Guid : La tabla de test utiliza el campo Guid indexado y con restricción Unique, además del campo OID autonumérico obligatorio para Siaqodb.


 

Vemos como a ambas bases de datos le cuesta más de lo esperado añadir 100000 elementos o más a una tabla, cuando estos son añadidos uno a uno. En ciertos escenarios donde sea necesario añadir registros a tablas que ya cuenten con un alto número de elementos deberemos ser conscientes del alto coste temporal que puede suponer añadir nuevos registros a las mismas.

 

A pesar de este comportamiento similar para ambas, en esta parte de las pruebas el claro ganador es Siaqodb ya que mientras que Siaqodb sólo necesita 1 minuto para insertar 10000 elementos en una tabla, SQLCE necesitaría media hora para hacer esa misma operación.

 

Luego sin haber mostrado un gran juego ninguno de los contendientes en esta segunda parte, Siaqodb se ha apuntado un tanto que le ha dado la victoria por la mínima en el partido de ida en el feudo de Microsoft SQLCE. La verdad es que después de ver la igualdad en este primer partido, el partido de vuelta en casa de Siaqodb promete muchas muchas emociones.

Partido de vuelta: Condiciones Siaqodb

Primera Parte: 1 Flush

Arranca el partido en el campo de Siaqodb. Un estadio más modesto que el de Microsoft pero que suple con creces sus carencia gracias a la entrega y el entusiasmo de cada uno de sus miembros. Aquí van las alineaciones

 

Las ejecuciones que utiliza Siaqodb son :

  • SIAQODB (1 Flush) Index + Autonumeric Key : La tabla de test utiliza el OID autonumérico obligatorio para Siaqodb y el campo Guid que ni es indexado ni tiene restricción unique.
  • SIAQODB (1 Flush Massive Insert) Index + Autonumeric Key : Se utiliza la misma tabla de test que la anterior ejecución pero en lugar de utilizar el método estándar de almacenamiento en bd, se utiliza un método específico de Siaqodb para acelerar las inserciones masivas.

Las ejecuciones de SQLCE son :

  • SQLCE (1 Flush) Index + Autonumeric Key : Utiliza el campo OID autonumérico como clave primaria y el campo Guid sin indexar y sin restricción unique.


A la vista de los resultados comprobamos como Siaqodb cuando juega en su campo (con sus condiciones) obtiene mejores tiempos que SQLCE. Ampliándose de hecho su ventaja a medida que el conjunto de datos aumenta.

 

Con esto al final de la primera parte el resultado es un 0-1 a favor de Siaqodb que parece estar sentenciando la eliminatoria del lado del aspirante.

Segunda Parte: N Flushes

El campo de Siaqodb es una fiesta cuando comienza la segunda parte. ¿Será capaz SQLCE de al menos de igualar el marcador en esta segunda parte?


 

De nuevo como en la segunda parte del partido de ida, Siaqodb se muestra muy superior a su contrincante a la hora de insertar muchos datos de uno en uno en la base de datos. Eso si ambas muestran sus limitaciones cuando alcanzan los 100000 elementos insertados en una tabla uno a uno.

 

Finaliza el partido con un claro 2-0 para Siaqodb

Resultado de la Eliminatoria: Conclusión

La eliminatoria se saldó con un marcador contundente de 3-0 a favor de Siaqodb. Quizás este marcador resulte demasiado abultado si sólo miramos las diferencias de tiempo entre ambas bases de datos, pues al fin y al cabo estamos hablando de situaciones un tanto excepcionales en las que trabajamos con una gran cantidad de datos, cuando lo habitual en una aplicación para un dispositivo móvil es que se utilicen cantidades de datos más reducidas. Sin embargo si recordamos los puntos al principio del post, donde mencionaba que Siaqodb es multiplataforma, claramente me parece que Siaqodb es digno merecedor de tan abultado resultado.

 

Veremos que ocurre en los siguientes posts cuando evaluemos otros tipos de operaciones...


Código Fuente: http://jersiovic.webs.com/SiaqodbvsSQLCE/wp75_MissileOne_WithSergioNavarroChanges.zip

Nota: Para hacer funcionar el proyecto necesitareiss añadir una referencia a la dll de Siaqodb para Mango. Además de obtener un código de licencia de prueba de 30 días. Ambos se pueden obtener desde la sección Downloads de la web de Siaqodb http://siaqodb.com .

Categories: None

Post a Comment

Oops!

Oops, you forgot something.

Oops!

The words you entered did not match the given text. Please try again.

Already a member? Sign In

0 Comments

Twitter