La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Arquitectura de Proyectos de IT © 2005 Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón Coco Nicolás Passerini.

Presentaciones similares


Presentación del tema: "Arquitectura de Proyectos de IT © 2005 Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón Coco Nicolás Passerini."— Transcripción de la presentación:

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

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

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

4 4 Arquitectura de Proyectos de IT 4 Estrategias de Persistencia Archivos Bases de datos – Relacional – Objetos – Otras Prevalencia Ortogonal

5 5 Arquitectura de Proyectos de IT 5 Archivos XML Ancho fijo Csv DBF + IDX Archivos Indexados - VSAM Serialización Snapshot – Smalltalk – Self

6 6 Arquitectura de Proyectos de IT 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)

7 7 Arquitectura de Proyectos de IT 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.

8 8 Arquitectura de Proyectos de IT 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

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

10 10 Arquitectura de Proyectos de IT 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

11 11 Arquitectura de Proyectos de IT 11 Bases de Objetos

12 12 Arquitectura de Proyectos de IT 12 Bases de Objetos

13 13 Arquitectura de Proyectos de IT 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

14 14 Arquitectura de Proyectos de IT 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

15 15 Arquitectura de Proyectos de IT 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.

16 16 Arquitectura de Proyectos de IT 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

17 17 Arquitectura de Proyectos de IT 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 18 Arquitectura de Proyectos de IT 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 19 Arquitectura de Proyectos de IT 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 20 Arquitectura de Proyectos de IT 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 21 Arquitectura de Proyectos de IT 21 Estrategias de Uso SQL Plano / Embebido / HQL / OQL Frameworks de persistencia – ORM – No relacionales Transparentes – Bases de Objetos – Prevalencia – Persistencia Ortogonal

22 22 Arquitectura de Proyectos de IT 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

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

24 24 Arquitectura de Proyectos de IT 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").

25 25 Arquitectura de Proyectos de IT 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.

26 26 Arquitectura de Proyectos de IT 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.

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

28 28 Arquitectura de Proyectos de IT 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

29 29 Arquitectura de Proyectos de IT 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.

30 30 Arquitectura de Proyectos de IT 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

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

32 32 Arquitectura de Proyectos de IT 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

33 33 Arquitectura de Proyectos de IT 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.

34 34 Arquitectura de Proyectos de IT 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.


Descargar ppt "Arquitectura de Proyectos de IT © 2005 Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón Coco Nicolás Passerini."

Presentaciones similares


Anuncios Google