У нас есть система, которая одновременно вставляет большой объем данных с нескольких станций, а также предоставляет интерфейс запроса данных. Схема выглядит примерно так (извините за плохое форматирование):
[SyncTable]
SyncID
StationID
MeasuringTime
[DataTypeTable]
TypeID
TypeName
[DataTable]
SyncID
TypeID
DataColumns...
Вставка данных выполняется в режиме «Синхронизация» и происходит следующим образом (мы только вставляем данные в систему, мы никогда не обновляем)
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 ...
И запросы идут так (для данной станции, времени измерения и типа данных)
SELECT SyncID FROM SyncTable WHERE StationID = @StationID
AND MeasuringTime = @MeasuringTime
SELECT DataColumns FROM DataTable WHERE SyncID = @SyncIDJustSelected
AND DataTypeID = @TypeID
Мой вопрос заключается в том, как мы можем объединить уровень транзакций на вставках и подсказки NOLOCK / READPAST на запросы так, чтобы:
- Мы максимизируем параллелизм в нашей системе, отдавая предпочтение вставкам (нам нужно хранить много данных, что превышает 2000+ записей в секунду)
- Запросы возвращают только данные из «зафиксированной» синхронизации (нам не нужен результирующий набор с наполовину вставленной синхронизацией или синхронизацией с некоторыми пропущенными записями из-за пропуска блокировки)
- Нам не важно, включены ли в запрос «самые новые» данные, нам важнее согласованность и оперативность, чем «живые» и актуальные данные
Это может быть очень противоречивыми целями и может потребовать высокого уровня изоляции транзакции, но меня интересуют все приемы и оптимизации для достижения высокой отзывчивости как на вставках, так и на выборках. Я с удовольствием уточню, если понадобится больше деталей, чтобы избавиться от дополнительных ухищрений и уловок.
ОБНОВЛЕНИЕ: просто добавив немного больше информации для будущих ответов. Мы запускаем SQL Server 2005 (вероятно, в течение шести месяцев в 2008 году) в сети SAN с объемом хранения 5+ ТБ. Я не уверен, какой тип RAID настроен для SAn и сколько именно дисков у нас есть.