B-Tree против T-Tree - Для более низких нагрузок, что лучше?

Question

Наше приложение использует базу данных (в памяти), которая использовала T-Tree до недавнего времени. Теперь мы перешли на B-Tree и заметили, что для более высоких рабочих нагрузок (с миллионами записей в дБ) производительность значительно улучшается. Информация об учетной записи уже создана (вставка - 4M), а затем при обработке она обновляется.

Однако для другого варианта продукта, который работает очень мало, количество записей уменьшилось. Здесь информация об учетной записи была временно создана (вставлена), обработана (несколько обновлений), а затем очищена (удалена). В любом случае мы не стремимся обрабатывать более 100 профилей учетных записей в секунду. В этом случае мы наблюдали существенную разницу в производительности с T-Tree и B-Tree.

В последнем случае B-Tree работает хуже.

Я не смог найти много информации в Интернете для конкретных случаев, когда B-Tree мог работать не так хорошо, как T-Tree.

Answer 1

T-деревья работают лучше для наборов данных, находящихся в памяти, в то время как B-деревья работают лучше для наборов данных, находящихся на диске.

Это служит причиной того, что T-деревья работают лучше для небольших наборов данных, так как ониСкорее всего, они полностью войдут в память (и останутся там на некоторое время)

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

Найдено: T-Tree или B-Tree

В наше время [T-деревья] неизбежно страдают из-за своей плохой локализации, как в смысле ожидаемого количества передач блоков / страниц, так и в смысле локальности кэша.