From b46fac657ccb025b24b78aabfb4822304b5efd60 Mon Sep 17 00:00:00 2001 From: ihar_hancharenka Date: Thu, 25 Sep 2025 07:44:42 +0300 Subject: [PATCH] m --- db/sql/postgres/docs/whatsnew.txt | 56 +++++++++++++++++++ db/sql/postgres/feature/search/regexp.txt | 2 + devops/iaas/terraform/docs/presentations.txt | 3 + net/browsers/chrome/devtools/articles.txt | 2 + nontech/ortho/people/mazhuko.txt | 2 + os/linux/internals/cgroups/docs/articles.txt | 1 + os/unix/trace/bpf/docs/articles.txt | 2 + .../data/jpa/features/nplusone/articles.txt | 1 + .../spring/security/docs/presentations.txt | 2 + pl/kt/libfws/ai/koog.txt | 4 +- science/ai/rag/docs/exp1.txt | 23 ++++++++ .../provider/keycloak/docs/presentations.txt | 2 + 12 files changed, 99 insertions(+), 1 deletion(-) create mode 100644 devops/iaas/terraform/docs/presentations.txt create mode 100644 science/ai/rag/docs/exp1.txt diff --git a/db/sql/postgres/docs/whatsnew.txt b/db/sql/postgres/docs/whatsnew.txt index 45c02c8a0..d7d8e061d 100644 --- a/db/sql/postgres/docs/whatsnew.txt +++ b/db/sql/postgres/docs/whatsnew.txt @@ -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 diff --git a/db/sql/postgres/feature/search/regexp.txt b/db/sql/postgres/feature/search/regexp.txt index 7cf5c16c5..bca8c9a78 100644 --- a/db/sql/postgres/feature/search/regexp.txt +++ b/db/sql/postgres/feature/search/regexp.txt @@ -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/ diff --git a/devops/iaas/terraform/docs/presentations.txt b/devops/iaas/terraform/docs/presentations.txt new file mode 100644 index 000000000..5998a0086 --- /dev/null +++ b/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 diff --git a/net/browsers/chrome/devtools/articles.txt b/net/browsers/chrome/devtools/articles.txt index af7510bc1..e1e0d40e8 100644 --- a/net/browsers/chrome/devtools/articles.txt +++ b/net/browsers/chrome/devtools/articles.txt @@ -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 diff --git a/nontech/ortho/people/mazhuko.txt b/nontech/ortho/people/mazhuko.txt index 6e57eb6b6..576231752 100644 --- a/nontech/ortho/people/mazhuko.txt +++ b/nontech/ortho/people/mazhuko.txt @@ -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 diff --git a/os/linux/internals/cgroups/docs/articles.txt b/os/linux/internals/cgroups/docs/articles.txt index 7e5e00785..0dca01791 100644 --- a/os/linux/internals/cgroups/docs/articles.txt +++ b/os/linux/internals/cgroups/docs/articles.txt @@ -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 diff --git a/os/unix/trace/bpf/docs/articles.txt b/os/unix/trace/bpf/docs/articles.txt index 17cc7c049..4e5977b5b 100644 --- a/os/unix/trace/bpf/docs/articles.txt +++ b/os/unix/trace/bpf/docs/articles.txt @@ -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 diff --git a/pl/java/libfws/spring/data/jpa/features/nplusone/articles.txt b/pl/java/libfws/spring/data/jpa/features/nplusone/articles.txt index 25a9b5886..9dd0e0be0 100644 --- a/pl/java/libfws/spring/data/jpa/features/nplusone/articles.txt +++ b/pl/java/libfws/spring/data/jpa/features/nplusone/articles.txt @@ -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/ diff --git a/pl/java/libfws/spring/security/docs/presentations.txt b/pl/java/libfws/spring/security/docs/presentations.txt index 5156b9108..e6660dbed 100644 --- a/pl/java/libfws/spring/security/docs/presentations.txt +++ b/pl/java/libfws/spring/security/docs/presentations.txt @@ -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 diff --git a/pl/kt/libfws/ai/koog.txt b/pl/kt/libfws/ai/koog.txt index b40929e06..5dd55e3e3 100644 --- a/pl/kt/libfws/ai/koog.txt +++ b/pl/kt/libfws/ai/koog.txt @@ -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/ diff --git a/science/ai/rag/docs/exp1.txt b/science/ai/rag/docs/exp1.txt new file mode 100644 index 000000000..77a19757b --- /dev/null +++ b/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 🙂 diff --git a/security/provider/keycloak/docs/presentations.txt b/security/provider/keycloak/docs/presentations.txt index a074fb369..dcc1219bc 100644 --- a/security/provider/keycloak/docs/presentations.txt +++ b/security/provider/keycloak/docs/presentations.txt @@ -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