2008-11-13 15 views
5

Tenemos un sistema que simultáneamente inserta una gran cantidad de datos de múltiples estaciones y al mismo tiempo expone una interfaz de consulta de datos. El esquema se ve algo como esto (lo de los pobres formato):Nivel de transacción, nolock/readpast y concurrencia

[SyncTable] 
    SyncID 
    StationID 
    MeasuringTime 


[DataTypeTable] 
    TypeID 
    TypeName 


[DataTable] 
    SyncID 
    TypeID 
    DataColumns... 

inserción de datos se realiza en una "sincronización" y es la siguiente (sólo insertar datos en el sistema, nunca Update)

INSERT INTO SyncTable(StationID, MeasuringTime) VALUES (X,Y); SELECT @@IDENTITY 

INSERT INTO DataTable(SyncID, TypeID, DataColumns) VALUES 
    (SyncIDJustInserted, InMemoryCachedTypeID, Data) 
    ... lots (500) similar inserts into DataTable ... 

y consultas dice así (para una determinada estación, measuringtime y tipo de datos)

SELECT SyncID FROM SyncTable WHERE StationID = @StationID 
           AND MeasuringTime = @MeasuringTime 
SELECT DataColumns FROM DataTable WHERE SyncID = @SyncIDJustSelected 
            AND DataTypeID = @TypeID 

Mi pregunta es ¿cómo podemos combinar el nivel de transacción en los insertos y NOLOCK/READP consejos de AST en las consultas de forma que:

  1. Maximizamos la concurrencia en nuestro sistema al tiempo que favorece los insertos (necesitamos para almacenar una gran cantidad de datos, algo tan alto como 2000 + graba un segundo)
  2. Consultas solamente devolver datos desde la sincronización "comprometida" (no queremos un conjunto de resultados con una mitad de sincronización insertada o una sincronización con algunas entradas omitidas debido a saltos de bloqueo)
  3. No nos importa si se incluyen los datos "más recientes" en la consulta, nos preocupamos más por la coherencia y la capacidad de respuesta que por los datos "activos" y actualizados

Esto puede ser un objetivo muy conflictivo y puede requerir un alto nivel de aislamiento de transacción, pero estoy interesado en todos los trucos y optimizaciones para lograr una alta capacidad de respuesta tanto en las inserciones como en las selecciones. Estaré encantado de elaborar si se necesitan más detalles para eliminar más ajustes y trucos.

ACTUALIZACIÓN: Solo agrego un poco más de información para respuestas futuras. Estamos ejecutando SQL Server 2005 (2008 dentro de seis meses probablemente) en una red SAN con 5 TB de almacenamiento inicialmente. No estoy seguro de qué tipo de RAID está configurado SAn y cuántos discos tenemos disponibles.

Respuesta

0
  1. ¿Qué tipo de sistema de disco va a utilizar? Si tiene una matriz RAID de rayas grandes, las escrituras deben tener un buen rendimiento. Si puede estimar las lecturas y escrituras requeridas por segundo, puede conectar esos números en una fórmula y ver si su subsistema de disco se mantendrá actualizado. Tal vez no tiene control sobre el hardware ...

  2. ¿No envolvería las inserciones en una transacción, lo que las haría no disponibles para las lecturas hasta que finalice la inserción?

  3. Esto debe seguir si su hardware está configurado correctamente y está prestando atención a su codificación SQL, que parece ser.

mirada en las herramientas y el estrés SQLIO.exe SQL:

SQLIOStress.exe SQLIOStress.exe simula varios patrones de comportamiento de SQL Server/O 2000 que para garantizar la seguridad de E/S rudimentaria.

La utilidad SQLIOStress se puede descargar desde el sitio web de Microsoft. Vea el siguiente artículo.

• Cómo utilizar la Utilidad de SQLIOStress para resaltar un subsistema de disco como SQL Server http://support.microsoft.com/default.aspx?scid=kb;en-us;231619

Importante La descarga contiene un libro blanco completo con detalles ampliados sobre la utilidad.

SQLIO.exe SQLIO.exe es una utilidad de E/S de SQL Server 2000 utilizada para establecer los resultados de las pruebas de referencia básicas.

La utilidad SQLIO se puede descargar desde el sitio web de Microsoft. Véase el siguiente: • Herramienta SQLIO Pruebas de rendimiento (Desarrollo de SQL) - cliente disponible http://download.microsoft.com/download/f/3/f/f3f92f8b-b24e-4c2e-9e86-d66df1f6f83b/SQLIO.msi

+0

Marcando esto como la respuesta ya que parte de la "solución" se relacionó con la configuración correcta de un sistema de disco en particular que mejoró enormemente el rendimiento –

1

Si está ejecutando SQL 2005 y por encima de mirada en la implementación de snapshot isolation. No podrá obtener resultados consistentes con nolock.

Resolver esto en SQL 2000 es mucho más difícil.

1

Este es un gran escenario para la función de Partición de SQL Server 2005/2008 Enterprise. Puede crear una partición para cada StationID, y los datos de cada StationID puede entrar en su propio grupo de archivos (si lo desea, puede no ser necesario dependiendo de su carga.)

Esto le compra algunas ventajas con la concurrencia:

  • Si particiona por stationid, los usuarios pueden ejecutar consultas de selección para los que no están cargando actualmente, y no se encontrarán con problemas de concurrencia
  • Si particiona por stationid, entonces múltiples estaciones pueden insertar datos simultáneamente sin problemas de concurrencia (siempre que estén en diferentes grupos de archivos)
  • Si realiza una partición por rango de sincronismo, puede colocar los datos anteriores en un almacenamiento más lento.
  • Si particiona por rango syncid, y si sus niveles son lo suficientemente pequeños (es decir, no una gama con miles de syncids), entonces usted puede hacer cargas al mismo tiempo que sus usuarios están consultar sin entrar en concurrencia emite

El escenario que está describiendo tiene mucho en común con las cargas nocturnas del almacén de datos. Microsoft hizo un proyecto de referencia técnica llamado Project Real que podría encontrar interesante. Publicaron como un estándar, y se puede leer a través de los documentos de diseño y el código de implementación con el fin de ver cómo se quitaron cargas muy rápido:

http://www.microsoft.com/technet/prodtechnol/sql/2005/projreal.mspx

particionamiento es aún mejor en SQL Server 2008, especialmente alrededor de concurrencia. Todavía no es una bala de plata: requiere un diseño y mantenimiento manual por parte de un DBA calificado. No es una función de "configúralo y olvídate", y requiere Enterprise Edition, que cuesta más que la Edición estándar. Aunque me encanta, lo he usado varias veces y me ha solucionado problemas específicos.

+0

Otra ventaja de la partición por stationid: Si crea los índices agrupados correctos (stationid, syncid) en synctable, (syncid) en datatable, y use identity para el syncid, nunca obtiene splits de página de la actividad de inserción, lo que le permite usar READPAST en las instrucciones select, que luego no interfieren en absoluto con la actividad de inserción (don No espere obtener sus bloqueos en S para los registros con X-locked y sin actualizaciones no se emite X-lock para ninguna fila en S-locked). Si las divisiones de página fueran posibles, READPAST a veces podría dar lugar a resultados inconsistentes, lo que la convierte en una opción peligrosa. – TToni

Cuestiones relacionadas