зеркало из
https://github.com/iharh/notes.git
synced 2025-10-29 04:44:18 +02:00
m
Этот коммит содержится в:
ihar_hancharenka
родитель
0529709db1
Коммит
b46fac657c
@ -1,3 +1,59 @@
|
||||
18
|
||||
https://t.me/pg_guru/1029
|
||||
*****
|
||||
Уже завтра должна выйти новая, 18я версия PostgreSQL! Давайте посмотрим на еще одно улучшение производительности в этой версии. Это улучшение решает давнее ограничение, когда многоколоночные B-tree индексы могли эффективно использоваться только в запросах, включающих условия равенства для ведущих (крайних слева) столбцов индекса.
|
||||
|
||||
До PostgreSQL 18, если у вас был индекс по (region, category, date), и вы хотели выполнить запрос по category и date, не указывая region, PostgreSQL обычно прибегал к последовательному сканированию таблицы или менее эффективному сканированию индекса. Оптимизация skip scan меняет это, позволяя PostgreSQL интеллектуально "пропускать" части индекса для поиска релеватных данных, даже если ведущие столбцы пропущены в запросе.
|
||||
|
||||
Чтобы понять важность skip scan, давайте сначала рассмотрим, как работают традиционные многоколоночные B-tree индексы и их ограничения.
|
||||
|
||||
В предыдущих версиях PostgreSQL многоколоночные B-tree индексы были наиболее эффективны, когда запросы включали условия по ведущим столбцам. Структура индекса организует данные сначала по первому столбцу, затем по второму столбцу в пределах каждого значения первого столбца и так далее.
|
||||
|
||||
Пример:
|
||||
|
||||
CREATE INDEX idx_sales_region_category_date
|
||||
ON sales (region, category, date);
|
||||
|
||||
-Этот запрос использует индекс эффективно:
|
||||
|
||||
SELECT * FROM sales
|
||||
WHERE region = 'North' AND category = 'Electronics';
|
||||
|
||||
-Этот запрос не может использовать индекс эффективно (до PG18):
|
||||
|
||||
SELECT * FROM sales
|
||||
WHERE category = 'Electronics' AND date > '2025-01-01';
|
||||
|
||||
Второй запрос выше традиционно требовал от PostgreSQL сканировать все записи индекса или возвращаться к последовательному сканированию таблицы, поскольку он не указывает ведущий столбец region.
|
||||
|
||||
Skip scan решает эту проблему, позволяя PostgreSQL эффективно ориентироваться в структуре индекса, даже если ведущие столбцы отсутствуют в запросе. Это достигается за счет идентификации различных значений в неуказанных ведущих столбцах и выполнения целевого сканирования для каждого значения.
|
||||
|
||||
Оптимизация skip scan наиболее эффективна когда ведущие столбцы будут с низкой кардинальностью. Т. е. Skip scan работает лучше всего, когда пропущенные ведущие столбцы имеют относительно немного уникальных значений. Оптимизация работает, по сути, выполняя отдельные сканирования индекса для каждого уникального значения в пропущенных ведущих столбцах, поэтому меньше уникальных значений означает меньше отдельных сканирований.
|
||||
|
||||
Хотя skip scan значительно улучшает производительность запросов во многих сценариях, важно понимать его характеристики и ограничения.
|
||||
|
||||
Skip scan полезен не во всех ситуациях:
|
||||
|
||||
❌ Ведущие столбцы с высокой кардинальностью. Когда ведущий столбец имеет слишком много уникальных значений, skip scan становится неэффективным;
|
||||
|
||||
❌ Большие результирующие наборы.
|
||||
Когда ваш запрос возвращает большую часть таблицы, последовательное сканирование обычно быстрее.
|
||||
|
||||
Планировщик запросов PostgreSQL автоматически определяет, когда skip scan целесообразен, на основе статистики таблицы и оценок стоимости. Вам не нужно вручную настраивать, когда его использовать - планировщик выбирает наиболее эффективный подход для каждого запроса.
|
||||
|
||||
Поддерживайте актуальность статистики таблиц, чтобы обеспечить принятие планировщиком хороших решений об использовании skip scan. Свежая статистика помогает PostgreSQL точно оценивать кардинальность столбцов индекса и принимать оптимальные решения по использованию skip scan.
|
||||
|
||||
Ограничения
|
||||
|
||||
Skip scan в PostgreSQL 18 имеет определенную область применения:
|
||||
|
||||
📌 Работает только с индексами типа B-tree;
|
||||
📌 Наиболее эффективен, когда пропущенные ведущие столбцы имеют низкую кардинальность;
|
||||
📌 Требует по крайней мере одно условие равенства для последующего столбца в индексе;
|
||||
📌 Преимущество в производительности уменьшается по мере роста количества уникальных значений в пропущенных столбцах.
|
||||
|
||||
Ждем PostgreSQL 18 с нетерпением! 😁
|
||||
|
||||
17
|
||||
https://www.postgresql.org/about/news/postgresql-17-released-2936/
|
||||
https://www.postgresql.org/docs/17/release-17.html
|
||||
|
||||
@ -1,2 +1,4 @@
|
||||
2025
|
||||
Otus - SQL Against Data Mess 0:00 of 1:48:15
|
||||
https://www.youtube.com/watch?v=CcCFHwQKWXM
|
||||
https://habr.com/ru/articles/946274/
|
||||
|
||||
3
devops/iaas/terraform/docs/presentations.txt
Обычный файл
3
devops/iaas/terraform/docs/presentations.txt
Обычный файл
@ -0,0 +1,3 @@
|
||||
2025
|
||||
Otus - Terraform Patterns Antipatterns and Modularity 0:00 of 2:00:53
|
||||
https://www.youtube.com/watch?v=Ay6hRs5kFKA
|
||||
@ -1,3 +1,5 @@
|
||||
2025
|
||||
https://habr.com/ru/companies/intec_balance/articles/884482/
|
||||
2021
|
||||
https://habr.com/ru/post/587146/
|
||||
https://blog.bitsrc.io/9-element-tab-features-in-chrome-devtools-for-effective-debugging-1b02aa8f000a
|
||||
|
||||
@ -29,6 +29,8 @@ people
|
||||
! his students - S.S Averintsev, V Bibihin
|
||||
|
||||
2025
|
||||
Mazhuko - QA 37 - Golovosek of 16:07
|
||||
https://www.youtube.com/watch?v=pN_R5KUNiBM
|
||||
Mazhuko - How to Prepare to the Last Times of 11:55
|
||||
https://www.youtube.com/watch?v=V1QKntW7-RA
|
||||
Mazhuko - Humility Way of 13:17
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
2025
|
||||
https://habr.com/ru/companies/postgrespro/articles/878844/
|
||||
https://habr.com/ru/articles/881428/
|
||||
2024
|
||||
https://michalpitr.substack.com/p/linux-container-from-scratch
|
||||
|
||||
@ -1,4 +1,6 @@
|
||||
2024
|
||||
https://www.petermcconnell.com/posts/whispers/
|
||||
https://habr.com/ru/companies/otus/articles/884598/
|
||||
https://getanteon.com/blog/monitoring-postgre-sql-database-on-kubernetes-using-ebpf/
|
||||
2023
|
||||
https://developers.redhat.com/articles/2023/10/19/ebpf-application-development-beyond-basics
|
||||
|
||||
@ -7,6 +7,7 @@ https://www.baeldung.com/hibernate-fetchmode
|
||||
https://www.baeldung.com/hibernate-common-performance-problems-in-logs
|
||||
!!!
|
||||
2025
|
||||
https://habr.com/ru/articles/875134/
|
||||
https://habr.com/ru/articles/896618/
|
||||
2024
|
||||
https://habr.com/ru/companies/magnit/articles/814573/
|
||||
|
||||
@ -8,6 +8,8 @@ Himanshu Sharma - Spring Security of p9
|
||||
https://www.youtube.com/playlist?list=PLlpRbkgzkioF9RRXQ5jK_W6zXAJO9S8Q4
|
||||
|
||||
2025
|
||||
JavaTechie - Spring Security 6 One-Time Token (OTT) | Passwordless Login Explained 0:00 of 34:51
|
||||
https://www.youtube.com/watch?v=5MkNE1qh3C8
|
||||
SpringIO - Modern Authentication Demystified: A Deep Dive into Spring Security’s Latest Innovations 0:00 of 48:19
|
||||
https://www.youtube.com/watch?v=MO0eAEjQxHQ
|
||||
2024
|
||||
|
||||
@ -5,7 +5,9 @@ https://docs.koog.ai/
|
||||
https://github.com/JetBrains/koog-docs
|
||||
|
||||
2025
|
||||
JetBrains - Building Smarter AI Agents With Koog 0:00 of ...
|
||||
Otus - AI for QA with Koog 0:00 of 1:58:46
|
||||
https://www.youtube.com/watch?v=_s2m9jBhI8Q
|
||||
JetBrains - Building Smarter AI Agents With Koog 0:00 of 1:41:16
|
||||
https://www.youtube.com/watch?v=vDtnqQmiyck
|
||||
https://jamshidbekboynazarov.medium.com/kotlins-koog-framework-building-ai-agents-for-smarter-android-experiences-d29dcac28075
|
||||
https://blog.jetbrains.com/ai/2025/05/meet-koog-empowering-kotlin-developers-to-build-ai-agents/
|
||||
|
||||
23
science/ai/rag/docs/exp1.txt
Обычный файл
23
science/ai/rag/docs/exp1.txt
Обычный файл
@ -0,0 +1,23 @@
|
||||
https://t.me/rybakalexey/314
|
||||
*****
|
||||
Ликбез: RAG, или генерация с дополнением
|
||||
|
||||
Признаюсь честно, сначала я не понимал, зачем нужен RAG так массово, почему СУБД бросились реализовывать векторный поиск, и вообще на этом делается неслабый маркетинговый упор. Возможно, вы и сами не очень в теме RAG, и тогда этот пост для вас. Постараюсь очень простыми словами написать, что такое RAG, или генерация c дополнением.
|
||||
|
||||
Начнем с конца: зачем важен контекст промта. Нравится нам это или нет, но LLM уже полноценно заменяют нам поиск. Уже гугл для большинства запросов первым сниппетом в результатах ставит справку из своего AI. Людям удобнее и приятнее читать ответы LLM на вопросы, где нужно обьяснить, где нет четкого ответа. Но LLM строит свои ответы на ранее проиндексированных документах, и этот множество как правило очень широкое. Поэтому если нам нужно построить какую-то поисковую или агентную систему, например, для организации, на основе только какого-то кусочка знаний, в LLM нужно передать этот кусочек, или контекст, поскольку иначе LLM нам что-то ответит на основе всех-всех проиндексированных документов и ценность этого знания будет минимальной.
|
||||
|
||||
Например, у нас есть специфический закрытый софт, на который есть подробная документация (не смейтесь, верьте в хорошее). И есть много пользователей, которые постоянно что-то спрашивают. Читать документацию им лень, да и документация большая, там гигантское оглавление, поди найди отавет на свой вопрос, поэтому проще спросить, и oncall админы, вам лучи добра и глубочайшего сочувствия.
|
||||
|
||||
А теперь представьте, что LLM может взять часть документации и получить её как контекст запроса. В первом приближении это выглядит так: к запросу юзера добавляется что-то вроде в ответе на вопрос используй этот и только этот контекст, и сюда же в запрос добавляется документация целиком. То есть мы говорим машине: вот документ, о котором ты ничего не знаешь, вот запрос пользователя, напиши ответ, основывающийся только на этой документации. Это супер-удобно, быстро делать, пользователям счастье.
|
||||
|
||||
Но документация может быть огромна, контекст широкий, и гонять такие запросы в LLM - дорого и долго ждать. Поэтому нужно передавать только релевантные куски документации. А как определить, какие куски релевантны? Нужно разбить документацию на куски, найти по запросу юзера наиболее близкие по смыску участки документации, и передать в качестве контекста только их. Как определить близкие по смыслу кучки? И тут приходит на помощь другая фича LLM, построение смыслового вектора, или “эмбеддинга”: куски документации при индексации получают от LLM смысловые вектора, а затем они сохраняются в корпоративную СУБД, кусочек доки и эмбеддинг.
|
||||
|
||||
И вся RAG-генерация (или ещё говорят RAG-пайплайн) выглядит так
|
||||
- при индексации: разбить доку на куски, получить эмбеддинги, сохранить в корпоративной субд
|
||||
- по запросу юзера найти близкие по смыслу кусочки доки, используя эмбеддинги
|
||||
- расширить запрос юзера контекстом (кусками доки) и отправит запрос в LLM
|
||||
- показать юзеру результат
|
||||
|
||||
Вот и всё!
|
||||
🔥 если хорошо обьяснил
|
||||
👍 еcли всё уже знал про RAG 🙂
|
||||
@ -1,4 +1,6 @@
|
||||
2025
|
||||
Otus - MSA Auth Practice 0:00 of 1:51:35
|
||||
https://www.youtube.com/watch?v=6Det9XUOqIM
|
||||
Stilicho2011 - How to Set Up and Tune Keycloak 0:00 of 31:09
|
||||
https://www.youtube.com/watch?v=OPk-woAkZaw
|
||||
Devoxx - Authenticate and authorize users “your way” when they access your appl & platf - Alexander Schwartz 0:00 of 32:34
|
||||
|
||||
Загрузка…
x
Ссылка в новой задаче
Block a user