Ну я разумеется не имел ввиду что вообще нчиего не хранит в памяти. Речь скорее о том, что узел не хранит критичное долговременное состояние. Данные без котороых система не сможет продолжить работу.
Если нода в этом слое перезапустится то: данные, сессии и прова не потеряются. Любая другая нода слоя сможет спокойно подхватить работу и отработать эти запросы.
Спасибо за интерес к статье! Сегодня я сознательно не уходил глубоко в детали конкретных OSD-конфигураций, поэтому некоторые моменты действительно остались «за кадром». Это часть нашего ноу-хау.
Однако вопрос то абсолютно правильный. Проблема тут в том, что при большом количестве дисков отказ одного такого SSD может потенциально затронуть сразу группу OSD, а значит привести к массвому восстановлению данных и дополнительной нагрузке на кластер.
Для части сценариев размещение служебных данных непосредственно рядом с основными данными может быть оправдано с точки зрения простоты эксплуатации и стоимости. Для других нет. То есть универсальной схемы здесь нет. И это всегда про баланс между производительностью, стоимостью, отказоустойчивостью, расходами и сложностью эксплуатации.
Про латенси: В подобных архитектурах, да и вообще в индустрии промышленных S3-хранения latency практически никогда не определяться самими накопителями. В промышленных S3, по моему опыту, существенный вклад начинают вносить: сетевой стек, согласование реплик, распределение объектов и балансировка траифка, очереди и взаимодействие между компонентами системы - в общем решает архитектура решения.
Мое мнение кратко, S3 это просто один из инструментов хранения данных. Если вы инженер то нужно разбираться как в теоретических ТТХ выбранного вами инструмента, так и проводить его тестирование под ваш профиль нагрузки.
И если для вас важен супер низкий латенси, вам не нужен S3, посмотрите на хранилища выше по "пирамиде памяти".
В целом еще раз соглашусь с вами: тип диска это далеко не самое узкое место в сложных системах.
Про proxy layer: изначально он проектировался как горизонтально масштабируемый, аппаратно изолированный stateless-слой. Соответственно, масштабирование довольно легко происходит добавлением узлов. Плюс часть нагрузки снимается за счет внутренних механизмов балансировки запросов и кэширования данных.
Дополнительно, для наших клиентов у нас есть интеграция с CDN. Что позволяет: выносить значительную часть нагрузки ближе к edge.
Здесь многое зависит от профиля нагрузки и модели доступа к данным.
Если сильно упростить, то в объектном хранилище стоимость складывается не только из «цены за гиабайт», но и из: - объема самих данных; - количества запросов; - исходящего трафика; - требований к отказоустойчивости и георезервированию; - класса хранения («горячее»/«холодное»).
Поэтому два клиента с одинаковым объемом в 1 ПБ могут иметь очень разную итоговую экономику.
Если говорить про конкурентоспособность, мы регулярно сравниваем себя с крупными облачными S3-провайдерами. Собственная инфраструктура и приложение, собственные ЦОД и компетенции позволяют нам держать очень конкурентную экономику. Вы можете убедиться в этом по ссылке https://selectel.ru/prices/
Именно поэтому для нас критично, что мы работаем на собственных площадках и сами контролируем инженерную инфраструктуру ЦОД от электроснабжения до регламентов эксплуатации. Это позволяет минимизировать зависимость от сторонних подрядчиков и быстрее реагировать на любые отклонения.
В индустрии давно считается лучшей практикой регулярно проводить тестирование аварийных сценариев.
Мое личное мнение - Абсолютно «непадающих» систем в мире не существует, SLA 100% это миф. Но именно постоянные испытания аварийных сценариев, эксплуатационная дисциплина и контроль собственной инфраструктуры позволяют существенно снижать вероятность подобных инцидентов.
Спасибо за развернутый комментарий, вы абсолютно правы.
Архиткетура решения как будто всегда определяется задачей, требовнием и профилем нагрузки. Большая часть роста данных действительно приходится на «холодные» слабо структуррованные данные (медиа, логи, телеметрия, контент с котиками), которые хорошо ложатся в распределённые объектные хранилища и как будто нетребуют постоянной обрабтки.
При этом транзакционные нагрузки никуда не исчезают и классические СУБД остаются основой для OLTP: заказы, платежи, каталоги, учёт остатков и т.д. Да вы правы здссь по-прежнему критичны latency, надежность и консистентность.
Я и не имел ввиду что "всё в мире заменит распределённое хранилище S3, кстати я так удачно его развиваю сейчас, приходите к нам :)"..
Скорее в том, что:
доля данных, которые хранят вне традиционных СУБД продолжает расти и я считаю станет преобладающей;
аналитика и ML всё чаще работают поверх таких хранилищ (S3+ Trino/Iceberg и тп);
архитектура систем хранения становится сложнее: OLTP в классических СУБД, старые данные аналитиков в DWH на Clickhouse, новые данные и экспериментальные кейсы в S3 с Trino.
И все это вместе вызвано не модными трендами, а физическими ограничениями наших технологий на данный момент времени. Значениями ТТХ имеющихся процессоров, памяти, дисков и сетей.
То есть речь шла скорее о смещении тренда, а не о полном отказе.
В любом случае спасибо вам за интерес, я вам благодарен.
Спасибо за интерес к статье и столь содержательные замечания.
Согласен, pg_relation_size(...) / 8192 не является строгим доказательством того, что таблица физически состоит из страниц. Использовал лишь как удобную демонстрацию того, что объем данных кратен размеру страницы (8 KB по умолчанию). Корректнее будет уточнить, что таблицы PostgreSQL действительно состоят из страниц фиксированного размера, и это подтверждается документацией и внутренней организацией heap-файлов, а приведенный запрос иллюстрация, а не proof. С вашего разрешения я немного скорректирую формулировку в статье по следам вашего комментария.
Да, теримн может ввести в заблуждение. Точнее будет сказать:
ctid идентификатор местоположения tuple внутри heap-файла, который включает (block_number, offset_in_page).
Это не абсолютный смещённый байтовый адрес, а координаты внутри структуры heap. Благодаря этму PostgreSQL может найти конкретный tuple без индексации, но сам по себе ctid не указывает положение в виде числа байт. Согласен, что термин стоило уточнить, поправлю.
3. PostgreSQL испльзует механизм TOAST (The Oversized-Attribute Storage Technique). Если строка превышает лимит содержание просто выносятся во внешнее TOAST-хранилище, а в tuple остаётся указатель. Поэтому одна tuple всегда помещается в страницу, а большие значения «разамзываются» по TOAST-страницам. Подробнее можно посмотреть в первоисточнике https://www.postgresql.org/docs/current/storage-toast.htm
4. нет никакой карты "просто страниц" и в ней нет необходимости. Таблица просто хранится в виде линейного файла, состоящего из блоков по 8 КБ внутри heap.Номер страницы это её положение внутри файла. Для более глубокого разбора тоже придется обращаться к первоисточнику https://www.postgresql.org/docs/current/storage-file-layout.html
5. Тут вы верно поняли про FSM и VM они не яаляются частью реализации MVCC, состяния легко и просто перезаписываются без версионирования и это ожидаемое поведение продукта. Идея в том, что они просто подсказки для оптимизации запросов, а не критически важный источник истины. В худшем случае PostgreSQL просто сделает лишний IO и перексанирует страницы.
Спасибо за подробный комментарий. Попробую уточнить, в чём, на мой взгляд, произошло недопонимание.
Идею “созидающий сначала разрушает” высказывал ещё Ницше, и нет доказательств, что она применима к компании.
Разумеется, идея не нова от Шумпетера и Клейтона Кристенсена до Мокира и Талеба её рассматривали в разных контекстах. Но речь не о философской максиме, а о прикладном управленческом паттерне. Компании действительно вынуждены «разрушать» свои старые решения — не в метафизическом, а в инженерном смысле. Примеры есть у всех крупных игроков: Amazon заменил monolith S3 control plane на микросервисы, Netflix несколько раз переписывал систему рекомендаций, а Microsoft закрывает продукты не из-за провала, а ради архитектурной миграции.
Присмотритесь внимательно, это не «натягивание совы», а устойчивая закономерность жизненного цикла технологических систем.
«Google не умеет делать нормально, не уммеет в стабильность».
Что умеет и не умеет Google тема дискусионная.. Я убежден что Google остаётся примером компании, у которой рефакторинг и саморазрушение это часть ДНК. Уничтожение Google Reader, миграции GCP сервисов, перезапуск API, переход к IaaS>SaaS это не “некомпетентность”, а следствие ориентации на эволюцию.
Возможно, конкретно вам неудобно или не понятно, но стратегически весьма оправдано.
«Ну покажите мне компанию с институтами, для начала =) ».
Видимо воспрос терминалогии и личного опыта. Я использую этот термин не в академическом смысле, а как описание «устойчивых организационных механизмов»: обучение, ревью-культура, архитектурные комитеты, продуктовое управление. Всё это формы внутренних институтов, которые регулируют поведение и управляет развитием.
Разумеется я допускаю что мой и ваш опыт работы и список компаний могут очень сильно отличаться.
«Про roadmap устаревания убивать надо».
Не согласен с вами. За это нужно вознаграждать. Многие зрелые компании уже так делают. Например, AWS имеет публичный deprecation policy и EOL процессы. Это нормальная инженерная зрелость: признание, что продукт живёт в ограниченном временном окне, и что для его устойчивости нужно планировать не только рост, но и замещение.
«Продукты умирают, потому что кто-то сделал лучше».
Разумеется я с вами согласен, но этого объяснения недостаточно. Часто «лучше» становится возможным именно потому, что старый игрок застрял в инерции собственной архитектуры или процессов (ну или старые разработчики запугали коллег убийством за подобные изменения).
В контексте продуктового управления основная мысль простая: если команда или компания перестала заниматься созидательным разрушением, то есть осознанно пересматривать, заменять и обновлять, она уже начала проигрывать.
Конкуренты обязательно придут и сделают “лучше”, но только потому, что не боятся разрушить своё вчерашнее решение ради будущего.
Спасибо за внимательность! Вы абсолютно правы в том, что премия по экономике формально не была учреждена самим Альфредом Нобелем она основана Банком Швеции в 1968 году «в память об Альфреде Нобеле».
Тем не менее, официальный сайтhttps://www.nobelprize.org/all-nobel-prizes-2025/ прямо относит эту награду к числу Nobel Prizes, перечисляя её в общем списке вместе с премиями по физике, химии и другим направлениям.
Поэтому использование выражения «Нобелевская премия по экономике» — это не ошибка, а устоявшаяся практика, отражённая в официальных материалах самой Нобелевской организации.
Спасибо за вопрос. Да, схема с чистым L3 и /32 или /31 (для IPv4) концептуально можно реализовать в любой сети. И в кампусной сети, и в сети провайдера, но с оговорками. А зачем?
Для облака, VМ, серверных ферм — мне понятна ценность; для массовых клиентских устройств в кампусе, может быть менее практично. Хотя, возможно, я просто не знаю какую проблему вы хотите решить.
Спасибо за инетрес к статье! Если говорить про foreign keys и views, чаще всего всё будет работать, но лучше перед использованием проверить зависимости (чтото типа SELECT * FROM pg_depend WHERE refobjid = 'your_table'::regclass;) Триггеры переносятся, но я бы рекомендовал проверить их после репака.
Насчет шардирвоания. Увы я не эксперт. Прошу прощения, не подскажу.
Насколько я знаю проблема с ограничениями целостности с отложенной проверкой в pgrepack всё ещё актуальна, и её нужно учитывать. Это обсуждалось и в официальном трекере pg_repack и не закрыто как решённое. Проблема затрагивает достаточно специфичные сценарии, но может быть критичной. Можно также рассмотреть pg_squeeze как альтернативу, хотя он тоже не всегда корректно работает с отоложенными проверками.
Спасибо большое за ваш комментарий, но я явно отразил этот момент с диском в разделе "Ограничения и Грабли". Ну и вы абсолютно правы - магии не бывает. Разные инстурменты работают с разными нюансами и ограничениями. Нужно правильно выбирать их под свои задачи.
Спасибо за валидный комментарий. Вы правы. Судя по всему в мае 2024 года в pg_vector действительно появилась поддержка HNSW. И если я правильно понял только для последних версий PG (16 и 17). Еще раз спасибо, я отредактирую статью по следам нашей дискусии.
Спасибо за комментарий, согласен с вашим мнением. Поэтому пишу однозначно что лично я считаю что для реально большого и требовательного проекта можно посмотреть другие инструменты и предлогаю рейтинг.
Ну я разумеется не имел ввиду что вообще нчиего не хранит в памяти. Речь скорее о том, что узел не хранит критичное долговременное состояние. Данные без котороых система не сможет продолжить работу.
Если нода в этом слое перезапустится то: данные, сессии и прова не потеряются. Любая другая нода слоя сможет спокойно подхватить работу и отработать эти запросы.
Спасибо за интерес к статье! Сегодня я сознательно не уходил глубоко в детали конкретных OSD-конфигураций, поэтому некоторые моменты действительно остались «за кадром». Это часть нашего ноу-хау.
Однако вопрос то абсолютно правильный. Проблема тут в том, что при большом количестве дисков отказ одного такого SSD может потенциально затронуть сразу группу OSD, а значит привести к массвому восстановлению данных и дополнительной нагрузке на кластер.
Для части сценариев размещение служебных данных непосредственно рядом с основными данными может быть оправдано с точки зрения простоты эксплуатации и стоимости. Для других нет. То есть универсальной схемы здесь нет. И это всегда про баланс между производительностью, стоимостью, отказоустойчивостью, расходами и сложностью эксплуатации.
Спасибо за вопрос!
Про латенси: В подобных архитектурах, да и вообще в индустрии промышленных S3-хранения latency практически никогда не определяться самими накопителями. В промышленных S3, по моему опыту, существенный вклад начинают вносить: сетевой стек, согласование реплик, распределение объектов и балансировка траифка, очереди и взаимодействие между компонентами системы - в общем решает архитектура решения.
Чуть подробнее про латенси и разные способы хранения данных я както описывал в этой статье https://habr.com/ru/companies/selectel/articles/987304/
Мое мнение кратко, S3 это просто один из инструментов хранения данных. Если вы инженер то нужно разбираться как в теоретических ТТХ выбранного вами инструмента, так и проводить его тестирование под ваш профиль нагрузки.
И если для вас важен супер низкий латенси, вам не нужен S3, посмотрите на хранилища выше по "пирамиде памяти".
В целом еще раз соглашусь с вами: тип диска это далеко не самое узкое место в сложных системах.
Про proxy layer: изначально он проектировался как горизонтально масштабируемый, аппаратно изолированный stateless-слой. Соответственно, масштабирование довольно легко происходит добавлением узлов. Плюс часть нагрузки снимается за счет внутренних механизмов балансировки запросов и кэширования данных.
Дополнительно, для наших клиентов у нас есть интеграция с CDN. Что позволяет: выносить значительную часть нагрузки ближе к edge.
Здесь многое зависит от профиля нагрузки и модели доступа к данным.
Если сильно упростить, то в объектном хранилище стоимость складывается не только из «цены за гиабайт», но и из:
- объема самих данных;
- количества запросов;
- исходящего трафика;
- требований к отказоустойчивости и георезервированию;
- класса хранения («горячее»/«холодное»).
Поэтому два клиента с одинаковым объемом в 1 ПБ могут иметь очень разную итоговую экономику.
Если говорить про конкурентоспособность, мы регулярно сравниваем себя с крупными облачными S3-провайдерами. Собственная инфраструктура и приложение, собственные ЦОД и компетенции позволяют нам держать очень конкурентную экономику. Вы можете убедиться в этом по ссылке https://selectel.ru/prices/
Именно поэтому для нас критично, что мы работаем на собственных площадках и сами контролируем инженерную инфраструктуру ЦОД от электроснабжения до регламентов эксплуатации. Это позволяет минимизировать зависимость от сторонних подрядчиков и быстрее реагировать на любые отклонения.
В индустрии давно считается лучшей практикой регулярно проводить тестирование аварийных сценариев.
Мое личное мнение - Абсолютно «непадающих» систем в мире не существует, SLA 100% это миф. Но именно постоянные испытания аварийных сценариев, эксплуатационная дисциплина и контроль собственной инфраструктуры позволяют существенно снижать вероятность подобных инцидентов.
Спасибо за развернутый комментарий, вы абсолютно правы.
Архиткетура решения как будто всегда определяется задачей, требовнием и профилем нагрузки. Большая часть роста данных действительно приходится на «холодные» слабо структуррованные данные (медиа, логи, телеметрия, контент с котиками), которые хорошо ложатся в распределённые объектные хранилища и как будто нетребуют постоянной обрабтки.
При этом транзакционные нагрузки никуда не исчезают и классические СУБД остаются основой для OLTP: заказы, платежи, каталоги, учёт остатков и т.д. Да вы правы здссь по-прежнему критичны latency, надежность и консистентность.
Я и не имел ввиду что "всё в мире заменит распределённое хранилище S3, кстати я так удачно его развиваю сейчас, приходите к нам :)"..
Скорее в том, что:
доля данных, которые хранят вне традиционных СУБД продолжает расти и я считаю станет преобладающей;
аналитика и ML всё чаще работают поверх таких хранилищ (S3+ Trino/Iceberg и тп);
архитектура систем хранения становится сложнее: OLTP в классических СУБД, старые данные аналитиков в DWH на Clickhouse, новые данные и экспериментальные кейсы в S3 с Trino.
И все это вместе вызвано не модными трендами, а физическими ограничениями наших технологий на данный момент времени. Значениями ТТХ имеющихся процессоров, памяти, дисков и сетей.
То есть речь шла скорее о смещении тренда, а не о полном отказе.
В любом случае спасибо вам за интерес, я вам благодарен.
Спасибо за интерес к статье и столь содержательные замечания.
Согласен,
pg_relation_size(...) / 8192не является строгим доказательством того, что таблица физически состоит из страниц. Использовал лишь как удобную демонстрацию того, что объем данных кратен размеру страницы (8 KB по умолчанию). Корректнее будет уточнить, что таблицы PostgreSQL действительно состоят из страниц фиксированного размера, и это подтверждается документацией и внутренней организацией heap-файлов, а приведенный запрос иллюстрация, а не proof. С вашего разрешения я немного скорректирую формулировку в статье по следам вашего комментария.Да, теримн может ввести в заблуждение. Точнее будет сказать:
ctidидентификатор местоположения tuple внутри heap-файла, который включает(block_number, offset_in_page).Это не абсолютный смещённый байтовый адрес, а координаты внутри структуры heap. Благодаря этму PostgreSQL может найти конкретный tuple без индексации, но сам по себе
ctidне указывает положение в виде числа байт. Согласен, что термин стоило уточнить, поправлю.3. PostgreSQL испльзует механизм TOAST (The Oversized-Attribute Storage Technique). Если строка превышает лимит содержание просто выносятся во внешнее TOAST-хранилище, а в tuple остаётся указатель. Поэтому одна tuple всегда помещается в страницу, а большие значения «разамзываются» по TOAST-страницам. Подробнее можно посмотреть в первоисточнике https://www.postgresql.org/docs/current/storage-toast.htm
4. нет никакой карты "просто страниц" и в ней нет необходимости. Таблица просто хранится в виде линейного файла, состоящего из блоков по 8 КБ внутри heap.Номер страницы это её положение внутри файла. Для более глубокого разбора тоже придется обращаться к первоисточнику https://www.postgresql.org/docs/current/storage-file-layout.html
5. Тут вы верно поняли про FSM и VM они не яаляются частью реализации MVCC, состяния легко и просто перезаписываются без версионирования и это ожидаемое поведение продукта. Идея в том, что они просто подсказки для оптимизации запросов, а не критически важный источник истины. В худшем случае PostgreSQL просто сделает лишний IO и перексанирует страницы.
Спасибо за подробный комментарий. Попробую уточнить, в чём, на мой взгляд, произошло недопонимание.
Разумеется, идея не нова от Шумпетера и Клейтона Кристенсена до Мокира и Талеба её рассматривали в разных контекстах. Но речь не о философской максиме, а о прикладном управленческом паттерне.
Компании действительно вынуждены «разрушать» свои старые решения — не в метафизическом, а в инженерном смысле. Примеры есть у всех крупных игроков: Amazon заменил monolith S3 control plane на микросервисы, Netflix несколько раз переписывал систему рекомендаций, а Microsoft закрывает продукты не из-за провала, а ради архитектурной миграции.
Присмотритесь внимательно, это не «натягивание совы», а устойчивая закономерность жизненного цикла технологических систем.
Что умеет и не умеет Google тема дискусионная.. Я убежден что Google остаётся примером компании, у которой рефакторинг и саморазрушение это часть ДНК. Уничтожение Google Reader, миграции GCP сервисов, перезапуск API, переход к IaaS>SaaS это не “некомпетентность”, а следствие ориентации на эволюцию.
Возможно, конкретно вам неудобно или не понятно, но стратегически весьма оправдано.
Видимо воспрос терминалогии и личного опыта. Я использую этот термин не в академическом смысле, а как описание «устойчивых организационных механизмов»: обучение, ревью-культура, архитектурные комитеты, продуктовое управление. Всё это формы внутренних институтов, которые регулируют поведение и управляет развитием.
Разумеется я допускаю что мой и ваш опыт работы и список компаний могут очень сильно отличаться.
Не согласен с вами. За это нужно вознаграждать. Многие зрелые компании уже так делают. Например, AWS имеет публичный deprecation policy и EOL процессы. Это нормальная инженерная зрелость: признание, что продукт живёт в ограниченном временном окне, и что для его устойчивости нужно планировать не только рост, но и замещение.
Разумеется я с вами согласен, но этого объяснения недостаточно. Часто «лучше» становится возможным именно потому, что старый игрок застрял в инерции собственной архитектуры или процессов (ну или старые разработчики запугали коллег убийством за подобные изменения).
В контексте продуктового управления основная мысль простая: если команда или компания перестала заниматься созидательным разрушением, то есть осознанно пересматривать, заменять и обновлять, она уже начала проигрывать.
Конкуренты обязательно придут и сделают “лучше”, но только потому, что не боятся разрушить своё вчерашнее решение ради будущего.
Спасибо за внимательность! Вы абсолютно правы в том, что премия по экономике формально не была учреждена самим Альфредом Нобелем она основана Банком Швеции в 1968 году «в память об Альфреде Нобеле».
Тем не менее, официальный сайт https://www.nobelprize.org/all-nobel-prizes-2025/ прямо относит эту награду к числу Nobel Prizes, перечисляя её в общем списке вместе с премиями по физике, химии и другим направлениям.
Поэтому использование выражения «Нобелевская премия по экономике» — это не ошибка, а устоявшаяся практика, отражённая в официальных материалах самой Нобелевской организации.
Спасибо за интерес к статье!
Спасибо за интерес к статье!
Спасибо за вопрос. Да, схема с чистым L3 и /32 или /31 (для IPv4) концептуально можно реализовать в любой сети. И в кампусной сети, и в сети провайдера, но с оговорками. А зачем?
Для облака, VМ, серверных ферм — мне понятна ценность; для массовых клиентских устройств в кампусе, может быть менее практично. Хотя, возможно, я просто не знаю какую проблему вы хотите решить.
Спасибо за инетрес к статье!
Если говорить про foreign keys и views, чаще всего всё будет работать, но лучше перед использованием проверить зависимости (чтото типа SELECT * FROM pg_depend WHERE refobjid = 'your_table'::regclass;)
Триггеры переносятся, но я бы рекомендовал проверить их после репака.
Насчет шардирвоания. Увы я не эксперт. Прошу прощения, не подскажу.
Насколько я знаю проблема с ограничениями целостности с отложенной проверкой в pgrepack всё ещё актуальна, и её нужно учитывать. Это обсуждалось и в официальном трекере pg_repack и не закрыто как решённое. Проблема затрагивает достаточно специфичные сценарии, но может быть критичной. Можно также рассмотреть pg_squeeze как альтернативу, хотя он тоже не всегда корректно работает с отоложенными проверками.
Спасибо большое за ваш комментарий, но я явно отразил этот момент с диском в разделе "Ограничения и Грабли".
Ну и вы абсолютно правы - магии не бывает. Разные инстурменты работают с разными нюансами и ограничениями. Нужно правильно выбирать их под свои задачи.
Спасибо за столь развернутый и подробный комментарий. Позволю себе отредактироваить и отразить подсвеченные вами моменты в статье.
Спасибо за валидный комментарий. Вы правы. Судя по всему в мае 2024 года в pg_vector действительно появилась поддержка HNSW. И если я правильно понял только для последних версий PG (16 и 17). Еще раз спасибо, я отредактирую статью по следам нашей дискусии.
Спасибо за комментарий, согласен с вашим мнением. Поэтому пишу однозначно что лично я считаю что для реально большого и требовательного проекта можно посмотреть другие инструменты и предлогаю рейтинг.
Благодарю за комментарий, буду продолжать эту тему дальше, подписывайтесь.
Спасибо за интересную статью, про крутой инструмент!