SubscribersHow many subscribers the channel has now. The wave shows subscribers at each point of the period. The change is against the start of the period.3 047▲ 0.7 %+21 for the period
ViewsHow many views the posts published in the period have now. These are not views per day: MAX does not report how many views there were yesterday.908▼ 62.3 %was 2 621
ReactionsHow many reactions the posts published in the period have.13▼ 21.3 %was 18
MentionsHow many times other channels mentioned the channel: links and reposts, excluding advertising posts. The bigger the circle, the more mentions at that point of the period.58▼ 17.9 %was 72with a subscription
RepostsHow many times other channels reposted this channel's posts (excluding advertising posts). Reposts are also counted as mentions.26▼ 1.8 %was 27after signing in
Average post reachHow many views one post gets on average. Only posts older than two days are counted: views of fresh posts are still growing. Points with fresh posts are dashed with hollow dots: the reach of all posts right now, it will still grow.454▼ 48.0 %was 874
ERRWhat share of subscribers sees an average post: average reach ÷ subscribers × 100 %. The line shows ERR at each point of the period, the dashed line — ERR of the previous period of the same length. Points with posts younger than two days are hollow dots on the dashed end of the line.14.9 %▼ 14.0 ppdashed line — was 28.9 %
Engagement ERHow often readers react to posts: reactions ÷ views × 100 %. The tick on the bar is the previous period.1.43 %▲ 0.7 pp
was 0.69 %
Posts per dayHow many posts are published per day on average. Each cell is a point of the period: the darker, the more posts per day.0.3▼ 27.4 %was 0.4
Ad shareWhat share of the period's posts looks like advertising: erid labeling, ad links and other signs. The scale shows the ad load by the quality index thresholds: up to 10 % — low, up to 25 % — moderate, up to 50 % — high, above — very high. A growing share is marked red.2.5 %▼ 1.8 pp
TrendTop — subscribers at the end of each point of the period; bottom — growth per point: green means more subscribers, red means fewer. Above the growth chart — the biggest gain and the biggest loss. MAX does not report how many people subscribed and unsubscribed separately.
Audience growth
+20subscribers in the period
+5 biggest gain · 25 Oct 2026
Channel scoreA channel score from 0 to 100 made of five parts: audience, growth integrity, ad load, trust and calculation reliability. Each bar shows how many points the part earned out of its maximum. The index is recalculated every night; channels are compared with similar ones of the same category and size.
ReachHow many views the posts published at each point of the period have now (not views per day). The record is labeled; the point with today is paler — the day is not over yet. Average post reach — posts older than two days.
Views and reach
908views in the period▼ 62.3 %
Average post reach — 454 views (posts older than two days).
EngagementER — reactions divided by views, in percent — for the posts of each point of the period. The dashed line is ER for the whole period. The change is in percentage points against the previous period of the same length.
Subscriber engagement
1.43 %ER = reactions ÷ views▲ 0.7 pp
Channel ERaverage for the period
CitationsThe citation index (CI) shows how often and by which channels this channel is mentioned over the last 30 days, excluding advertising posts. The level is its place among similar channels. The line shows CI at each point of the period (for a week or month — the average over its days).
RhythmHow many posts are published on average in each hour of each weekday, Moscow time: the darker the cell, the more posts. “Best time” — the hours when posts older than two days have the highest average reach.
When and how much it posts
MonTueWedThuFriSatSun
036912151821
Best time:09:0018:00hours when posts get the highest average reach
FormatsWhat the feed is made of. Each post has one format, by priority: repost, video, photo, link, text. The bar and percentages show the share of posts of each format; on the right — average reach of one post of the format (posts older than two days), the small bar compares it with the most viewed format.
Post formats
100 posts
Reposts99 %6 109
Video2121 %5 014
Photos3838 %5 705
Links1212 %5 320
Text2020 %6 298
On the right — average reach of one post of the format.
PostsEach dot is a post in the period: horizontally — publication date, vertically — views, dot size — reactions, color — format. This shows hits, flops and how reach changes. For large channels, the 100 most viewed posts and an even sample of the rest are shown — no more than 1,500 dots.
Every post is a dot
Higher means more views, bigger means more reactions. Click a dot to open the post.
VideoPhotosOthersize — reactionsZoom with the + and − buttons, a pinch or Ctrl + mouse wheel; drag a zoomed chart to move it
SummaryTotals for the selected period: how many posts were published, how many views and reactions they have now and the average post reach. Views are the current views of posts published on those days, not views per day. The change is against the same span before the period, if statistics cover it.
Period totals
Click a metric to see it across the period below
Viewstoday — the day is not over yetPoints with posts younger than two days are pale and dashed: their views are still growing.
AdsWhat share of the period's posts looks like advertising: erid labeling, ad links and other signs. The detector is cautious, so the real share is usually higher. The scale shows the ad load by the quality index thresholds. Below — the average reach of an ad post and a regular post, and who the channel advertises (sites that ad links lead to).
What worksPosts of the period with the most views. The bar shows views relative to first place. The preview is the post's image; for a post without an image — the channel avatar. Views are the post's current count.
RhythmHow many posts were published each day of the period (pale bars) and the 7-day average (line): you can see whether the channel is speeding up or slowing down. Today is not over yet, so its average is calculated up to yesterday.
Posts by day
Pale bars are days, the line is the 7-day average: you can see whether the channel is speeding up or slowing down
Posts per day7-day average
Data updated at 10:12 Moscow time. Views are the current counts of posts published on those days; average reach counts posts older than two days.
How the quality index is calculated
Один из самых частых вопросов от разработчиков и DevOps - “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇
🔷 PostgreSQL:
🔵 Поддержка JSONB с индексами - почти как NoSQL внутри SQL 🔵 CTE, оконные функции, полнотекстовый поиск - топ для аналитики 🔵 Расширяемость: можно писать свои типы, функции, операторы 🔵 Хорош для сложных запросов, аналитики, геоданных (PostGIS)
🔻 Минусы: – Сложнее в настройке и оптимизации – Меньше хостингов out-of-the-box (но всё быстро меняется)
🔶 MySQL (особенно InnoDB / MariaDB):
🔵 Быстрее на простых SELECT/INSERT, если запросы примитивные 🔵 Больше ready-to-go хостингов и тулов для web 🔵 Низкий порог входа - быстрее поднимается новичками
🔻 Минусы: – Слабее в сложных SQL-конструкциях – Нет нормальной поддержки CTE до недавнего времени – JSON без индексации (в MySQL < 8.0)
Вывод: 🧠 Если делаешь CRM, веб-продукт или MVP с простыми запросами, MySQL зайдёт.
📊 Если строишь data-heavy приложения, BI, ETL или гео-системы, PostgreSQL без шансов.
⚡️ Индексы в базах данных: как заставить запросы летать
Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.
Как это работает под капотом? Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.
✅ Зачем нужны:
* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз. * Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).
❌ Чем платим (минусы):
* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс. * Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.
🛠 Чек-лист: индексировать или нет?
🟢 Обязательно индексируем:
1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY. 2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически. 3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).
🔴 НЕ индексируем:
1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс). 2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен). 3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.
💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.
🦾 LLM умеют генерировать тексты, отвечать на вопросы и работать с документами. Но чтобы использовать их в реальных задачах, важно понимать, как модели принимают решения и почему иногда дают неожиданный результат.
🚀 На открытом уроке разберём, как устроены большие языковые модели и как применять эти знания на практике. Вы узнаете:
— как модель выбирает слова и формирует ответ; — как развернуть LLM локально и проверить её работу через API; — как модели используют контекст из документов и почему это важно для RAG-систем.
Урок подойдет начинающим разработчикам, аналитикам и менеджерам продукта, которые хотят понимать ИИ глубже и использовать его в рабочих задачах. Открытый урок проходит в преддверии старта курса «LLM-инженер».
📋 27 октября в 20:00 МСК. ➡️ Все участники получат скидку на обучение. Принять участие: https://vk.cc/d2Romz
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
– Дублирование данных — имя клиента повторяется в каждом заказе. – Нет масштабируемости — максимум 2 продукта? А если будет 3? – Трудности с запросами — попробуй посчитать топ-5 товаров. Удачи. – Адские апдейты — изменить email клиента надо во всех заказах.
✅ Как правильно:
1. Нормализуй. Раздели данные на сущности: customers, orders, products, order_items. 2. Используй внешние ключи. 3. Не бойся JOIN'ов — они для этого и придуманы.
Пример нормализованной структуры:
-- Таблица клиентов CREATE TABLE customers ( id SERIAL PRIMARY KEY, name TEXT, email TEXT );
-- Таблица заказов CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT REFERENCES customers(id) );
-- Таблица товаров CREATE TABLE products ( id SERIAL PRIMARY KEY, name TEXT, price NUMERIC );
-- Связка товаров и заказов CREATE TABLE order_items ( order_id INT REFERENCES orders(id), product_id INT REFERENCES products(id), quantity INT );
📌 Да, нормализация требует чуть больше времени. Зато потом вы не утонете в хаосе.
Сохрани, чтобы не забыть — и не повторять чужих ошибок.
🎯 Мини-гайд: как НЕ спроектировать монстра вместо схемы БД
Когда проект только начинается, есть соблазн «не заморачиваться» и сделать одну большую таблицу на всё. Спойлер: потом будет больно.
Вот как этого избежать 👇
1. Начинай с нормализации – Смотри, какие поля повторяются. – Разделяй по сущностям: клиент ≠ заказ ≠ товар. – Нормальные формы — не академикам, а тебе на пользу.
2. Определи связи заранее – Один ко многим? Многие ко многим? – Используй FOREIGN KEY, чтобы база помогала тебе, а не мешала.
3. Не бойся JOIN-ов – Да, их становится больше. – Но это лучше, чем сотни NULL - ов и "status_1", "status_2" в одной колонке.
4. Планируй под рост – Временные костыли становятся постоянными. – Заложи масштабируемость: разнос сущностей, отдельные таблицы для логов, истории, связей.
5. Назначь ID-шки как бог велел – PRIMARY KEY + автоинкремент или UUID. – Не делай email или name ключом — это путь в баги.
🧠 Помни: хорошо спроектированная схема ускоряет разработку, а не тормозит её. А переделывать схему сложнее, чем сделать нормально с самого начала.
Когда бизнес-логика усложняется, а структура БД остаётся в духе Excel — жди беды.
🔴 Что это такое? Проектировщик (часто на раннем этапе) создаёт одну большую таблицу, где: – сотни колонок на все случаи жизни, – куча NULL-ов, – смешаны данные разных сущностей (например, и клиенты, и заказы, и статусы).
Так проще… пока не начнётся работа с реальными данными.
💥 Что пойдёт не так: – Производительность падает: индексы не работают эффективно. – Сложность валидации и бизнес-логики. – Трудно расширять: каждое изменение — как операция на открытом сердце. – Нельзя нормально нормализовать: всё связано со всем.
✅ Как избежать: – Используй нормализацию: выноси повторяющиеся и логически независимые данные в отдельные таблицы. – Не бойся JOIN-ов — это не зло, а инструмент. – Планируй схему БД под задачи, а не наоборот.
CREATE TABLE orders ( id SERIAL PRIMARY KEY, order_date VARCHAR(20) );
На первый взгляд — всё ок: дата есть, строка хранит. Но на практике — сплошные проблемы:
🔴 Нет гарантии формата '2024-12-01', '12/01/2024', '01.12.24', 'вчера' — всё ляжет, но работать с этим потом боль.
🔴 Сложность фильтрации и сортировки Сравнение строк ≠ сравнение дат. Запросы типа WHERE order_date > '2024-01-01' могут вести себя непредсказуемо. 🔴 Нельзя использовать функции времени Ни DATE_TRUNC, ни AGE(), ни агрегаты по времени не работают нормально с VARCHAR.
✅ Как правильно Используйте типы DATE, TIMESTAMP, TIMESTAMPTZ — они:
* валидируют данные на вставке; * дают мощный инструментарий для анализа; * упрощают работу с часовыми поясами и интервалами.
CREATE TABLE orders ( id SERIAL PRIMARY KEY, order_date TIMESTAMPTZ DEFAULT now() );
💡 Если данные приходят в виде строк — парси их при загрузке, а не храни как есть.
🔎 Мини-гайд: Индексы в PostgreSQL — быстро и по делу
Индексы — главный инструмент для ускорения запросов. Но неправильное использование может только навредить.
Основные типы индексов в PostgreSQL: - B-tree — по умолчанию. Идеален для поиска по равенству и диапазону (=, <, >, BETWEEN). - Hash — только для поиска по точному равенству (=). Становится актуальным реже. - GIN — для массивов, JSONB, полнотекстового поиска. - GiST — геоданные, поиск по диапазонам, сложные типы. - BRIN — для очень больших таблиц с упорядоченными данными (например, логи).
Практические советы: - Не злоупотребляй индексами: каждый индекс замедляет INSERT/UPDATE/DELETE. - Следи за актуальностью: периодически проверяй и удаляй неиспользуемые (pg_stat_user_indexes поможет). - Составные индексы ((col1, col2)) эффективны, только если условия WHERE учитывают порядок колонок. - Используй EXPLAIN ANALYZE, чтобы понять, работает ли индекс в реальности.
Типичная ошибка: Создать индекс на всё подряд без анализа запросов. Итог — тормоза на записи и огромный размер базы.
✅ Индексы — это как специи: мало — пресно, много — несъедобно.
Вывод: Хотите быструю базу — планируйте индексацию так же внимательно, как сами запросы.
Necessary cookies keep the site working: sign-in, form protection, language and theme. Yandex Metrica analytics cookies and Yandex Advertising Network ad cookies are enabled only with your consent. By clicking “Accept all” you give consent to processing of cookie data; see the Personal Data Processing Policy for details.
