Как я могу гарантировать, что вставки в 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

Я был бы склонен вставлять себя в очередь ДАЖЕ, если СУБД поддерживает это, потому что (а) это не сложно, (б) это полностью под вашим контролем, и (в) это не зависит от поставщика.

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

11

Вы пытались просто написать и посмотреть, что происходит? У вас есть известное узкое место?

Если вам нужно предотвратить блокирование вашего приложения, то вы можете поставить записи в очередь, чтобы отложить вызов базы данных. Тем не менее, я ожидаю, что очередь очистится через секунду или 2: так вам нужна очередь, если это нормально?

Или вы можете намотать на промежуточный стол, а потом смыть? Мы используем эту технику, чтобы иметь дело с последовательной записью миллионов новых строк в минуту (мы фактически используем промежуточную БД с Простым восстановлением), но мы не реализовали ее, пока у нас не было опыта простой записи строк.

Примечание. Каждая запись в SQL Server будет выполняться на диске как часть протокола записи в журнал записи (WAL). Это относится к записи t-log для этой записи.

Страница данных со строкой в какой-то момент перейдет на диск (в зависимости от времени, использования, нехватки памяти и т. Д.), Но, как правило, ваши данные все равно будут в памяти. Это называется «контрольная точка» и не удаляет данные из памяти, а просто сбрасывает изменения (отредактировано 24 ноября 2011 г.)

Редактировать:

Из соображений повсеместности, основываясь на последнем параграфе выше, переместите LDF для этой базы данных на выделенный набор дисков для большей производительности. Так же промежуточная база данных (по одной для MDF / LDF). Для вашего сервера базы данных довольно часто иметь дюжину или 3 разных тома (обычно через SAN)

— ГБН
источник

1

Наводить на промежуточный стол, наверное, лучший путь. Я также получил подтверждение от одного из моих друзей, который работает в среде с миллиардами таблиц строк, он сказал, что использует временные таблицы для более быстрого анализа.

7

Если я что-то упустил, это нарушило бы требование Durability от ACID ( http://en.wikipedia.org/wiki/ACID ). То есть, если ваше приложение «записывает» данные в ОЗУ, а затем происходит сбой сервера, ваши данные теряются.

Итак, вы ищете либо систему без базы данных, которая служит в качестве очереди для возможного хранения в базе данных, либо систему базы данных, которая достаточно быстра для того, что вы делаете. Я бы предложил сначала попробовать последнее и посмотреть, достаточно ли этого; не занимай проблем.

— Бен Тул
источник

+1 Я должен был упомянуть об этом. WAL требуется для ACID

— gbn

2

Я использовал один раз набор данных для этого. Я вставлял строки в набор данных по мере их поступления, и был другой поток, который сбрасывал строки каждые 2 секунды или около того в базу данных. Вы также можете использовать XML-документ для выполнения кэширования, а затем передать XML-файл в базу данных за один вызов, это может быть даже лучше.

С уважением

Петр

— Петр Родак
источник