B-tree vs LSM-tree: почему выбор стораджа для Rust-проекта — не религиозный вопрос, а инженерный расчёт?

Коллеги, давно хотел поднять эту тему в контексте pet-проектов на Rust. Сейчас пилю свой storage engine под ключ-значение, и в очередной раз упираюсь в вечный холивар: B-tree или LSM-tree для дисковых нагрузок? Да, все знают про RocksDB и sled, но меня интересует именно low-level реализация под конкретные паттерны доступа. Если честно, надоело видеть, как новички blindly копируют выбор из документации, не понимая, что для read-heavy сценариев с редкими вставками B-tree даст предсказуемую латентность без write amplification, а LSM-tree с его compaction — это ад для SSD при высоком проценте overwrite. У меня в финтехе был кейс, когда переход с LSM на B-tree на слое аудита снизил P99 latency в 3 раза — просто потому, что данные писались раз в час, а читались постоянно. Давайте обсудим реальные метрики: размер блока, cache locality, merge policy. Кто что использует под свои задачи? Без споров про «модно/немодно» — только цифры и профили. И да, если кто-то скажет «бинарники на Go», я начну кидаться тапками. Это всё-таки Rust-секция.