#bдерево — Public Fediverse posts

[Перевод] Структуры данных на практике. Глава 10: B-деревья и деревья, эффективно использующие кэш

Загадка базы данных Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 12 тысяч тактов. При миллионе показаний датчика IoT-устройства с 64 КБ кэша реализация красно-чёрного дерева оказалась слишком медленной для запросов в реальном времени. «Давайте попробуем B-дерево», — предложил я. «Разве они нужны не только для баз данных на дисках?», — спросил лид, — «У нас всё находится в памяти. Чем нам будет полезно B-дерево?» Вопрос был вполне разумным. B-деревья были придуманы для доступа к диску; каждый узел в них — это блок диска. Однако паттерны промахов кэша выглядели подозрительно похожими на паттерны дискового ввода-вывода — всего в 100 раз, а не в 100000 раз быстрее. В итоге мы реализовали B-дерево. Результаты удивили всех...

https://habr.com/ru/articles/1013048/

#bдерево #красночерное_дерево #b+_tree

[Перевод] Почему VACUUM не спасает от раздувания индексов в PostgreSQL

VACUUM в PostgreSQL принято считать универсальным средством поддержания порядка: он очищает мёртвые кортежи, обновляет статистику и вроде бы держит базу «в форме». Но с индексами всё сложнее. В какой-то момент они начинают расти и деградировать так, что это уже влияет на планы запросов и поведение оптимизатора — при том, что формально всё обслуживается корректно. Разберёмся, где именно возникает это расхождение между ожиданиями и реальностью и что на самом деле происходит внутри B-дерева. Разобраться глубже

https://habr.com/ru/companies/otus/articles/1012266/

#postgres #PostgreSQL #VACUUM #раздувание_индексов #Bдерево #планировщик_запросов #оптимизация_запросов #REINDEX #производительность_базы_данных

[Перевод] Как фильтры Блума в 10 раз ускорили SQLite

Это интригующая история о том, как исследователи с помощью грамотного использования фильтров Блума смогли в 10 раз ускорить аналитические запросы в SQLite. Ниже я приведу свой краткий обзор работы « SQLite: Past, Present, and Future (2022) », и объясню некоторые внутренние особенности баз данных, включая механизм реализации соединений.

https://habr.com/ru/companies/ruvds/articles/885830/

#ruvds_перевод #sqlite #базы_данных #star_schema_benchmark #bдерево #duckdb

[Перевод] Насколько быстры B-деревья по сравнению с хэш-таблицами?

Во многих «скриптовых» языках для стандартных ассоциативных структур данных используется хэш-таблица (hashmap) (объекты Javascript, словари Python и так далее). Хэш-таблицы обладают множеством раздражающих свойств: Уязвимость к hash flooding . В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее. При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки. Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping. Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными. Упорядоченные структуры данных наподобие B-деревьев не имеют этих недостатков. Обычно они медленнее хэш-таблиц, но меня удивило, насколько разнятся ожидания людей относительно их скорости.

https://habr.com/ru/articles/849654/

#bдерево #хэштаблицы #btree #hashmap #поисковые_алгоритмы #бенчмарки

[Перевод] Насколько быстры B-деревья по сравнению с хэш-таблицами?

Во многих «скриптовых» языках для стандартных ассоциативных структур данных используется хэш-таблица (hashmap) (объекты Javascript, словари Python и так далее). Хэш-таблицы обладают множеством раздражающих свойств: Уязвимость к hash flooding . В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее. При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки. Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping. Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными. Упорядоченные структуры данных наподобие B-деревьев не имеют этих недостатков. Обычно они медленнее хэш-таблиц, но меня удивило, насколько разнятся ожидания людей относительно их скорости.

https://habr.com/ru/articles/849654/

#bдерево #хэштаблицы #btree #hashmap #поисковые_алгоритмы #бенчмарки

[Перевод] Насколько быстры B-деревья по сравнению с хэш-таблицами?

Во многих «скриптовых» языках для стандартных ассоциативных структур данных используется хэш-таблица (hashmap) (объекты Javascript, словари Python и так далее). Хэш-таблицы обладают множеством раздражающих свойств: Уязвимость к hash flooding . В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее. При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки. Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping. Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными. Упорядоченные структуры данных наподобие B-деревьев не имеют этих недостатков. Обычно они медленнее хэш-таблиц, но меня удивило, насколько разнятся ожидания людей относительно их скорости.

https://habr.com/ru/articles/849654/

#bдерево #хэштаблицы #btree #hashmap #поисковые_алгоритмы #бенчмарки

[Перевод] Насколько быстры B-деревья по сравнению с хэш-таблицами?

Во многих «скриптовых» языках для стандартных ассоциативных структур данных используется хэш-таблица (hashmap) (объекты Javascript, словари Python и так далее). Хэш-таблицы обладают множеством раздражающих свойств: Уязвимость к hash flooding . В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее. При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки. Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping. Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными. Упорядоченные структуры данных наподобие B-деревьев не имеют этих недостатков. Обычно они медленнее хэш-таблиц, но меня удивило, насколько разнятся ожидания людей относительно их скорости.

https://habr.com/ru/articles/849654/

#bдерево #хэштаблицы #btree #hashmap #поисковые_алгоритмы #бенчмарки

[Перевод] Почему B-деревья быстрые?

B-дерево — это структура, помогающая выполнять поиск в больших объёмах данных. Она была изобретена более сорока лет назад, однако по-прежнему используется в большинстве современных баз данных. Хотя существуют и более новые структуры индексов, например, LSM-деревья, B-дерево пока никто не победил в обработке большинства запросов баз данных. После прочтения этого поста вы будете знать, как B-дерево упорядочивает данные и выполняет поисковые запросы.

https://habr.com/ru/articles/783012/

#btree #bдерево #индексация #базы_данных #алгоритмы_на_графах #двоичное_дерево_поиска