Як я можу гарантувати, що вставки в SQL Server 2008 R2 спочатку зберігаються в оперативній пам'яті?

17

Уявіть потік даних, який "лопається", тобто він може мати 10 000 подій, які надходять дуже швидко, а за хвилиною нічого не йде.

введіть тут опис зображення

Ваша порада експерта: Як я можу записати код вставки C # для SQL Server, щоб була гарантія того, що SQL негайно кешує все у власній оперативній пам’яті, не блокуючи моє додаток більше, ніж потрібно для введення даних у згадану оперативну пам’ять? Щоб досягти цього, чи знаєте ви які-небудь схеми для налаштування самого SQL-сервера або шаблони для налаштування окремих таблиць SQL, до яких я пишу?

Звичайно, я міг би зробити свою власну версію, яка передбачає побудову власної черги в оперативній пам’яті - але я не хочу винаходити палеолітичний каменний сокир, так би мовити.

c# sql-server visual-studio-2010 sql-server-2008

— Контанго
джерело

1

Ви говорите про клієнтський код C #? Отже, вас цікавить код SQL, який забезпечує кешування записів?

— Річард

6

Я схильний до того, що черга вставляє себе ВСІМО, якщо RDBMS підтримує це, оскільки (а) це не важко, (б) це повністю під вашим контролем, і (в) це не залежить від постачальника.

Мене цікавить клієнтський код C #, який містить код SQL для забезпечення кешування записів. Однак я впевнений, що зможу працювати з прямим T-SQL і написати власну обгортку C #.

11

Ви спробували просто написати і подивитися, що станеться? У вас є відоме вузьке місце?

Якщо вам потрібно не допустити, щоб ваш додаток було заблоковано, тоді ви одним із способів було б встановити чергу на запис, щоб відкласти виклик бази даних. Однак я очікую, що черга очиститься через секунду або через 2: тож вам потрібна черга, якщо це нормально?

Або ви можете розмотати до постановочного столу, а потім промити пізніше? Ми використовуємо цю техніку для обробки постійних записів мільйонів нових рядків на хвилину (ми фактично використовуємо поетапну БД з простим відновленням): але ми не застосовували її, поки не мали досвіду просто писати рядки.

Примітка. Кожне записування на SQL Server буде виконувати диск як частина протоколу WAL (Write Ahead Logging). Це стосується запису t-log для цього запису.

Сторінка даних із рядком в якийсь момент перейде на диск (залежно від часу, використання, тиску пам’яті тощо), але, як правило, ваші дані все одно будуть в пам'яті. Це називається "Checkpointing" і не вилучає дані з пам'яті, а просто вимиває зміни (відредаговано 24 листопада 2011)

Редагувати:

З урахуванням останнього пункту вище, перемістіть свій LDF для цієї бази даних на спеціальний набір дисків для більшої продуктивності. Розмістіть базу даних для постановки (по одній для MDF / LDF). Для вашого сервера баз даних досить часто мати десяток або 3 різних томи (звичайно через SAN)

— гбн
джерело

1

Намотування до постановочного столу - це, мабуть, найкращий шлях. У мене також було підтвердження від одного з моїх друзів, який працює в середовищі з мільярдами таблиць рядків, він сказав, що він використовує тимчасові таблиці для швидшого аналізу.

7

Якщо я чогось не пропускаю, це порушило б вимогу міцності ACID ( http://en.wikipedia.org/wiki/ACID ). Тобто, якщо ваша програма "записує" дані в оперативну пам'ять, а потім сервер виходить з ладу, ваші дані втрачаються.

Отже, те, що ви шукаєте, це або система без баз даних, яка служить чергою для можливого зберігання в базі даних, або система бази даних, яка є достатньо швидкою для того, що ви робите. Я б запропонував спробувати останнє спочатку і подивіться, чи достатньо це; не позичайте клопоту.

— Бен Тул
джерело

+1 Я повинен був це згадати. WAL необхідний для кислоти

— gbn

2

Я використовував для цього один раз набір даних. Коли я надходив, я вставляв рядки до набору даних, і там була ще одна нитка, яка передає рядки кожні 2 секунди або близько того до бази даних. Ви також можете використовувати xml документ для кешування, а потім передайте xml до бази даних за один дзвінок, це може бути ще краще.

З повагою

Пьотр

— Петро Родак
джерело