Explicación de la arquitectura de SQL Server: canalizaciones con nombre, optimizador, administrador de búfer

Tabla de contenido:

Anonim

MS SQL Server es una arquitectura cliente-servidor. El proceso de MS SQL Server comienza cuando la aplicación cliente envía una solicitud. SQL Server acepta, procesa y responde a la solicitud con datos procesados. Analicemos en detalle toda la arquitectura que se muestra a continuación:

Como muestra el siguiente diagrama, hay tres componentes principales en la arquitectura de SQL Server:

  1. Capa de protocolo
  2. Motor relacional
  3. Motor de almacenamiento
Diagrama de arquitectura de SQL Server

Analicemos en detalle los tres módulos principales anteriores. En este tutorial, aprenderá.

  • Capa de protocolo - SNI
    • Memoria compartida
    • TCP / IP
    • Tubos con nombre
    • ¿Qué es el TDS?
  • Motor relacional
    • Analizador CMD
    • Optimizador
    • Ejecutor de consultas
  • Motor de almacenamiento
    • Tipos de archivo
    • Método de acceso
    • Administrador de búfer
    • Caché de plan
    • Análisis de datos: caché de búfer y almacenamiento de datos
    • Gerente de transacciones

Capa de protocolo - SNI

MS SQL SERVER PROTOCOL LAYER admite 3 tipos de arquitectura cliente-servidor. Comenzaremos con " Tres tipos de arquitectura cliente-servidor" que admite MS SQL Server.

Memoria compartida

Reconsideremos un escenario de conversación a primera hora de la mañana.

MOM y TOM - Aquí Tom y su mamá, estaban en el mismo lugar lógico, es decir, en su casa. Tom pudo pedir café y mamá pudo servirlo caliente.

SERVIDOR MS SQL - Aquí el servidor MS SQL proporciona PROTOCOLO DE MEMORIA COMPARTIDA . Aquí el CLIENTE y el servidor MS SQL se ejecutan en la misma máquina. Ambos pueden comunicarse a través del protocolo de memoria compartida.

Analogía: Permite mapear entidades en los dos escenarios anteriores. Podemos asignar fácilmente a Tom a cliente, mamá a servidor SQL, casa a máquina y comunicación verbal a protocolo de memoria compartida.

Desde el escritorio de configuración e instalación:

Para la conexión a la base de datos local: en SQL Management Studio, la opción "Nombre del servidor" podría ser

"."

"localhost"

"127.0.0.1"

"Máquina \ Instancia"

TCP / IP

Ahora considere que por la noche, Tom está de humor de fiesta. Quiere un café que se pida en una cafetería conocida. La cafetería se encuentra a 10 km de su casa.

Aquí Tom y Starbuck se encuentran en ubicaciones físicas diferentes. Tom en casa y Starbucks en el concurrido mercado. Se comunican a través de la red celular. De manera similar, MS SQL SERVER proporciona la capacidad de interactuar a través del protocolo TCP / IP, donde CLIENTE y MS SQL Server son remotos entre sí y están instalados en una máquina separada.

Analogía: Permite mapear entidades en los dos escenarios anteriores. Podemos asignar fácilmente a Tom al cliente, Starbuck al servidor SQL, el lugar de inicio / mercado a la ubicación remota y, finalmente, la red celular al protocolo TCP / IP.

Notas del escritorio de Configuración / instalación:

  • En SQL Management Studio: para la conexión a través de TCP \ IP, la opción "Nombre del servidor" debe ser "Máquina \ Instancia del servidor".
  • El servidor SQL usa el puerto 1433 en TCP / IP.

Tubos con nombre

Ahora finalmente por la noche, Tom quería tomar un té verde claro que su vecina, Sierra, preparaba muy bien.

Aquí, Tom y su vecino , Sierra, están en la misma ubicación física, siendo vecinos el uno del otro. Se comunican a través de la red Intra. Del mismo modo, MS SQL SERVER proporciona la capacidad de interactuar a través del protocolo Named Pipe . Aquí el CLIENTE y el SERVIDOR MS SQL están conectados a través de LAN .

Analogía: Permite mapear entidades en los dos escenarios anteriores. Podemos mapear fácilmente a Tom a Cliente, Sierra a servidor SQL, Vecino a LAN y finalmente Intra red a Protocolo de tubería con nombre.

Notas del escritorio de Configuración / instalación:

  • Para conexión a través de tubería con nombre. Esta opción está deshabilitada de forma predeterminada y debe habilitarla el Administrador de configuración de SQL.

¿Qué es el TDS?

Ahora que sabemos que hay tres tipos de arquitectura cliente-servidor, echemos un vistazo a TDS:

  • TDS son las siglas de Tabular Data Stream.
  • Los 3 protocolos utilizan paquetes TDS. TDS está encapsulado en paquetes de red. Esto permite la transferencia de datos desde la máquina cliente a la máquina servidor.
  • TDS fue desarrollado por primera vez por Sybase y ahora es propiedad de Microsoft

Motor relacional

El motor relacional también se conoce como procesador de consultas. Tiene los componentes de SQL Server que determinan qué debe hacer exactamente una consulta y cómo se puede hacer mejor. Es responsable de la ejecución de las consultas de los usuarios solicitando datos del motor de almacenamiento y procesando los resultados que se devuelven.

Como se muestra en el diagrama arquitectónico, hay 3 componentes principales del motor relacional. Estudiemos los componentes en detalle:

Analizador CMD

Los datos, una vez recibidos de la capa de protocolo, se pasan al motor relacional. "CMD Parser" es el primer componente del motor relacional que recibe los datos de la consulta. El trabajo principal de CMD Parser es verificar la consulta en busca de errores sintácticos y semánticos. Finalmente, genera un árbol de consultas . Discutamos en detalle.

Verificación sintáctica:

  • Como cualquier otro lenguaje de programación, MS SQL también tiene el conjunto predefinido de palabras clave. Además, SQL Server tiene su propia gramática que el servidor SQL entiende.
  • SELECT, INSERT, UPDATE y muchos otros pertenecen a las listas de palabras clave predefinidas de MS SQL.
  • CMD Parser realiza una verificación sintáctica. Si la entrada de los usuarios no sigue la sintaxis del idioma o las reglas gramaticales, devuelve un error.

Ejemplo: digamos que un ruso fue a un restaurante japonés. Pide comida rápida en ruso. Desafortunadamente, el camarero solo entiende japonés. ¿Cuál sería el resultado más obvio?

La respuesta es: el camarero no puede seguir procesando el pedido.

No debe haber ninguna desviación en la gramática o el lenguaje que acepta el servidor SQL. Si los hay, el servidor SQL no puede procesarlo y, por lo tanto, devolverá un mensaje de error.

Aprenderemos más sobre las consultas de MS SQL en los próximos tutoriales. Sin embargo, considere a continuación la sintaxis de consulta más básica como 

SELECT * from ;

Ahora, para tener una idea de lo que hace la sintaxis, digamos si el usuario ejecuta la consulta básica como se muestra a continuación:

SELECR * from

Tenga en cuenta que en lugar de "SELECT", el usuario escribió "SELECR".

Resultado: el analizador de CMD analizará esta declaración y arrojará el mensaje de error. Como "SELECR" no sigue el nombre y la gramática de la palabra clave predefinida. Aquí CMD Parser esperaba "SELECT".

Verificación semántica:

  • Esto lo realiza Normalizer .
  • En su forma más simple, verifica si el nombre de la columna, el nombre de la tabla que se consulta existen en el esquema. Y si existe, vincúlelo a Query. Esto también se conoce como enlace .
  • La complejidad aumenta cuando las consultas de los usuarios contienen VIEW. Normalizer realiza el reemplazo con la definición de vista almacenada internamente y mucho más.

Entendamos esto con la ayuda del siguiente ejemplo:

SELECT * from USER_ID

Resultado: el analizador de CMD analizará esta declaración para la verificación semántica. El analizador arrojará un mensaje de error ya que Normalizer no encontrará la tabla solicitada (USER_ID) ya que no existe.

Crear árbol de consultas:

  • Este paso genera un árbol de ejecución diferente en el que se puede ejecutar la consulta.
  • Tenga en cuenta que todos los árboles diferentes tienen el mismo resultado deseado.

Optimizador

El trabajo del optimizador es crear un plan de ejecución para la consulta del usuario. Este es el plan que determinará cómo se ejecutará la consulta del usuario.

Tenga en cuenta que no todas las consultas están optimizadas. La optimización se realiza para comandos DML (lenguaje de modificación de datos) como SELECT, INSERT, DELETE y UPDATE. Estas consultas se marcan primero y luego se envían al optimizador. Los comandos DDL como CREATE y ALTER no están optimizados, sino que se compilan en un formulario interno. El costo de la consulta se calcula en función de factores como el uso de la CPU, el uso de la memoria y las necesidades de entrada / salida.

La función del optimizador es encontrar el plan de ejecución más económico, no el mejor y rentable.

Antes de entrar en detalles más técnicos del Optimizador, considere el siguiente ejemplo de la vida real:

Ejemplo:

Digamos que desea abrir una cuenta bancaria en línea. Ya conoce un banco que tarda un máximo de 2 días en abrir una cuenta. Pero también tiene una lista de otros 20 bancos, que pueden tardar menos de 2 días o no. Puede empezar a colaborar con estos bancos para determinar qué bancos tardan menos de 2 días. Ahora, es posible que no encuentre un banco que demore menos de 2 días, y se perderá tiempo adicional debido a la actividad de búsqueda en sí. Hubiera sido mejor abrir una cuenta en el primer banco.

Conclusión: es más importante seleccionar sabiamente. Para ser precisos, elija qué opción es mejor, no la más barata.

Del mismo modo, MS SQL Optimizer funciona con algoritmos exhaustivos / heurísticos incorporados. El objetivo es minimizar el tiempo de ejecución de las consultas. Todos los algoritmos del Optimizador son propiedad de Microsoft y son un secreto. Aunque , a continuación se muestran los pasos de alto nivel realizados por MS SQL Optimizer. Las búsquedas de optimización siguen tres fases, como se muestra en el siguiente diagrama:

Fase 0: Búsqueda de un plan trivial:

  • Esto también se conoce como etapa de optimización previa .
  • En algunos casos, solo podría haber un plan práctico y viable, conocido como plan trivial. No es necesario crear un plan optimizado. La razón es que buscar más resultaría en encontrar el mismo plan de ejecución en tiempo de ejecución. Eso también con el costo adicional de buscar un plan optimizado que no era necesario en absoluto.
  • Si no se encuentra un plan Trivial, comienza la 1ª Fase.

Fase 1: búsqueda de planes de procesamiento de transacciones

  • Esto incluye la búsqueda de Plan simple y complejo .
  • Búsqueda de plan simple: los datos anteriores de la columna y el índice involucrados en la consulta se utilizarán para el análisis estadístico. Esto generalmente consiste, pero no se limita a, un índice por tabla.
  • Aún así, si no se encuentra el plan simple, se busca un plan más complejo. Se trata de un índice múltiple por tabla.

Fase 2: Procesamiento y optimización en paralelo.

  • Si ninguna de las estrategias anteriores funciona, Optimizer busca posibilidades de procesamiento paralelo. Esto depende de las capacidades de procesamiento y la configuración de la Máquina.
  • Si eso aún no es posible, entonces comienza la fase de optimización final. Ahora, el objetivo final de la optimización es encontrar todas las demás opciones posibles para ejecutar la consulta de la mejor manera. Los algoritmos de la fase de optimización final son propiedad de Microsoft.

Ejecutor de consultas

El ejecutante de consultas llama al método de acceso. Proporciona un plan de ejecución para la lógica de obtención de datos necesaria para la ejecución. Una vez que se reciben los datos de Storage Engine, el resultado se publica en la capa de Protocolo. Finalmente, los datos se envían al usuario final.

Motor de almacenamiento

El trabajo del motor de almacenamiento es almacenar datos en un sistema de almacenamiento como Disk o SAN y recuperar los datos cuando sea necesario. Antes de profundizar en el motor de almacenamiento, veamos cómo se almacenan los datos en la base de datos y el tipo de archivos disponibles.

Archivo de datos y extensión:

Archivo de datos, almacena físicamente datos en forma de páginas de datos, y cada página de datos tiene un tamaño de 8 KB, formando la unidad de almacenamiento más pequeña en SQL Server. Estas páginas de datos están agrupadas lógicamente para formar extensiones. A ningún objeto se le asigna una página en SQL Server.

El mantenimiento del objeto se realiza mediante extensiones. La página tiene una sección llamada Encabezado de página con un tamaño de 96 bytes, que contiene la información de metadatos sobre la página, como el tipo de página, el número de página, el tamaño del espacio utilizado, el tamaño del espacio libre y el puntero a la página siguiente y a la página anterior. etc.

Tipos de archivo

  1. Archivo principal
  • Cada base de datos contiene un archivo primario.
  • Esto almacena todos los datos importantes relacionados con tablas, vistas, disparadores, etc.
  • La extensión es. mdf por lo general, pero puede ser de cualquier extensión.
  1. Archivo secundario
  • La base de datos puede contener o no varios archivos secundarios.
  • Esto es opcional y contiene datos específicos del usuario.
  • La extensión es. ndf normalmente, pero puede tener cualquier extensión.
  1. Archivo de registro
  • También conocido como registros de escritura anticipada.
  • La extensión es. ldf
  • Se utiliza para la gestión de transacciones.
  • Esto se usa para recuperarse de cualquier instancia no deseada. Realice la importante tarea de Rollback a transacciones no comprometidas.

Storage Engine tiene 3 componentes; echemos un vistazo a ellos en detalle.

Método de acceso

Actúa como una interfaz entre el ejecutor de consultas y Buffer Manager / Transaction Logs.

El método de acceso en sí no realiza ninguna ejecución.

La primera acción es determinar si la consulta es:

  1. Seleccionar declaración (DDL)
  2. Declaración no seleccionada (DDL y DML)

Según el resultado, el método de acceso sigue los siguientes pasos:

  1. Si la consulta es DDL , instrucción SELECT, la consulta se pasa al Administrador de búfer para su posterior procesamiento.
  2. Y si consulta si DDL, declaración NON-SELECT , la consulta se pasa al Administrador de transacciones. Esto incluye principalmente la declaración UPDATE.

Administrador de búfer

El administrador de búfer administra las funciones principales de los módulos siguientes:

  • Caché de plan
  • Análisis de datos: caché de búfer y almacenamiento de datos
  • Página sucia

Aprenderemos Plan, Búfer y Caché de datos en esta sección. Cubriremos las páginas sucias en la sección Transacción.

Caché de plan

  • Plan de consulta existente: el administrador de búfer comprueba si el plan de ejecución está en la caché de plan almacenada. En caso afirmativo, se utiliza la caché del plan de consultas y su caché de datos asociada.
  • Plan de caché por primera vez: ¿De dónde proviene el caché del plan existente?

    Si el plan de ejecución de la consulta por primera vez se está ejecutando y es complejo, tiene sentido almacenarlo en la caché del plano. Esto garantizará una disponibilidad más rápida cuando la próxima vez que el servidor SQL reciba la misma consulta. Por lo tanto, no es nada más que la consulta misma qué ejecución del Plan se almacena si se ejecuta por primera vez.

Análisis de datos: caché de búfer y almacenamiento de datos

El administrador de búfer proporciona acceso a los datos necesarios. A continuación, son posibles dos enfoques dependiendo de si existen datos en la caché de datos o no:

Caché de búfer - Análisis suave:

El Administrador de búfer busca datos en el búfer en la caché de datos. Si está presente, el Ejecutor de consultas utiliza estos datos. Esto mejora el rendimiento a medida que se reduce el número de operaciones de E / S cuando se obtienen datos de la caché en comparación con la obtención de datos del almacenamiento de datos.

Almacenamiento de datos - Análisis duro:

Si los datos no están presentes en Buffer Manager, los datos requeridos se buscan en el almacenamiento de datos. También almacena datos en la caché de datos para uso futuro.

Página sucia

Se almacena como una lógica de procesamiento de Transaction Manager. Lo aprenderemos en detalle en la sección Transaction Manager.

Gerente de transacciones

El Administrador de transacciones se invoca cuando el método de acceso determina que la consulta es una instrucción no seleccionada.

Administrador de registros

  • Log Manager realiza un seguimiento de todas las actualizaciones realizadas en el sistema a través de registros en los registros de transacciones.
  • Los registros tienen un número de secuencia de registros con el ID de transacción y el registro de modificación de datos .
  • Se utiliza para realizar un seguimiento de la transacción comprometida y la reversión de la transacción .

Administrador de bloqueo

  • Durante la transacción, los datos asociados en el almacenamiento de datos se encuentran en estado de bloqueo. Este proceso lo maneja Lock Manager.
  • Este proceso garantiza la coherencia y el aislamiento de los datos . También conocidas como propiedades ACID.

Proceso de ejecución

  • Log Manager inicia el registro y Lock Manager bloquea los datos asociados.
  • La copia de los datos se mantiene en la caché del búfer.
  • La copia de los datos que se supone deben actualizarse se mantiene en el búfer de registro y todos los eventos actualizan los datos en el búfer de datos.
  • Las páginas que almacenan los datos también se conocen como páginas sucias .
  • Registro de punto de control y escritura anticipada: este proceso se ejecuta y marca toda la página desde las páginas sucias hasta el disco, pero la página permanece en la caché. La frecuencia es de aproximadamente 1 ejecución por minuto, pero la página se envía primero a la página Datos del archivo de registro desde el registro de búfer. Esto se conoce como registro de escritura anticipada.
  • Escritor perezoso: la página sucia puede permanecer en la memoria. Cuando el servidor SQL observa una carga enorme y se necesita memoria intermedia para una nueva transacción, libera las páginas sucias de la caché. Funciona en LRU : el algoritmo menos utilizado recientemente para limpiar la página del grupo de búferes al disco.

Resumen:

  • Existen tres tipos de arquitectura cliente-servidor: 1) Memoria compartida 2) TCP / IP 3) Canalizaciones con nombre
  • TDS, desarrollado por Sybase y ahora propiedad de Microsoft, es un paquete que está encapsulado en paquetes de red para la transferencia de datos desde la máquina cliente a la máquina servidor.
  • El motor relacional contiene tres componentes principales:

    CMD Parser: Este es responsable del error sintáctico y semántico y finalmente genera un árbol de consultas.

    Optimizador: la función del optimizador es encontrar el plan de ejecución más económico, no el mejor y rentable.

    Ejecutor de consultas: el ejecutador de consultas llama al método de acceso y proporciona un plan de ejecución para la lógica de obtención de datos necesaria para la ejecución.

  • Existen tres tipos de archivos Archivo principal, archivo secundario y archivos de registro.
  • Motor de almacenamiento: tiene los siguientes componentes importantes

    Método de acceso: este componente determina si la consulta es una instrucción de selección o de no selección. Invoca Buffer y Transfer Manager en consecuencia.

    Administrador de búfer: el administrador de búfer gestiona las funciones principales para la caché del plan, el análisis de datos y la página sucia.

    Administrador de transacciones: gestiona transacciones no seleccionadas con la ayuda de administradores de registro y bloqueo. Además, facilita la implementación importante del registro Write Ahead y los escritores perezosos.