B-tree based collection types for Go

tidwall의 btype 패키지는 Go 언어용 B-트리 기반 컬렉션 타입(Map, Set, Array, Table, Stack, Queue, Deque, Prique)을 제공합니다. 각 컬렉션은 O(log n) 복잡도의 고성능 연산을 지원하며, 복사 시 O(1) 복사-온-라이트 방식을 사용해 빠른 스냅샷을 제공합니다. 특히 Map과 Set은 키 정렬과 다양한 탐색 및 수정 메서드를 갖추고 있어 Go 개발자가 효율적인 데이터 구조를 쉽게 구현할 수 있습니다. 이 패키지는 Go, Rust, C++의 기존 B-트리 구현보다 성능이 뛰어나며, 100% 테스트 커버리지를 자랑합니다.

https://github.com/tidwall/btype

#go #btree #datastructures #collections #performance

HTAP внутри OLTP: как мы строили векторизованный движок с самого начала

Как встроить векторизованный движок в OLTP-ядро с нуля — без отдельного аналитического слоя. Разбираем PhysicalType, SelectionVector, RowToColumnBridge, SIMD на листовых страницах B-Tree и Hash Join. Бенчмарк на 2,25 млн строк: от 1.22× на простых агрегатах до 2.67× на GROUP BY.

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

#htap #векторизация #база_данных #simd #btree #Hash_Join #rust #oltp

BRIN, GIN, B‑Tree: полный гайд по индексам PostgreSQL для highload

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

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

#архитектура #PostgreSQL #индексы #оптимизация_запросов #highload #базы_данных #BTree #BRIN

[Перевод] Нетипичные оптимизации в PostgreSQL, или Креативное ускорение запросов

Когда речь заходит об оптимизации базы данных, разработчики обычно перечисляют привычный набор приёмов: слегка переписать запрос, накинуть индекс на колонку, денормализовать, сделать analyze, vacuum, cluster, и так по кругу. Классические техники, конечно, работают, но иногда креативный подход даёт гораздо больше. В этой статье Haki Benita показывает нетипичные техники оптимизации в PostgreSQL.

https://habr.com/ru/companies/postgrespro/articles/1001194/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1001194

#optimisation #hash #btree #indexes #postgresql #администрирование #администрирование_бд #индекс

[Перевод] Нетипичные оптимизации в PostgreSQL, или Креативное ускорение запросов

Когда речь заходит об оптимизации базы данных, разработчики обычно перечисляют привычный набор приёмов: слегка переписать запрос, накинуть индекс на колонку, денормализовать, сделать analyze, vacuum, cluster, и так по кругу. Классические техники, конечно, работают, но иногда креативный подход даёт гораздо больше. В этой статье Haki Benita показывает нетипичные техники оптимизации в PostgreSQL.

https://habr.com/ru/companies/postgrespro/articles/1001194/

#optimisation #hash #btree #indexes #postgresql #администрирование #администрирование_бд #индекс

Как не получилось сделать PostgreSQL лучше (и почему это нормально)

Недавно я получил статус Major Contributor в проекте PostgreSQL. Это довольно радостное для меня событие и интересное, поэтому коллеги попросили написать статью об этом. А чтобы я не сомневался — заботливо составили список достижений за меня. Получилось замечательно, но публиковать от своего имени статью вида «как я крут» я не хочу. Я совсем не против про это говорить, и из каждого утюга вещаю про разные технологии, сделанные моей командой или вот прям вообще мной. Но только в контексте «как использовать эти технологии», либо в узком кругу или личной беседе. Я решил написать другую статью: что у меня не получилось. Писал довольно спешно, поэтому, возможно, местами будет понятно только специалистам. Не расстраивайтесь, если что‑то неясно и пришлось гуглить. А вот если всё понятно — возможно, стоит меньше смотреть в монитор и чаще трогать траву. Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. И в большинстве случаев предлагаемых в PostgreSQL доработок — вред превышает пользу. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.

https://habr.com/ru/companies/yandex/articles/964778/?utm_source=habrahabr&utm_medium=rss&utm_campaign=964778

#postgresql #wal #btree #btree_индекс #синхронная_репликация #lz4 #pglz

Как не получилось сделать PostgreSQL лучше (и почему это нормально)

Недавно я получил статус Major Contributor в проекте PostgreSQL. Это довольно радостное для меня событие и интересное, поэтому коллеги попросили написать статью об этом. А чтобы я не сомневался — заботливо составили список достижений за меня. Получилось замечательно, но публиковать от своего имени статью вида «как я крут» я не хочу. Я совсем не против про это говорить, и из каждого утюга вещаю про разные технологии, сделанные моей командой или вот прям вообще мной. Но только в контексте «как использовать эти технологии», либо в узком кругу или личной беседе. Я решил написать другую статью: что у меня не получилось. Писал довольно спешно, поэтому, возможно, местами будет понятно только специалистам. Не расстраивайтесь, если что‑то неясно и пришлось гуглить. А вот если всё понятно — возможно, стоит меньше смотреть в монитор и чаще трогать траву. Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. И в большинстве случаев предлагаемых в PostgreSQL доработок — вред превышает пользу. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.

https://habr.com/ru/companies/yandex/articles/964778/

#postgresql #wal #btree #btree_индекс #синхронная_репликация #lz4 #pglz

Kent Beck의 4주 실험: AI 코딩이 ‘바이브’를 넘어서는 법

https://aisparkup.com/posts/6155

File system design philosophy

https://deyaa1251.github.io/deyaa1251/posts/b_tree/

#HackerNews #File #system #design #philosophy #fileSystemDesign #techPhilosophy #softwareEngineering #bTree #dataStorage