Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
Mostrar más📈 Análisis del canal de Telegram Data Science. SQL hub
El canal Data Science. SQL hub (@sqlhub) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 35 911 suscriptores, ocupando la posición 3 635 en la categoría Tecnologías y Aplicaciones y el puesto 17 843 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 35 911 suscriptores.
Según los últimos datos del 25 agosto, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 10, y en las últimas 24 horas de -14, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 8.19%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 3.64% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 943 visualizaciones. En el primer día suele acumular 1 309 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 17.
- Intereses temáticos: El contenido se centra en temas clave como sql, индекс, postgres, index, sqlite.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 26 agosto, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
Месяц назад в сети появились жалобы на то, что GPT-5.6 в Codex делает с файлами то, о чем его не просили. Самый серьезный кейс - команда, которая должна была почистить за собой временные файлы, вместо этого удаляла файлы пользователя. В ходе разбора выяснили, что Codex создает временные папки и потом чистит их, и в редких случаях чистил неправильно - он переиспользовал под временную работу системную переменную окружения, а некорректная команда очистки затем указывала на настоящий домашний каталог вместо временной папки. Второй случай проще - модель удаляла или перезаписывала временный путь, не посмотрев, что там уже лежит.По итогам расследования добавили дополнительную защиту на нескольких уровнях: 🟢Инструкции самой модели. Codex теперь обязан проверять, что именно он собирается удалить, заводить временные каталоги заново, не переиспользовать системные переменные окружения, выбирать обратимые действия и останавливаться, когда масштаб операции неясен. 🟢Проверки на исполнении. Механизм, который выявляет рискованные команды удаления и отправляет их на ревью, усилили. Если команду отклонили, модель направляют к более безопасному способу. 🟢Ужесточение Full access. Включить полный доступ случайно стало труднее, предупреждения переписали понятнее, а самые рискованные сочетания разрешений дополнительно ограничили. 🟢Обновленный Auto-review. Он стал лучше распознавать деструктивные действия. 🟢Тесты и обучение. OpenAI собрала условия и данные, воспроизводящие найденные сбои. Сейчас добавляются RL-задачи и грейдеры под эти риски, а деструктивные действия вычищаются из обучающих данных. 🟡Что советуют делать самим Обновлять Codex и работать в одном из режимов песочницы -
Ask for approval или Approve for me.
Full access включать только там, где среде можно доверять и откуда легко восстановиться.
@ai_machinelearning_big_data
#news #ai #mlSELECT, JOIN и WHERE действительно помогают найти преступника.
https://store.steampowered.com/app/5072430/Ghost_in_the_SQL_Data/Сама библиотека к Google отношения не имеет, это независимая реализация чужого алгоритма.🟡Turbovec сжимает данные примерно в восемь раз Коллекция из 10 миллионов документов, занимающая в исходном виде 31 гигабайт, умещается в 4. Поиск при этом, как утверждает автор, идёт быстрее, чем в FAISS - одного из самых распространённых инструментов в этой области. По замерам turbovec обгоняет FAISS в среднем в 3,4-3,5 раза при 4-битном сжатии и на 20-26% при 2-битном, в зависимости от железа. 🟡Удобные мелочи Индекс не нужно предварительно обучать - векторы просто добавляются по мере поступления. Сохранение инкрементальное, на диск уходит только то, что изменилось с прошлого раза, поэтому даже на большом индексе это занимает миллисекунды. Поиску можно передать список разрешённых документов - скажем, чтобы пользователь видел только свои файлы. Удаление работает по постоянным идентификаторам, ссылки на записи не плывут. Тем, кто уже сидит на LangChain, LlamaIndex, Haystack или Agno, автор предлагает готовые адаптеры - меняется одна строка импорта, остальной код остаётся как был. 📌Лицензирование: MIT License 🖥 Github @ai_machinelearning_big_data #AI #ML #VectorSearch #TurboQuant #Rust
SELECT COUNT(*) FROM events;
На большой таблице это может читать миллионы строк.
Для быстрой оценки можно взять статистику PostgreSQL:
SELECT reltuples::bigint
FROM pg_class
WHERE relname = 'events';
reltuples хранит примерную оценку количества строк, которую PostgreSQL обновляет после ANALYZE и VACUUM.
Это полезно для админок, мониторинга, дашбордов и проверок вида «в таблице примерно 10 млн или 100 млн строк?», где абсолютная точность не нужна.
А если нужна актуальная оценка:
ANALYZE events;
После этого reltuples станет ближе к реальному количеству строк.
На таблицах в сотни миллионов строк разница между мгновенной оценкой и настоящим COUNT(*) может быть огромной.🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨 В программе четыре продуктовых трека — AI, Data, Security и Hybrid Infrastructure & DevOps, — и отдельный углублённый технологический трек DeepTech, который пройдёт только онлайн. В треке Data расскажем, как Yandex Cloud развивает аналитику от отдельных сервисов к единой бесшовной среде: от загрузки данных до готовых бизнес-инсайтов, где ИИ помогает на каждом этапе. Разберём, как YDB помогает строить рекомендательные и поисковые системы и ИИ‑ассистентов. «Додо Пицца» представит честную историю миграции десятков терабайт данных в Yandex Cloud, а также расскажет о сравнении с западным облаком и совместном преодолении ограничений. Расскажем, как Yandex Cloud движется к самоуправляемым базам данных на основе опыта эксплуатации тысяч баз в Яндексе. «Азбука вкуса» разберёт миграцию Oracle Exadata на Lakehouse в Yandex Cloud без единого аврала. И покажем, как Yandex Managed Service for Valkey научили растягиваться под нагрузку — и вширь, и вглубь.
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨 Отдельно пройдут воркшопы по Data: разберём ключевые сценарии использования ИИ‑агента Нейроаналитика в Yandex DataLens. На практике посмотрим, как PGHouse позволяет OLTP‑базе PostgreSQL прозрачно выполнять OLAP‑запросы в ClickHouse без переписывания SQL. И соберём поисковую систему на Serverless YDB с настройкой полнотекстовых и векторных индексов.
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 И это ещё не всё: демозоны, питчинг решений, IT-квест и мерч — офлайн, а розыгрыши призов и секретный гость — в онлайн-студии.Вся программа — на сайте, регистрация занимает пару минут, а участие бесплатное!
Nested Loop и в итоге прогнать миллионы сравнений.
В PostgreSQL быстро обновить статистику можно так:
ANALYZE users;
А проверить, насколько оценки оптимизатора отличаются от реальности:
EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM users
WHERE status = 'active';
Смотри на разницу между rows= и actual rows=.
Если PostgreSQL ожидал 100 строк, а реально получил 500 000, проблема может быть не в индексе, а в плохой статистике.
Особенно часто это всплывает после массовых INSERT, UPDATE, импорта данных или резкого изменения распределения значений.«Просто гарантируй, что в каждый момент времени пишет только одна машина».А на скрине как раз часть Go-кода LiteFS, которая продлевает этот lease и следит, чтобы узел не продолжал считать себя primary после истечения TTL.
CREATE INDEX idx_users_status ON users(status);
И запрос:
SELECT *
FROM users
WHERE status != 'active';
Кажется, что индекс должен ускорить поиск.
Но если условие возвращает большую часть таблицы, индекс может оказаться дороже обычного Seq Scan.
Например, если 'active' — только 10% строк, то:
status != 'active'
вернёт примерно 90% таблицы.
В таком случае базе дешевле один раз последовательно прочитать таблицу, чем прыгать по индексу к огромному количеству строк.
Проверить можно так:
EXPLAIN ANALYZE
SELECT *
FROM users
WHERE status != 'active';
Смотреть нужно не только на наличие индекса, а на селективность условия.
Особенно часто это проявляется с:
<>
NOT IN
IS NOT NULL
Индекс может быть идеальным, но если запрос выбирает почти всю таблицу, оптимизатор вполне разумно его проигнорирует.