Your SlideShare is downloading. ×
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Consideraciones de diseño
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Consideraciones de diseño

845

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
845
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CHECK L1STSOBRE MODELO DE DATOS FUNCIONAL, DISEÑO E IMPLEMENTACiÓN A continuación, se lista una serie de elementos a considerar durante el diseño de una base de daros, agrupados en función del objetivo perseguido. Es importante recordar que se trata de recomendaciones que, bajo determinadas Cjrcu.nsrancias,no es posi- ble verificar (por ejemplo, cuando debemos trabajar sobre un diseño existente) y donde no podemos rediseñar la base sin hacer una reingenietía de la aplicación. No obstante, sí podemos revisar el diseño existente buscando mejorar las consultas, los índices, los tipos de daros, etcétera. EscalamientoEs la característica de una base de daros que consiste en crecer y ofrecer más servi-cios. Si el diseño es oscuro, complejo o difícil de mantener, las posibilidades de es-calar una aplicación decrecen. La siguiente tabla muestra las principales considera-ciones que se deben tener en cuenta a la hora de escalar una aplicación. CHECK DETAllE v Optimizar la aplicación antes de escalarla. v Revisar la necesidad de crear tablas históricas de datos para reportes. Tabla 3. Elementos a tener en cuenta que influyen en las posibilidades de escalamiento de una aplicación.Seguramente, la optimización de una aplicación requerirá de la asistencia del ad-rninisrrador de la base de datos y de la red. Esto se fundamenta en que, para op-timizar la base de datos, primero debemos tener una idea de cuáles son los ele-memos que producen dichos problemas. Entre esos elementos podemos enume-rar: procedimientos almacenados con sentencias mal formadas, que produzcanscans de tablas completas; estadísticas desactualizadas; índices pobres, de poca co-bertura, basados en campos poco selectivos o sobre campos de texto; tablas con
  • 2. clave primaria basada en campos compuesros; bloqueos morrales por alra concu-rrencia, bloqueo mal adminisrrado, ercérera.Es recomendable también que, a la hora de pensar en escalar una aplicación, revi-semos el uso de rabias de regisrros hisróricos que puedan moverse a otra base de da-ros (dedicada, por ejemplo, a reporres y regimos hisróricos).Esquema de la base de datosEl esquema de la base de daros refiere al diseño de tablas, campos, vistas, particio-nes, etc., que en su conjunto definen una base de daros. SQL Server permite con-sultar el esquema de una base de daros por medio de las vistas de INFORMATION_SCHEMA, según veremos en el capítulo dedicado a vistas.Si el esquema está bien definido (es decir, de acuerdo con las recomendaciones dela tabla que se encuentra a continuación) la base de daros será escalable y rendrá un óptimo desempeño. . CHECK DETALLE v Asignar los recursos apropiados (almacenamiento) al diseño. v Separar transacciones analíticas (BI) de transaccionales. v Normalizar primero. Denormalizar para mejorar desempeño. v Definir claramente claves primarías, foráneas y relaciones. v Definir todas las constraints UNIQUE y CHECK. v Seleccionar los tipos de datos más apropiados. v Usar vistas indexadas de normalización. v Partlcinnar tablas vertical y horizontalmente. Tabla 4. Elementos que definen un buen esquema de base de datos. Asignar los recursos apropiados al diseño implica estudiar cómo hemos de distribuir los recursos físicosde la base de daros entre los medios de almacenamienro. En ciertas dis- posiciones de hardware, como implemenraciones RAID (RedundalltArray of Indepen- dent orlnexpensive Disk) de discos, sería posible distribuir los archivos de daros y el lag de transacciones, separar los datos de las tablas y sus Índices. Incluso, se podrían parti- cionar tablas vertical y horizonra1menre en discos separados, con el fin de obtener me- joras generales de rendimiento, almacenamiento y desempeño de las consulras. Nos adentraremos más en este rema en el capítulo que hemos dedicado a las rabIas. Al separar las transacciones analíticas de las transaccionales, resolveremos también las cuestiones mencionadas, pero, desde el PWlto de vista funcional, ya que las transaccio- nes analíticas consumen muchos recursos de agrupanlienro y swnarización que po-
  • 3. drían ser optimizadas si, por ejemplo, almacenamos esas tablas en otro disco del RAID. En el capítulo dedicado a la creación de bases de datos veremos todo esto en detalle. Por otra parte, cuando hablamos de normalizar primero y denormalizar para mejo- rar desempeño nos referimos a los concepros ya tratados en el Capítulo 2, cuando hablamos de las formas normales. Allí dijimos que, en algunos casos, para mejorar el desempeño de algunas consultas, es posible incluir en el diseño campos calcula- dos que, si bien vulneran el concepto de normalización, permiten ganar desempe- ño y velocidad de procesamiento. No es lo mismo ejecutar una consulta que sume los importes de rodos los írems de cada factura que crear un campo derivado Total_ Factura, en la tabla Facturas, que guarde la sumarización de aquéllos. A la vez, al definir claramente claves primarias, foráneas y relaciones utilizando las es- tructuras que nos provee SQL Server, evitamos la implementación por código de la verificación de la integridad referencial al tiempo que creamos índices consistentes so- bre los cuáles se ha de realizar la mayor parte de las consultas que utilicen esa tabla. Aquí será de suma utilidad definir rodas las constrainrs UNIQUE y CHECK para la ve- rificación de integridad de dominio, utilizando, en ambos casos, herramientas y ob- jetos nativos y oprimizados de SQL Server. SQL Server aventaja otros productos por su facilidad de insralación y uso, que se evidencia en la rendencia a considerar la habilidad de creación y desarrollo sobre ba- ses de datos como una competencia adicional de los programadores. Esra concep- ción alienta la formación de profesionales mucho mejor formados pero, en ocasio- nes, cuando los equipos de trabajo no comparten esrándares de programación, las aplicaciones tienden a perder cohesión debido a que cada integrante del equipo aplica lo que sabe de la mejor forma posible. El resultado suele derivar en aplicacio- nes de baja capacidad para compartir datos, especialización y dependencia respecto del profesional que desarrolló tal aplicación y pobre desempeño. Uno de los problemas más usuales que se presenta es el desperdicio de recursos por deficiente tipificación de los daros. En este sentido, seleccionar los tipos de daros~ DISEÑO CONCEPTUAL.~. ~ El diseño conceptual parte de las especificaciones . . ~ de requisitos dé usuario. y su resullado es el es.qu~ma conceptual de la basede,datos; iodep;ndiente deLSGBD,utilizado. Un modelo conc€p- tual e~ lenguaje un que se utiliza p-~ra describir esquemas concepfual~,s{su objetivo es desc~jbir . el contenidO de jnformación"de la"bas~de datos, y no, sus estfJcturas"de a[mác~namiento, .
  • 4. más apropiados para cada campo y/o variable definida en la base de daros redunda-rá en un mejor desempeño de la aplicación en genera!.Lamenrablemente, para elegir los tipos de daros más apropiados es necesario disponerde un modelo de daros previamente definido, a parrir del análisis funcional del sisremaque se ha de desarrollar (tarea para la que suele falrar tiempo, entre otras cosas, porqueno se le asigna en la planificación del proyecto el valor preponderante que tiene).ConsultasUna vez diseñado el modelo de daros, son las consultas, generalmenre bajo la for-ma de procedimientos almacenados, las que definirán el desempeño de la aplica-ción, tanto en términos de tiempos de respuesta frente a! usuario como en desem-peño genera! y buena utilización de los recursos del servidor.Es muy importante escribir el código bien formado y revisar la lista de elementosde la tabla siguienre para obtener consultas de buen desempeño. 0., . " CJlf,CK DErALlE" W !,j" V •••• Definir de antemano la escalabilidad y los requerimientos de desempeño de las consultas . •••• Escribir consultas bien formadas . •••• Devolver s610 las filas y columnas requeridas . •••• Evitar operadores costosos en términos de rendimiento como HOT lIKE . •••• Evitar funciones implícitas o explícitas en cláusulas WHERE . •••• Utilizar H1NT5 de bloqueo y nivel de aislamiento para minimizar los bloqueos . •••• Usar procedimientos almacenados o consultas parametrizadas . •••• Minimizar el uso de cursores. •••• Evitar actualizaciones complejas en triggers. •••• Usar apropiadamente tablas temporarias y variables de tipo tabla . •••• Limitar el uso de HINTS en consultas e índices . •••• calificar apropiadamente los objetos. Tabla 5. Consideraciones sobre consultas. Establecer de antemano la escalabilidad y los requerimientos de desempeño de las consultas, así como la cantidad de usuarios (para entender las necesidades de con- currencia), la posibilidad de realizar consultas distribuidas, la necesidad de reali- zar cálculos intermedios o la necesidad de agregar datos definirá la estrategia de desarrollo de una consulta. Esa estrategia deberá contemplar la escritura de código claro y bien formado, que respete la estructura del lenguaje, y evitando, siempre que sea posible, el uso de sen- tencias de pobre desempeño. En este sentido, deberá evitarse la devolución de co- lumnas no requeridas que saturan las redes con información redundante y atestan sin necesidades las estructuras de daros de las aplicaciones.
  • 5. Por otra parte, los cursores deberán reservarse para procesamientos Fila A Fila, donde se estime más conveniente que los procese el servidor, en lugar de la apli- cación, y se tendrá especial cuidado en el uso de los HINTS en consultas e índi- ces que quitan a SQL Server la responsabilidad de elegir el mejor camino de eje- cución para una consulra. A la vez, por eficiencia en el uso de recursos, se preferirán las variables de tipo tabla por encima de las tablas temporarias y se calificarán adecuadamente los objetos ba- jo la forma owner.Nombre_Objeto para reducir los tiempos de búsqueda. índices Este puntO es fundamental en todo buen diseño, de manera que lo veremos con más detalle en el capítulo dedicado a tablas. Las recomendaciones del siguiente cuadro nos permitirán asegurar el óptimo desempeño de la aplicación. , . ;.., . • % CHECK DETAllE P «4<· 11 Crear los índices basándose en el uso. 11 Mantener las claves de los índices clustered 0 más pequeñas posibles. 11 Evaluar el rango de datos cubierto por el índice. 11 Crear índices en todos los FORElNG KEY. 11 Crear índices altamente selectivos. 11 Crear índices de cobertura para las consultas más usadas o de alto impacto. 11 Preferir índices estrechos a índices grandes de basta cobertura. 11 Crear indices compuestos sobre los campos más restrictivos. 11 Considerar la creación de índices sobre campos usados en cláusulas WHERE. ORDER BY. GROUP BY y DI5TINCT. 11 Remover índices no utilizados. 11 Utilizar el optimizador de índices. Tabla 6. Consideraciones sobre índices. Crear los índices basándose en el uso implica poseer un conocimiento bastante cer- tero sobre el objetivo de persistencia de datos que busca nuestra aplicación. Creare-----.DI DISEÑO LÓGICO El diseño lóqico parte del esquema conceptual y da como resultado un esquema lógico. que es una descripción de la estructura de la base de datos en términos de las estructuras de datos-que puede procesar un tipo de SGBD. Un modelo lógico es un len~uaie usado para especificar esque- mas lógicos. que depende del tipo de SGBD que se vaya a utitizar. no. del producto concreto.
  • 6. mos índices, -preferentemente sobre los campos definidos como candidatos-, en función de las consultas que desarrollaremos (o de las ya existentes que requieren mejoras). Los índices clustered (físicos), almacenados en páginas de índices, debe- rán estar basados en c<~mpos cuyo tipo de daros sea lo más pequeño posible. A mismo tiempo, es necesario verificar el rango de cobertura y de selectividad de un índice (un índice sobre un campo EstadoCivilserá de gran cobertura, petO de baja selectividad). Esta recomendación también es válida para los índices compuestos (basados en varios campos). Para decidir los campos candidatos a ser indexados, conviene analizar las cláusulas WHERE, RDER O BY,GROUP BYY DI8TINCT las consultas y luego analizar los tipos de de daros involucrados. Transacciones El ambiente transaccional que demos a nuestras consultas garantizará que la ejecu- ción de las sentencias de IN8ERT,UPDATE DELETE ellas ejecutadas se hagan ro- y en das o ninguna. El desempeño de nuestras transacciones puede ser mejorado si se observan las si- guientes recomendaciones. CHECK DETAllE ti Evitar transacciones de larga duración. ti Evitar transacciones Que requieran intervención del usuario para realizar COMMIT. ti Utilizar los dalos más pesados al final de la transacción. ti Intentar acceder a los recursos siempre en el mismo orden. ti Utilizar cuidadosamente los HINTS de nivel de aislamiento para reducir bloqueos. ti Asegurar la existencia de sentencias COMMIT y ROlLBACK. ti Determinar los patrones de datos más utilizados en transacciones y organizar las tablas e índices sobre arreglos de discos RAID. ti Buscar la mayor normalización posible de la base de datos para evitar redundancia. ti Mantener los registros históricos o de agregación en bases de datos separadas. Tabla 7. Consideraciones sobre transacciones.--.m DISEÑO FíSICO El diseño físico parte del esquema lógico y resulta en un esquema físico (descripción de la imple- mentación de una base de datos en memoria secundaria}: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos ..Par eso, el diseño fislco depende del SGBO concreto, y el esquema físico se expresa mediante su lenguaje de definición de datos. ~ $,
  • 7. De estas recomendaciones, consideramos como más importante aquella que sugiereevitar transacciones que requieran intervención del usuario para realizar COMMIT.El conocido ejemplo del usuario que deja pendienre una acrualización de saldos por-que salió a almorzar ya resulta una trivialidad para el profesional de sistemas. Pero aunasí, y dado que la práctica persisre, insistimos en este punto para resaltar que no sólose trata de una transacción en estado desconocido que espera una acción, sino queinvolucra la adquisición de bloqueos sobre los recursos involucrados en ella, que de-mora o directamente impide el acceso del resto de los usuarios al recurso bloqueado.No menos importante es resaltar el cuidado que deberá tenerse al utilizar los HINTSde nivel de aislamienro para reducir bloqueos. Aquí, para ejecutar la nuestra, Corre-mos el riesgo de utilizar datos que están siendo modificados por otras transacciones.Procedimientos almacenadosRespecto de los procedimientos almacenados, es importante la recomendación dela Tabla 8, debido a que, si la variable NOCOUNT está en OFF, corremos peligro de nopoder evaluar los resultados intermedios (cantidad de filas afectadas). CHECK "DETAllE 0.R ,, W~"W.:c"; e;; "2%¡.,Ji V Utilizar set NOCOUNT ON en procedimientos almacenados. V Verificar la necesidad de recompilación. Tabla 8. Consideraciones sobre procedimientos almacenados.Las recomendaciones sobre el código de los procedimientos almacenados se corres-ponden con el de las consultas.Planes de ejecuciónEn algún momento del análisis del desempeño de una consulra, rendremos la ne-cesidad de evaluar su plan de ejecución. Al respecto, mencionamos las principa-les recomendaciones. CHECK DETAllE ~ ",!I,"" . ¡" 0; V Evaluar los planes de ejecución. V Evitar seans de tablas e índices. V Evaluar el uso de joins HASH. V Evaluar bookmarks. V Evaluar ordenamientos y filtros. V Evaluar filas y ejecuciones actuales versus estimadas. Tabla 9. Consideraciones sobre los planes de ejecución.
  • 8. Un sean de rabla o índice señala que SQL Server está revisando dicha tabla o página de índices fila a fila o estructura a estructura en el árbol de índices. Se producen cuan- do la consulta no está utilizando (por falta de definición, por ejemplo) los índices ade- cuados. Al respecro, cuando nos adentremos en el capírulo referido a tablas, evaluare- mos en detalle las situaciones en las que se puede mejorar el plan de ejecución. Recompilación En la medida que una base de daros cambia debido a la creación de índices o por la modificación sobre los daros almacenados en columnas indexadas, también cambian los planes de ejecución compilados para acceder a esos datos. Por ello es necesario re- compilar dichos planes para optimizarlos. En SQL Server 2005, esta recompilación es auromática siempre que se corre por primera vez un procedimiento almacenado luego de reiniciar el servidor o si cambia una tabla utilizada por éste. Pero si se crea un índice nuevo sobre una tabla a partir del cual la ejecución de un procedimiento puede verse beneficiada, la recompilación no es auromática. La. siguieme tabla muestra recomendaciones respecro de la recompilación. -ce . , litÉ jjJ CHECK ·DETAllE . " v Utilizar procedimientos almacenados o consultas parametrizables. v Utilizar sp executesql para consultas dinámicas. v Evitar sentencias de definición de datos (DDl) o de manipulación de datos (DMl), aun en la tempdb, para manipular elementos ya definidos. v Evitar el uso de cursores en tablas temporarias. Tabla 1.0. Recomendaciones sobre recompilación. La. recomendación de utilizar procedimientos almacenados o consultas parametriza- bies se refiere a la necesidad de evitar el envío de consultas T-SQL desde la aplicación. Veremos con mayor detalle este punro en el capítulo dedicado a procedimientos al- macenados, pero, justamente, una de las ventajas de utilizar consultas parametrizadas y procedimientos almacenados por encima de sentencias T-SQL variables es la posi- bilidad de compilarlos, guardar el plan de ejecución en el servidor y reutilizarlo para---.nI EL PLAN DE EJECUCiÓN
  • 9. cada ejecución, evitando que el servidor deba verificar la referencia a objetos y buscar el mejor plan de ejecución pOt cada consulta que se envía desde la aplicación. SQLXML SQL Server ptovee soporte extensivo pata el procesamiento de datos XML. Valores en este forrnaro pueden ser almacenados en el nuevo tipo de datos XML, tipificado bajo diferentes esquemas XML. Este cipo de datos soporta indexado y puede ser manipulado por XQuery y XML DML. Ya en su versión 2000, SQL Server proveía poderosas capacidades de manipulación de XML con SQLXML, y permitía la transformación de datos relacionales en da- tos XML. También era posible "mapear " los resultados relacionales a XML median- te la sentencia FOR XML de T-SQL o generar vistas de XML mediante OPENXML. A continuación, se incluyen las consideraciones que debieran tenerse en cuenta respectO del uso de XML en SQL Server 2005 desde dos puntOS de vista: el mo- delado de datos y su uso. CHECK DETAllE • • ·"c. / . ", . . V " (semiestrueturado La estructura de datos es flex.ible o sin estructura). V Se desconoce la estructura de datos o ésta puede variar mucho en el futuro. V Los datos poseen una estructura jerárqulca y recursiva. V Importa el orden como ceractenstiea propia de los datos. V Planea actualizar los datos basándose en su estructura. V Planea utilizar las funciones administrativas del servidor para administrar la información XMl. V Planea compartir, consultar y modificar los datos XMl en forma transaccional segura. V Desea obtener Interoperabilidad entre aplicaciones relacionales y basadas en XML V Desea garantizar documentos bien formados mediante esquemas. V Desea acceso a datos XML desde sus aplicaciones utilizando SOAP,AOO .NET y OLEOS. Tabla 11. Evaluación de circunstancias para uso de tipos XM.-.m EL REGISTRO DE TRANSACCIONES Esta aplicación trabaja escribiendo en regjstro, anticipadamente. todos los cambios que se realicen ante una operación de COMMIT o cuando se ejecuta un CHECKPOINTmediante el proceso lazywrit- ter. Las políticas de backup suelen incluir el lag de transacciones, permitiendo recuperar la infor- rnación ante una caída del sistema, sin ·husmear" en el registro.
  • 10. TunningEn la siguiente rabia, se resumen las acciones recomendadas para evaluar el desem-peño de una consulta. CHEC~ DETAllE" ., . + . W ?ii;¡o¡ . •••• Utilizar el Profiler para identificar consultas de larga duración . •••• Registrar las consultas pequeñas realizadas varias veces . •••• Utilizar sp-who2 Y sp lock para analizar bloqueos . •••• Evaluar waittype y walttime en master..sysprocesses . •••• Utilizar DBCe OPENTRAN para localizar transacciones de larga duración. Tabla 12. Recomendaciones para el refinamiento del diseño.TestingLa fase de Análisis y Desarrollo es tan importante como la fase de Testing. En la si-guiente tabla se muestra un resumen de las acciones recomendadas para testear elaspecto técnico de una base de daros. CHECK DETALLE , < ,t:,, ., .. .: J%, :,¡;,¡ •••• Revisar que no se llene el Transaction lag . •••• Presupuestar el tamaño de la base de datos . •••• Utilizar herramientas para popular datos . •••• Utilizar datos de producción . •••• Utilizar escenarios de usuario común, con un apropiado balance entre lecturas y escrituras . •••• Usar herramientas de test de stress sobre el sistema. Tabla 13. Recomendaciones para el testlng de diseño y desempeño.Si el Transacrion log (registro de transacciones) se llena, ya sea porque alcanzó eltamaño prefijado como si no queda espacio disponible en el Server (suele sucederen ambientes de desarrollo), no se dispondrá de resguardo transaccional sobre labase de daros y fallará la aplicación. Es importante disponer de un plan de mante--uD FUNCIONES DEL DBA Unbuen administrador de bases de datos [OBA) será de gran ayuda para.prptegerlos datos medían- te·backups, asegurarse de qljién y cómo accede a la base dedatos; administrar los recursos ñsicos d~tpervid9r, ejecutar tareas>de~~anteJ¡irniento y asigna2íónde espacio e.ndisco en la base, mGni"to~ • . " .,y . . re%;el uso y desempeño del sistema y n~garse a a~ignár~e:.pef~os sa a los desarrolladores.~· ,j~, k.·z 5k-- ~ .~
  • 11. nirniento que se ocupe, entre otras cosas, de! backup (resguardo) de la base y queesté configurado para truncar e! registro.También es importante tratar de utilizar un conjunto real de datos con el fin deverificar el diseño (excepto que se trate de una aplicación nueva). Esto nos brin-dará la posibilidad de proyectar el uso real de ésta.MonitoreoLas tareas de monitoreo refieren a las acciones que normalmente efectúa el D BA pa-ra verificar el desempeño de! servidor y de las bases de datos en él administradas. LaTabla 13 muestra las recomendaciones de monitoreo para realizar un buen análisis. ClIECK DEfAIll._ @ ~ . . " 01 Mantener las estaoísucas al día. 01 Utilizar el Profiler para afinar consultas de larga duración. 01 Utilizar el Profiler para consultar scans de tablas e índices. 01 Utilizar el Performance Monitor para analizar el uso de recursos del sistema. 01 Analizar las comunicaciones de red en consultas de larga duración. 01 Analizar recursos de memoria del server en consultas de larga duración. 01 Analizar la falta de estadísticas actualizadas en consultas de larga duración. 01 Analizar la falta de índices en consultas de larga duración. Tabla 14. Recomendaciones para el monitoreo del servidor. Deployment (distribución) La Tabla 14 resume las recomendaciones para la distribución y/o pase a Producción de la base de datos. Entre ellas, se destaca la de asignar DBA, que normalmente es quien conoce el servidor de destino, asign los recursos necesarios y ocuparse de los aspectos relacionados con el resguardo y la recuperación de la información. CHECK DETALLE 01 Utilizar la configuración del seoer para las aplicaciones. 01 Ubicar ellog y la tempdb en distintos dispositivos del de datos. 01 Proveer dispositivos separados para [as tablas y los índices mas accesacos. 01 Usar la configuración RAID correcta. 01 Usar múltiples controladores de discos. 01 Dimensionar las bases de datos y sus logs de manera de evitar las opciones de autocrecimiento automático. 01 Maximizar la memoria disponible del servidor. 01 Administrar la fragmentación de índlces, 01 Asignar un DBA. Tabla 15. Recomendaciones para la distribución de bases de datos.

×