Informática y Sistemas (β)

bases de datos en la nube

Completando las pruebas de los servicios de SQL Azure en el sitio que implementé hace algunas semanas; debo decir que realmente cumplió con lo prometido, y su programación es trasparente para cualquier desarrollador que haya trabajado anteriormente con .Net y SQL Server. De más está decir que el rendimiento en la fase CTP (esto es, con pocos usuarios y bases de datos pequeñas) es óptimo, por lo que a continuación voy a comentar sobre ciertos aspectos a considerar antes de decidir su adopción.

En línea con mis comentarios anteriores, los servicios de SQL Azure están inicialmente destinados para aplicaciones moderadas, sin grandes ambiciones: esto es dado principalmente a que son servicios de base de datos, y por ahora no se ofrecen modalidades OLAP en la nube con miras a extender las prestaciones integrando Datawarehouse en Azure e incorporando funcionalidades de Inteligencia de Negocios (BI). Por otra parte la migración desde y hacia estas bases de datos está limitada a scripts o servicios de integración (SSIS) externos, lo que puede ser un tópico importante frente a aplicaciones de rápido crecimiento de datos, o intentar migrar una aplicación con varios gigas de información almacenada previamente. En efecto, las herramientas de respaldo (backup o detach) no existen en el contexto de aplicación en la nube.

Para el resto de los casos en que lo anterior no representa una desventaja considerable, los puntos a favor no son pocos:

• La administración se reduce prácticamente solo a la asignación de permisos, dado que el rendimiento, replicación, y procedimientos de recuperación son responsabilidad del proveedor; que asegura la continuidad (casi) perfecta del servicio.
• Los costos del servicio frente a los de una instalación particular del producto SQL Server, equipos necesarios, personal dedicado e infraestructura física para ofrecer un servicio y performance equivalentes son prácticamente irrisorios. La comparación de la inversión se inclina hacia la conveniencia de este servicio, con una diferencia tipo de entre 5 a 15 años a favor del mismo, según el volumen de datos en juego para igualar costos.
• El acceso remoto desde aplicaciones por fuera de la nube tienen un muy buen rendimiento, lo que puede ser ventajoso en ciertos escenarios en que se requiera una base centralizada para aplicaciones cliente que por algún motivo no se deseen subir a los servicios web de Azure. En este caso el firewall propio del SQL Azure protege la base obligando a declarar los accesos permitidos según rangos IP predefinidos.
• El crecimiento y actualización del servicio está asegurado por el proveedor, quien realizará las implementaciones (upgrade) a través del tiempo en forma completamente trasparente para las aplicaciones, dejando atrás la posibilidad de obsolescencia del entorno.

Adicionalmente durante las pruebas comprobé el comportamiento de transacciones según la clase SqlTransaction (de  la librería System.Data.SqlClient) sin problemas; y luego la de transacciones distribuidas (TransactionScope en System.Transactions) según la versión definitiva en línea actualmente del sitio de pruebas. En este último caso,  la documentación declara que no está soportada para el caso que se involucren varias bases de datos y otros recursos (como colas); pero para una sola base de datos en Azure SQL se comporta perfectamente según lo esperado, por lo que el servicio de MS DTC se encuentra habilitado por defecto en Azure. Las operaciones las realicé invocando exclusivamente procedimientos almacenados. En este servicio de SQL el tema del rendimiento comparado entre procedimientos almacenados y ejecución de sql dinámico puede que realmente no sean muy diferentes, pero por temas de seguridad y previendo que a la larga pueda ser un factor de incidencia en retardos recomiendo basarse en procedimientos almacenados. Un factor por el que me inclino por esta práctica es que se elimina la posibilidad de ataques por inyección sql por completo, siendo una preocupación menos a controlar en un proyecto de equipo. Por último, una observación respecto al rendimiento de las consultas y los timeout: como siempre influye la pericia del programador y el evitar caer en la tentación del abuso de los recursos del servicio por suponerlos “infinitos”.

Respecto a los objetos de acceso, por los tipos de conexión admitidos resulta imposible acceder con el EDM (Entity Data Model), aunque por su inconveniencia frente a escenarios desconectados que destaqué oportunamente no lo eché de menos. Por este motivo, aunque las clases LinQ contra SQL sí trabajan perfectamente, utilicé el objeto preferido para trabajo desconectado o en n-capas: el DataSet. Por supuesto que hay que hacer algún rodeo mínimo con el Visual Studio 2008 para facilitar su aplicación, pero su programación es transparente y simplifica notablemente el trabajo de crear entidades y acceso a base de datos.

En definitiva, este es el recurso ideal para complementar las aplicaciones de servicios web de Azure, y le da la profundidad necesaria para enfrentar aplicaciones de estilo comerciales o en los que la integridad de los datos y operaciones sean un punto sensible a la hora de realizar un proyecto. Como siempre los invito a recorrer el sitio de pruebas y comprobar en directo sus funcionalidades.

(tiny)