¿Cómo puedo garantizar que las inserciones en SQL Server 2008 R2 se almacenen primero en la memoria caché?


17

Imagine un flujo de datos que está "en ráfaga", es decir, podría tener 10,000 eventos muy rápidamente, seguidos de nada por un minuto.

ingrese la descripción de la imagen aquí

Su consejo experto: ¿Cómo puedo escribir el código de inserción de C # para SQL Server, de modo que haya una garantía de que SQL almacena en caché todo inmediatamente en su propia RAM, sin bloquear mi aplicación durante más de lo necesario para alimentar los datos en dicha RAM? Para lograr esto, ¿conoce algún patrón para configurar el servidor SQL o patrones para configurar las tablas SQL individuales en las que estoy escribiendo?

Por supuesto, podría hacer mi propia versión, que implica construir mi propia cola en RAM, pero no quiero reinventar el Paleolithic Stone Axe, por así decirlo.


1
¿Estás hablando del código de cliente C #? Entonces, ¿está interesado en el código SQL que garantiza que las escrituras estén en caché?
Richard

66
Me inclino a hacer cola, incluso si el RDBMS lo admite porque (a) no es difícil, (b) está totalmente bajo su control y (c) no depende del proveedor.

Estoy interesado en el código de cliente C # que contiene el código SQL para garantizar que las escrituras estén en caché. Sin embargo, I "m seguro de que podría trabajar con la recta T-SQL y escribir mi propia C # envoltorio.

Respuestas:


11

¿Has intentado simplemente escribir y ver qué pasa? ¿Tienes un cuello de botella conocido?

Si necesita evitar que su aplicación se bloquee, una forma sería poner en cola las escrituras para diferir la llamada a la base de datos. Sin embargo, esperaría que la cola se borre en un segundo o 2: entonces, ¿necesita una cola si esto está bien?

¿O puede pasar a una mesa de ensayo y luego enjuagarse más tarde? Usamos esta técnica para lidiar con escrituras sostenidas de millones de filas nuevas por minuto (en realidad usamos una base de datos provisional con recuperación simple): pero no la implementamos hasta que tuvimos la experiencia de escribir solo filas.

Nota: Cada escritura en SQL Server va a ir a hacer el disco como parte del protocolo de escritura anticipada registro (WAL). Esto se aplica a la entrada t-log para esa escritura.

La página de datos con la fila irá al disco en algún momento (según el tiempo, el uso, la presión de la memoria, etc.) pero, en general, sus datos estarán en la memoria de todos modos. Esto se llama "Checkpointing" y no expulsa los datos de la memoria, solo elimina los cambios (editado el 24 de noviembre de 2011)

Editar:

Para consideraciones generales, basadas en el último párrafo anterior, cambie su LDF para esta base de datos a un conjunto dedicado de discos para un mayor rendimiento. Lo mismo ocurre con una base de datos provisional (una para MDF / LDF). Es bastante común tener una docena o 3 volúmenes diferentes (a través de una SAN normalmente) para su servidor de base de datos


1
Enrollar a una mesa de ensayo es probablemente la mejor manera de hacerlo. También recibí la confirmación de uno de mis amigos, que trabaja en un entorno con mil millones de tablas de filas, dijo que usa tablas temporales para un análisis más rápido.

7

A menos que me falte algo, esto violaría el requisito de durabilidad de ACID ( http://en.wikipedia.org/wiki/ACID ). Es decir, si su aplicación "escribe" los datos en la RAM y luego el servidor falla, sus datos se perderán.

Entonces, lo que busca es un sistema que no sea de base de datos que sirva como una cola para el almacenamiento eventual en una base de datos o un sistema de base de datos que sea lo suficientemente rápido para lo que está haciendo. Sugeriría probar el último primero y ver si es suficiente; No te prestes problemas.


+1 Debería haber mencionado esto. Se requiere WAL para ACID
gbn

2

Utilicé una vez un conjunto de datos para esto. Estaba insertando filas en el conjunto de datos a medida que llegaban, y había otro hilo que estaba volcando las filas cada 2 segundos más o menos a la base de datos. También puede usar el documento xml para hacer el cachin, y luego pasar el xml a la base de datos en una sola llamada, esto puede ser aún mejor.

Saludos

Piotr

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.