Comments 6
хорошее решение. Я в свое время работал с базой, где ключами были guid и тоже много параллельных встравок. Это вело к тому, что практически вся таблица хотела быть в памяти, которой постоянно не хватало, происходил checkpoint и дисковые очереди улетали в небеса. И тогда мы наоборот хотели, чтобы новые данные писались в новую страницу. Пробовали NEWSEQUENTIALID, вроде легче стало, но любой аналитический запрос возвращал проблему. Решили увеличением памяти до неприличных размеров и ssd дисками. Дорого, но очень эффективно.
Помню на заре 1С все надсмехались над ключами в виде guid.
Можно еще редис/очереди + пакетная вставка. Типа ридер, который сгребает данные и пакетами вставляет, если данных нет, то заканчивает. Как появятся, то запуск вставки. Все же бд может и сменится.
Не хочу холивара, но простите я как прочитал этот пост сразу вспомнил почему мы перелезли на постгрес)
Не хватает контекста, явно данные вставляются не круглосуточно, а если так, то можно делать это последовательно. Второе, что не понятно, это нужен ли этой таблице кластерный индекс и какой.
Как ускорить высокопараллельные вставки строк в SQL Server за считанные часы: опыт Mindbox