📘 Как PostgreSQL научился масштабироваться без боли
Менеджер буферов в PostgreSQL отвечает за кэширование 8KB-страниц диска в общей памяти фиксированного размера. Для поиска используется хеш-таблица (через BufferTag → buffer ID), а для удаления страниц — clock-sweep алгоритм.
Первые версии были предельно простыми — с глобальной блокировкой, что быстро приводило к узким местам под нагрузкой. За 30 лет система эволюционировала:
от единой глобальной блокировки
к блокировкам на каждый буфер и партицию
и, наконец, к атомарным операциям, обеспечивающим почти lock-free доступ к структурам памяти.
Это позволило резко снизить конфликтность и повысить масштабируемость в OLTP-нагрузках, сохранив устойчивость при работе с общей памятью.
Философия дизайна PostgreSQL — минимальное время удержания блокировок, абстракция аппаратных различий через атомики и постоянная оптимизация реальных узких мест по результатам профилирования.
Отличный блог-пост с хронологией ключевых вех и ссылками на важные коммиты за эти годы — по ссылке 👇
Подробности
Менеджер буферов в PostgreSQL отвечает за кэширование 8KB-страниц диска в общей памяти фиксированного размера. Для поиска используется хеш-таблица (через BufferTag → buffer ID), а для удаления страниц — clock-sweep алгоритм.
Первые версии были предельно простыми — с глобальной блокировкой, что быстро приводило к узким местам под нагрузкой. За 30 лет система эволюционировала:
от единой глобальной блокировки
к блокировкам на каждый буфер и партицию
и, наконец, к атомарным операциям, обеспечивающим почти lock-free доступ к структурам памяти.
Это позволило резко снизить конфликтность и повысить масштабируемость в OLTP-нагрузках, сохранив устойчивость при работе с общей памятью.
Философия дизайна PostgreSQL — минимальное время удержания блокировок, абстракция аппаратных различий через атомики и постоянная оптимизация реальных узких мест по результатам профилирования.
Отличный блог-пост с хронологией ключевых вех и ссылками на важные коммиты за эти годы — по ссылке 👇
Подробности
❤5❤🔥2
Какой SQL оператор отвечает за создание таблицы?
Anonymous Quiz
3%
ALTER
1%
INSERT
1%
DROP
92%
CREATE
3%
MAKE
0%
DELEGATE
🙉9😱3😁1💅1
Media is too big
VIEW IN TELEGRAM
🔥 Hugging Face снова выкатили полезные материалы.
Вышел бесплатный плейбук о том, как изнутри строят SOTA-модели.
Без общих слов - только реальные решения и нюансы, которые обычно скрыты внутри исследовательских команд.
Это полноценный мастеркласс на 214 страниц для тех, кто хочет понимать, как устроены современные LLM.
Что внутри:
• Логика построения модели: зачем → что → как
• Как разработчики берут модель и по частям включают/выключают компоненты (или меняют их)
• Архитектура: ключевые выборы и trade-offs
• Искусство подбора и очистки данных
• Как проходит обучение моделей
• Пост-тренинг и RLHF в 2025
• Инфраструктура больших моделей
По первым страницам - уровень деталей как в Ultra-scale playbook.
Ссылка: https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook#designing-the-model-architecture
Видео: https://www.youtube.com/watch?v=LGzO-Mn0DJQ
#AI #LLM #MachineLearning #HuggingFace
@sql_lib - библиотека МЛ и ИИ книг
Вышел бесплатный плейбук о том, как изнутри строят SOTA-модели.
Без общих слов - только реальные решения и нюансы, которые обычно скрыты внутри исследовательских команд.
Это полноценный мастеркласс на 214 страниц для тех, кто хочет понимать, как устроены современные LLM.
Что внутри:
• Логика построения модели: зачем → что → как
• Как разработчики берут модель и по частям включают/выключают компоненты (или меняют их)
• Архитектура: ключевые выборы и trade-offs
• Искусство подбора и очистки данных
• Как проходит обучение моделей
• Пост-тренинг и RLHF в 2025
• Инфраструктура больших моделей
По первым страницам - уровень деталей как в Ultra-scale playbook.
Ссылка: https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook#designing-the-model-architecture
Видео: https://www.youtube.com/watch?v=LGzO-Mn0DJQ
#AI #LLM #MachineLearning #HuggingFace
@sql_lib - библиотека МЛ и ИИ книг
❤3🔥1
🔄 Миграция на российскую СУБД без переписывания кода
25 ноября в 14:00 (МСК) — вебинар о переходе с MS SQL или Oracle на Digital Q.DataBase с минимальными издержками.
💡 На вебинаре узнаете:
1️⃣ Как Digital Q.DataBase объединила три диалекта — T-SQL, PL/SQL и PL/pgSQL.
2️⃣ Как мигрировать ПО с любой СУБД без переписывания кода.
3️⃣ Что входит в поставку (включая то, что другие вендоры лицензируют отдельно).
4️⃣ Как получить бесплатную версию Digital Q.DataBase.
🏆 Digital Q.DataBase:
— Сертификация ФСТЭК 4-го уровня
— 1 место в рейтинге CNews Market «Конвергентные СУБД»
👥 Для кого:
Разработчики, администраторы БД, CIO, CDTO, руководители проектов импортозамещения.
🎤 Спикер: Андрей Жуйков, руководитель направления
📅 25 ноября | 🕐 14:00 (МСК) | 💻 Онлайн, бесплатно
👉 Регистрация
#реклама
О рекламодателе
25 ноября в 14:00 (МСК) — вебинар о переходе с MS SQL или Oracle на Digital Q.DataBase с минимальными издержками.
💡 На вебинаре узнаете:
1️⃣ Как Digital Q.DataBase объединила три диалекта — T-SQL, PL/SQL и PL/pgSQL.
2️⃣ Как мигрировать ПО с любой СУБД без переписывания кода.
3️⃣ Что входит в поставку (включая то, что другие вендоры лицензируют отдельно).
4️⃣ Как получить бесплатную версию Digital Q.DataBase.
🏆 Digital Q.DataBase:
— Сертификация ФСТЭК 4-го уровня
— 1 место в рейтинге CNews Market «Конвергентные СУБД»
👥 Для кого:
Разработчики, администраторы БД, CIO, CDTO, руководители проектов импортозамещения.
🎤 Спикер: Андрей Жуйков, руководитель направления
📅 25 ноября | 🕐 14:00 (МСК) | 💻 Онлайн, бесплатно
👉 Регистрация
#реклама
О рекламодателе
❤2
This media is not supported in your browser
VIEW IN TELEGRAM
🚨 SQL Никогда НЕ ДЕЛАЙ ТАК #sql
НИКОГДА НЕ ЛОМАЙ ИНДЕКСЫ ФУНКЦИЯМИ: не оборачивай индексируемые поля в функции внутри WHERE.
Как только ты пишешь LOWER(), CAST(), COALESCE() или любые вычисления по колонке — индекс перестаёт работать, и запрос падает в полное сканирование таблицы.
Это одна из самых тихих причин, почему запросы внезапно превращаются в тормоза.
Вместо этого приводи значения заранее или используй функциональные индексы.
https://www.youtube.com/shorts/AyiAslOeJFA
НИКОГДА НЕ ЛОМАЙ ИНДЕКСЫ ФУНКЦИЯМИ: не оборачивай индексируемые поля в функции внутри WHERE.
Как только ты пишешь LOWER(), CAST(), COALESCE() или любые вычисления по колонке — индекс перестаёт работать, и запрос падает в полное сканирование таблицы.
Это одна из самых тихих причин, почему запросы внезапно превращаются в тормоза.
Вместо этого приводи значения заранее или используй функциональные индексы.
Плохо: индекс по email НЕ используется
SELECT *
FROM users
WHERE LOWER(email) = 'user@example.com';
-- Хорошо: нормализуем значение заранее
SELECT *
FROM users
WHERE email = 'user@example.com';
-- Или создаём функциональный индекс (PostgreSQL)
CREATE INDEX idx_users_email_lower ON users (LOWER(email));
https://www.youtube.com/shorts/AyiAslOeJFA
🔥6❤3👍3👎1🤔1