Arquitectura de Persistencia

Transcripción

1 Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón Coco Nicolás Passerini 2005

2 Qué es persistencia? In computer science, persistence refers to the characteristic of data that outlives the execution of the program that created it. Por qué es necesario? Los datos en memoria se pierden La memoria es acotada 2

3 Problemas de persistencia Performance Acceso a disco Búsquedas Distribución Transformación de los datos 3

4 Estrategias de Persistencia Archivos Bases de datos Relacional Objetos Otras Prevalencia Ortogonal 4

5 Archivos XML Ancho fijo Csv DBF + IDX Archivos Indexados - VSAM Serialización Snapshot Smalltalk Self 5

6 Prevalencia Características Los datos se mantienen en memoria. Regularmente se hace un snapshot a disco Implementaciones Prevayler (Java) Bamboo (.Net) Madeleine (Ruby) Sprevayler (Smalltalk) Perlvayler (Perl) 6

7 Prevalencia Ventajas No hay transformación, los datos se guardan en el formato que los usa el programa. Alto grado de transparencia. La performance es muchísimo más alta. Desventajas La aplicación debe poder ser contenida en memoria. Interoperabilidad. Falta la maduración de un sistema híbrido. 7

8 Data Base Management Systems Independencia de la forma en que se guardan físicamente los datos Permite compartir la DB entre varios programas Comunicación, transacciones, lockeos, seguridad, etc. Mecanismos para recuperarse si algo falla Transacciones, logs, auditoría, herramientas de backup Permite establecer reglas de integridad Valores inválidos Incoherencias o inconsistencias Performance y escalabilidad Grandes volúmenes de datos o de transacciones Puedo ejecutar cosas dentro de la base 8

9 Tipos de DBMS En red Jerárquicas Relacionales Objetos Asociativas Multidimensionales 9

10 Bases de Datos Relacionales Bases teóricas Algebra relacional (Ted Codd ) Teoría de conjuntos (Georg Cantor 1874) Lógica de predicados Elementos Tablas, relaciones, constraints, domains, keys Operadores relacionales Normalización 10

11 Bases de Objetos 11

12 Bases de Objetos 12

13 Bases de Objetos Frameworks de persistencia DB4O Omnibase (desapareciendo) EJB Entity Beans Bases de Objetos Gemstone Objectivity GOODS (Generic Object Oriented Database System) Lenguajes de Consulta OQL LINK 13

14 Bases de Objetos Algunas clasificaciones Activas / Pasivas Transformación nativa / no nativa Embebidas Reticencia a su uso Interacción con otras aplicaciones No parece tan sencillo cocinar datos Miedo 14

15 Bases de Objetos Ventajas Más simple Más rápido (trabajan con punteros en lugar de relaciones, navegacional en lugar de declarativo ) Modificabilidad Desventajas Son más rápidas para las búsquedas conocidas previamente. Desarrollos sobre múltiples plataformas. Interoperabilidad. 15

16 Multidimensionales OLAP (cubos) Fact Table / Dimension Tables Vistas precalculadas, para las posibles agregaciones Grandes volúmenes de datos a gran velocidad Datos históricos 16

17 NO-SQL Surgen en parte para suplir limitaciones del modelo relacional Escalabilidad Distribuidas por diseño Volumen de datos Esquemas flexibles Pueden o no implementar ACID Tipos Columns Key/Value Document 17

18 NO-SQL. Columns Es parecido al modelo relacional, pero los datos son guardados ordenados por columna en lugar de por registro. Las búsquedas son mucho más rápidas Mas fácil calcular proyecciones relativas a una o pocas columnas. Es más difícil realizar escrituras o consultas complejas (muchas columnas) Ejemplos: BigTable (Google) Hypertable 18

19 NO-SQL. Key/Value La información se guarda organizado como un par clave/valor. Tiene una alta flexibilidad, no es necesario modificar estructuras para agregar atributos. No es necesario lidiar con tipos de datos Es complicado hacer búsquedas por más de un campo (AND y OR) Ejemplos: Cassandra (Facebook, Twitter, Digg) Tyrant 19

20 NO-SQL. Document Guardan cualquier documento arbitrario, independientemente de la estructura. Es mas fácil guardar estructuras que varían pese a referirse al mismo tipo de entidad. Suelen usar XML, YAML o JSON para retornar los datos a través de un protocolo REST. No es tan fácil hacer consultas complejas (proyecciones, por ejemplo) Ejemplos: MongoDB (sourceforge, github) CouchDB 20

21 Estrategias de Uso SQL Plano / Embebido / HQL / OQL Frameworks de persistencia ORM No relacionales Transparentes Bases de Objetos Prevalencia Persistencia Ortogonal 21

22 SQL Plano Muy difundido Inclusive desde la vista (por ejemplo JSP) Puede ser manual o generado Normalmente se introduce a través de strings 22

23 SQL Plano - Variantes Stored Procedures Vistas Triggers SQL Embebido Pro*C RPG Herramientas de Reporting Jasper Reports Externalización XML DAO 23

24 SQL Plano Ventajas Es facil generar diferentes vistas de los datos. El clasico "mostrame este y este dato en la pantallita". O "modificame solo este campito No necesitan generar abstracciones ni modelo. (esto no es una ventaja, pero si somos cortoplacistas, sale con fritas. Recordar RAD) Facilita la generación de Reportes (cuando son datos "cuadrados"). 24

25 SQL Plano Desventajas NO se generan abstracciones ni modelo!!! La lógica de negocio se entremezcla en los INSERT / UPDATES / DELETE La lógica se hace parte de la infraestructura. Triggers y su promiscuidad oculta -> tocan los datos, se meten en la lógica. Y encima es oculta, NO es explícita. 25

26 Mapeo Objetos-Relacional Permite concentrarse en el negocio Puede tener problemas de performance. Ejemplos Hibernate / NHibernate Castor JDO TopLink Dos niveles Mapeador de objetos Framework de persistencia. 26

27 Alternativa: Active Record Simplifica el uso de un ORM Convention over configuration Table per class Behavioral complete Ejemplos Ruby on Rails 27

28 Impedance Mismatch (I) Conversiones de tipos Imposibilidad de refactor, no hay entornos integrados. Inflexibilidad de las tablas, no polimorfismo. Herencia Identidad vs. Clave Primaria. Unicidad 28

29 Impedance Mismatch (II) Interfaces de datos vs. interfaces de comportamiento Relaciones bidireccionales, navegabilidad, consistencia, relaciones inversas. En realidad esto de a poco se va solucionando Ausencia del concepto de proyección Declarativo vs. Imperativo (4GL vs. 3GL) Manejo de conjuntos versus iteración. Conjuntos por comprensión. 29

30 Qué significa transparente? (I) Cómo y dónde persistir? Qué objetos persistir Persistence by Reachability Qué objetos traer del repositorio persistente Lazy Resolución múltiples Eliminación 30

31 Qué significa transparente? (II) Lenguaje de interacción con el repositorio persistente Lenguajes embebidos Mismo lenguaje de programación Transacciones 31

32 Qué significa transparente? (III) Pero entonces cómo funciona? Programática Declarativa Automática / Inteligente / Heurística Transparente para quién? Servicios Objetos de negocio Presentación 32

33 Combinando esquemas de persistencia Para qué pueden servir cada una de las formas de persistencia. Cómo combinarlas? Prototipado Para guardar información de configuración no hace falta una base de datos. Una persistencia bien objetosa podría ser útil para una configuración más feliz. Otra posibilidad es que la configuración sea código. La base está buena para datos que son muchos y cuadrados. Si son muchos y complicados entonces es un problema. 33

34 Otros problemas de persistencia Cachés Distribución del acceso a los datos Distribución de los datos Transaccionalidad Entre múltiples repositorios de datos. 34