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:
- 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)
- 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)
- 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.
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 –