LINUX.ORG.RU

История изменений

Исправление maxcom, (текущая версия) :

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

Обычные реляционные СУБД таким не занимаются. Такая логика есть, например, в индексах Lucene (Elasticsearch, OpenSearch и др). Наверняка что-то подобное можно обнаружить в аналитических базах вроде Clickhouse, но не уверен.

Я знаю 2 способа быстрого поиска элемента в контейнере

СУБД не используют красно-черные деревья, потому что они плохо работают на дисковых хранилищах. Вместо этого используются другие сбалансированные деревья. В PostgreSQL есть возможность выбрать тип индекса – «btree» по-умолчанию и «hash» по выбору. Но я еще ниразу не видел, чтобы hash кто-то использовал.

Исходная версия maxcom, :

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

Обычные реляционные СУБД таким не занимаются. Такая логика есть, например, в индексах Lucene (Elasticsearch, OpenSearch и др). Наверняка что-то подобное можно обнаружить в аналитических базах вроде Clickhouse, но не уверен.

Я знаю 2 способа быстрого поиска элемента в контейнере

СУБД не используют красно-черные деревья, потому что они плохо работают на дисковых хранилищах. Вместо этого используются другие сбалансированные деревья. В PostgreSQL есть возможность выбрать тип индекса – «btree» по-умолчанию и «hash» по выбору. Но я еще ниразу не видел чтобы hash кто-то использовал.