Таблица сортированных строк (SSTable) или дерево B + для индекса базы данных?

Использование двух баз данных для иллюстрации этого примера: CouchDB и Cassandra .

CouchDB

CouchDB использует дерево B + для индексов документов (используя умную модификацию для работы в среде только для добавления) - в частности, при изменении документов (вставка / обновление / удаление) они добавляются к работающему файлу базы данных, а также к полному пути Leaf -> Node из дерева B + всех узлов, на которые влияет обновленная ревизия, сразу после документа.

Эти частичные изменения индекса встроены рядом с изменениями, так что полный индекс представляет собой объединение самых последних изменений индекса, добавленных в конце файла вместе с дополнительными частями, находящимися дальше в файле данных, которые все еще актуальны. и еще не были изменены.

Поиск в B + дереве - O (logn).

Кассандра

Кассандра хранит ключи записей отсортированными, в памяти, в таблицах (давайте думать о них как о массивах для этого вопроса) и записывает их как отдельные (отсортированные) таблицы сортированных строк от время от времени.

Мы можем рассматривать совокупность всех этих таблиц как «индекс» (насколько я понимаю).

Cassandra требуется для сжатия / комбинирования этих таблиц сортированных строк время от времени, создавая более полное файловое представление индекса.

Поиск в отсортированном массиве - O (logn).

Вопрос

Предполагая аналогичный уровень сложности между поддержанием частичных блоков дерева B + в CouchDB и частичными индексами отсортированных строк в Cassandra, и учитывая, что оба обеспечивают время поиска O (logn), которое, по вашему мнению, могло бы улучшить представление индекса базы данных и почему?

Мне особенно любопытно, есть ли детали реализации одного по сравнению с другим, которые делают его особенно привлекательным, или если они оба являются размытыми, и вы просто выбираете любые данные структура, с которой вы предпочитаете работать / имеет больше смысла для разработчика.

Спасибо за мысли.