готово сейчас сдаётся так-с так [музыка] Угу Так сейчас я секундочку А запись Угу всё всё поехали да Готово Представься пожалуйста а меня зовут Руслан Расскажи о своём опыте немного а в общей сложности Я где-то уже 15 лет Ну даже уже шестнадцатый год пошёл в разработки вот основной опыт это на PHP Ну если брать в целом То есть были периоды когда писал на пайтоне примерно полтора года вот около года писал на на Джаве Вот но ну и там ещ где-то 67 месяцев писал на гон вот в перерывах там были разные
00:00:08 - 00:02:17
языки был там CP А какое-то время Ну что-то такое небольшое делал совсем на c+ псе Вот Но всё равно возвращался на PHP Так что вот в основном это PHP довольно такой широкий спектр стек Ну да я старался перепробовать всё что всё что мне нравится отлично Давай приступим Расскажи о проектах архитектуры которую вы разрабатывали и в значительной степени улучшали Какие ключевые решения вы приняли и почему как вы обеспечили масштабируемость и поддерживаемой этой архитектуры Угу а из проектов Ну буду брать в целом
00:01:36 - 00:02:57
наверное одни из последних которые были А ну если брать какие-то крупные то это был а предпоследний проект это что-то типа Яндекс Маркета мы а как бы забираем Excel о эмки там порядка на старте было Это около 20-30 млн товаров которые в этих ексель ках расположены вот сейчас там насколько я знаю около 50 млн может быть уже и больше вот а по сути это всё было разработано на PHP использо Framework U второй данных mysql и для того чтобы мы могли каждый день обновлять вот эти вот там 20-30 мл товаров потому что каждый день позиции
00:02:17 - 00:04:00
меняется там что-то условно Ну там просто товар уже недоступен там какие-то товары распроданы и так далее и нам надо постоянно чтобы э актуальность поддерживала для этого Я использовал сервер очередей то есть в фоновом пускаются задачи там порядка 15 процессов Ну п потоков одновременно и соответственно всё это обновляет базу ежедневно вот там у нас в принципе ну это основное как бы то что использовалось и А для того чтобы масштабировать во-первых он довольно масштабируемая система То есть к нему можно подключать другие сер и
00:03:11 - 00:04:45
соответственно можно а ну делать его как бы а мощнее то есть там по сути можно использовать как А ну за счёт именно того что мы добавляем его мощности и соответственно там мы количество потоков можно можно кратно увеличивать а второе по сути mysql Она из коробки не масштабируется так на другие серваки Но есть уже готовые расширение которое позволяет базу данных туже mysql тоже соответственно на разные серваки устанавливать и таким образом мы тоже можем масштабировать Но при нашей загрузке там в 50 условно там даже
00:04:00 - 00:05:30
миллионов А у нас один сервер спокойно с нагрузкой справляется мо отлично Давай следующий вопрос как реализуете паттерн проектирования стратегия в PHP и в каких ситуациях его применение будет наиболее целесообразным Ну если можешь Приведи пример кода Угу давай сейчас я наверно расскажу как бы для чего этот паттерн а потом уже покажу какой-нибудь пример а по сути основная задача этого паттерна условно [музыка] м сделать так чтобы в например могут быть похожие классы но у них может быть реализация разная
00:04:46 - 00:06:20
допустим там класс который скажем а для подключение к базе там можно использовать это подключение к mysql Можно Можно например там к постгрес можно вообще какой-нибудь монко db базе то есть в целом у них функционал похожий это Select Ну условно это вывод это обновление данных delet там ление данных но как бы сами запросы они могут отличаться и по сути стратегия она как бы позволяет создать некий интерфейс который устанавливается всем этим классам и он как бы им говорит что ты должен реализовать условно вот название
00:05:33 - 00:06:46
метода у тебя быт точно такое же как задано в интерфейсе А ну реализацию уже можешь а придумать любую ну как которая тебе необходима А ну давай тогда сейчас я экран рас так тогда надо те остановить наверное будет и [музыка] Угу сечас секундочку так должно быть видно Да видно Так а ну по сути реализовать можно следующим образом можно взять допустим за пример м например архиваторы существуют разного типа архиваторы там есть rar например Zip T Вот ну как бы основные и у них по факту у всех есть разархивировать и либо
00:06:11 - 00:08:08
заархивировать а то есть ну методы но как бы реализация у них разная А по факту мы можем сделать некий интерфейс назвать его чив к примеру дальше мы внутри него можем сказать что у всех классов должен быть какой-нибудь чив к примеру Угу и принимать допустим он должен string и А это тоже должен быть там эрч какой-нибудь F name Вот и возвращает какое-то булевое значение а то есть по факту у нас этот интерфейс он отвечает за то чтобы а говорить Тем классам который мы будем реализовать что там должен быть
00:07:16 - 00:09:16
обязательно этот метод nch соответственно я могу реализовать какой-нибудь rar Strategy условно там и с имплементировать этот чив а соответственно я обязан буду реализовать данный метод Вот и здесь получается уже ну я могу реализовать там условно любую логику которая мне необходима то есть Ну связанно с конкретным типом уже архива да да ну как бы по факту я пока могу просто он требует возвращать какой-то булевой значение То есть я просто буду возвращать True а то есть это может быть rar допустим второе - это допустим Zip
00:08:19 - 00:09:59
тоже соответственно он тоже должен а реализовывать и далее Далее получается Мне нужен некий а некая как бы Центральный класс у словно Да который будет подключать эти стратегии назовём его как-нибудь л допустим л а и здесь получается во-первых некая свойства пусть она называется STR вот здесь получается также мы в Конструктор тоже передаём м по факту мы здесь можем Ну передать именно стратегию которую мы будем использовать далее Мы наш straty straty здесь мы присваиваем ту стратегию которую мы используем и соответственно а
00:09:17 - 00:11:27
ниже ниже А я могу реализовать опять-таки некий метод А который будет Ну в принципе то же самое слово вот а но он будет вызывать метод у конкретной Стратеги Стратеги Угу Так и здесь получается Вот и тут получается передаём ему архив и далее мы это просто можем сделать Рен а соответственно здесь у нас далее мы это делаем во-первых мы стратегию саму запускаем например Пусть это будет rar а далее мы сам можем запустить л мы передаём Стратегию и далее Мы у кла уже вызываем nch вот ну и сюда передаём какой-то
00:10:42 - 00:13:03
там rch rar к примеру Угу всё по факту получается Если я захочу вдруг там Zip я могу там Zip передать и так далее вот таким образом Ну это очень удобно на самом деле шаблон проектирования вот в принципе вот вот вот сам код Понятно так не останавливай да так идём тогда к следующему вопросу Угу Так а как вы оптимизирует запросы к базе данных в PHP для улучшения производительности приложений с большим объёмом данных Расскажи о своём опыте опыте э оптимизации SQL запросов и работе с индексами а оптимизация по сути там есть
00:12:02 - 00:13:44
большое количество Ну условно параметров которые можно оптимизировать Ну во-первых так или иначе это индексы индексы нам в любом случае ускоряют выборку из базы Вот Но у индексов есть Как положительна так и отрицательная сторона то есть они могут ускорять выборку но при этом они замедляют ставку Обычно я [музыка] использую колонки которые используются в условиях там V или Group вот или Order by то есть на них как правило в первую очередь выставляются индексы а далее то что касается оптимизация -
00:12:58 - 00:14:30
это второй момент при селекте мы указываем непосредственно те колонки которые нам нужны то есть не через звёздочку что типа мы там все да а только те которые нужны второе я обычно использую - это лимит то есть в запросе как правило лучше использовать лимит чтобы указать Ну как бы то количество а данных которые тебе требуется а соответственно Также можно использовать каширование запросов обычно Ну допустим А в проектах где я использую там ui2 там как правило есть методы которые реализуют кэширование запросов
00:13:46 - 00:15:08
Вот сам кэш он может по сути находиться либо в Диси либо например в файлах Вот то есть что доступно Но как правило естественно если сам по себе запрос тяжёлый то лучше конечно ну кэшировать его из последнего опыта где у нас порева пря такая опция как раз-таки вот тоже был проект где у нас было вот этих вот много там данных там А 20 млн там этих 30 млв товаров и там а была сильная задержка на главной странице Она грузила порядка 2,5т секунд что это как бы крайне неприемлемо Вот то есть страница как правило же там не должна грузиться
00:14:29 - 00:16:21
Ну больше чем 1 Секунда в идеале это там пол полсекунды Вот И там потом Выяснилось что есть там два запроса которые довольно тяжёлые они непосредственно выбирают данные и из таблицы вот во-первых этих запросов было несколько поэтому мы сделали Join запросы для того чтобы как бы более такой жадный жадный запрос был вот во-вторых использовали этих лых запросах Вот и плюс ко всему ещ мы подключили эластик который помог очень сильно при поиске в целом Вот потому что там тоже были определённые проблемы Вот то ну как бы это основное
00:15:24 - 00:17:20
то что оптимизации запросов естественно все остальные соответственно там по колонкам точно также использовалось вот понятно скажи пожалуйста вот Join Да вот затронул тему Join то есть какая что мы можем как сказать какой недостаток если мы будем Джони много данных сразу то есть да мы можем делать у нас жеж есть ленивая и жадная загрузка но как бы если сильно жадною загрузку в что мы можем упереться ну Join по сути Если брать то мы можем опереться в Ну в память так или иначе лимиты памяти да да потому что Join по факту если брать
00:16:23 - 00:17:59
на Ну как бы на уровне базы данных то она же тоже хранит где-то данные то есть условно Join - это просто несколько файлов которые она условно пытается как бы в один такой совместить и Ну соответственно ей надо подтягивать одновременно данные из разных соно если в разных файлах Ну как бы там данных довольно много то Ну это ВС так или иначе упрётся в Ну в производительность память Да это тоже надо за этим следить особенно если к примеру вот сталкивался бывает страницы неважно там категории ещё что-то у них бывают описание И в то
00:17:11 - 00:18:29
описание часто запихивают готовые куски HTML кода и его бывает достаточно много и когда делаешь выборку таких данных получается что Т упирается очень быстро в лимиты Да дада да да за этим Ну это очень жно Да особенно когда у тебя там несколько миллионов данных то там прям аккуратно надо быть переходим к следующему вопросу Представьте что у вас есть очень тяжёлый SQL Запрос который выполняется одну минуту и никак его оптимизировать нельзя причём запрос инициализируется с клиентской стороны а значит Ни в коем
00:17:50 - 00:19:00
случае нельзя допустить чтобы пользователь ждал для получения ответа Разумеется можно зашивать данные запросы например на 5 минут и в дальнейшем пользователи будут работать с этим кешем Ну есть может быть такая ситуация когда через 5 минут кш выпадает и Одновременно несколько десятков пользовательских процессов инициируют запросы которые уже теперь пойдут напрямую в базу опять-таки пользователи будут ждать ону минуту конечно нагрузка рат на базу данных как бы вот такую задачу можно решить пово это можно Каширова условно фоновыми
00:18:26 - 00:19:37
задачами то есть написать например некую консольную улитку и в идеале чтобы она обновлялась делала это заранее А если мы никак не можем оптимизировать уже данный зат который можно было бы использовать подключить например тот же эластик или Сфинкс а то есть это по сути поисковый движки они как бы работают на на то чтобы быстро искать Ну и в то же время быстро отдавать данные Поэтому в целом тоже их можно было бы использовать Это не совсем прямое их назначение но тем не менее А я думаю что они здесь
00:19:03 - 00:20:40
довольно сильно ускорили бы сам запрос а второе в целом можно было бы сделать так чтобы данные подгружать асинхронно вот через тот же акс допустим просто какой-то блок Ну условно Там наша страница подгрузило соответственно какой-то тяжёлый блок он может погрузиться через какое-то количество времени Угу третий момент но здесь опять-таки написано оптимизировать его никак нельзя то есть но в целом можно было бы если я понимаю что это довольно Большая таблица и там очень много данных то можно было бы использовать
00:19:59 - 00:21:30
партиции то есть условно мы можем нарезать одну большую таблицу на как бы на маленький точки вот причём Мы её нарезаем не по столбцам а условно А можно сказать по строкам Аа то есть внутри условно большой таблицы появляется много-много маленьких таблиц и А мы как-то использовали такой подход в нескольких проектах у нас такое было когда это действительно очень сильно помогает Ну вот какой-то из этих бы наверное я думаю точно сработал бы Ну понятно нужно каждый подход тестировать и смотреть искать где у нас
00:20:49 - 00:22:18
Что даёт большее преимущество также и смотреть что нам тяжелее что проще сделать Да выполнить Понятно переходим тогда к следующему так в разрезе mysql база данных Расскажите про отличие от UN по Су это у на первичный ключ он может быть только один бы ну колонка в целом Может быть одна которая у нас Prim обозначается а ри по сути то есть ну условно в базе данных mysql если мы говорим какая-то колонка обычно это ID какая-нибудь вот а то есть значения В этой колонке они все уникальные они не могут никогда
00:21:33 - 00:23:04
повторяться во-первых во-вторых в Пра колонки не должно быть никаких нуль значений Вот и эта колонка Она обычно как правило используется для быстрого поиска То есть у нас там есть условно Ну база данных там любая в принципе без разницы они умеют автоинкремент колонки соответственно у нас там условно мы добавили запись у нас один появился Ну цифра один потом второй у нас д и так далее и как бы эти цифры никогда не повторяются Даже если мы будем удалять соответственно новые данные отсчёт пойдёт с последней там удалённой строчки
00:22:20 - 00:23:50
вот то что касается UN UN тоже как бы эта колонка она должна иметь все значения уникальными но у нас UN как бы может быть несколько как правило колонок либо сери тоже может быть UN и у нас UN может быть нуль в принципе это ну допустимо для этой колонки в принципе основное отличие согласен переходим к следующему вопросу А ну частично уже затронули тему партицирование Да что такое партицирование Что будет если разбить партию по одному параметру к примеру по ID а запрашивать данные по-другому к примеру по User Sex будет ускорение
00:23:06 - 00:24:55
выборки замедление выборки или не будет отличий вообще и от чего это зависеть может но по сути если если мы а разбиваем условно по айди А запрашиваем по секс то а как правило как правило будет замедление а потому что для партиции очень важно использовать ту колонку в качестве условно как бы основного ключа по которой она была разбита А и по факту если мы разбили по одной колонке а используем другую колонку то а всё преимущество по сути партиции оно как бы улетучивается и оно М не даёт нам никаких преимуществ вот поэтому условно
00:24:03 - 00:25:54
если мы Ну как бы там разбили по колонке ID Вот соответственно по колонке ID мы должны делать запросы вот тогда это будет какой-то эффект давать Да логично переходим к следующему есть постоянно обновляемая таблица из несколько миллионов записей о пользователях и их очков необходимо на клиентской стороне показать топ 100 пользователей как бы ты это реализовал [музыка] ну здесь по сути тоже есть несколько вариантов Первый вариант - это опять-таки реализовать с помощью такой фоновой команды которая
00:24:57 - 00:26:22
будет условно там ну я не знаю просто как часто там например эти топ 100 надо показывать Ну в смысле как как часто их нужно обновлять но допустим если это там Раз в час к примеру мы просто пишем одну консольную улитку который раз в час делает запросы к этой тяжёлой таблице и эти там топ 100 пользователей она их хранит условно например там в кэше Вот и на фронт она просто отдаёт уже условно готовый готовый ответ который будет показываться мгновенно хорошо А если бы это какие-то ну более динамичные
00:25:42 - 00:26:57
пользователи то есть игра какая-то идёт она быстрее надо обновлять её можно можно использовать опять-таки какой-нибудь что-то типа что-то типа веб сокетов а которые допустим постоянно опрашивают фронт Ой этот ПК Вот и с небольшой задержкой будут отдавать эти данные То есть тут получается Ну если у нас таблице несколько миллионов записей о пользователях и их очках то по сути какой-то из этих вариантов в зависимости от того насколько быстро их нужно отдавать и насколько частое будет обновление А какой ещё вариант можно было бы
00:26:20 - 00:28:01
использовать наверное Это основное веб сокеты и ну даль сделать насколько это возможно максимально оптимизировать сам запрос то есть индексы которые он используют соответственно там лимиты о и так далее То есть если сам запрос оптимизирован реально уже до там ну прям до максимума до предела да до предела и как бы с ним уже ничего не сделаешь больше то соответственно Т только какие-то вот такие моменты связа СМИ даже по сути даже если Ну там условно таблица будет наверно обновляться Ну данные там не знаю Раз в
00:27:18 - 00:28:50
5 минут к примеру вот а запрос у нас условно там отдаётся там не знаю за 30 секунд или там максимум за минуту то в принципе тот же самый фоновый Ну фоновый этот фоновое приложение который будет его пересчитывать оно здесь тоже подой вот и может минут спокойно обновлять эту таблицу и выдавать данные вот Но дальше уже можно экспериментировать опять-таки с какими-то там дополнительными поисковыми движками которые будут как-то это дело ускорять насколько это возможно Вот либо же если для нас критично чтобы вот прямо
00:28:03 - 00:29:36
в данный момент только из базы мы вытягивали никаких фоновых и так далее а Ну возможно тогда допустим выбрать какую-то другую базу данных которая гораздо быстрее чем там условно текущий там вот если там это mysql соответственно что-то другое попробовать опять-таки какую-нибудь но SQL базу какую-нибудь типа мо db там поставить кассандру Вот и посмотреть Насколько быстро она будет отдавать Ну то есть тут уже в принципе надо экспериментировать Понятно согласен чем в Гид команда отличается от команды по
00:28:51 - 00:30:18
сути когда мы объединяем там условно две ветки то ч переносит историю как бы одной ветки в Ну он её объединяет с историей там условно второй ветки То есть он подтягивает собой саму историю Ну как бы историю он как бы её с нуля перезаписывает вот ну это ну это основное ихнее отличие по сути согласен А что такое PHP fpm и Fast cgi F cgi - это у нас это у нас по сути протокол Он позволяет веб-сервера общаться с какими-то там условно внешними там приложениями вот он имеет очень крутое как бы крутой функционал в том плане что он
00:29:37 - 00:31:38
может открыть несколько соединений и удерживать их итно запросы на эти соединения и Ну то есть он их не закрывает за счёт этого очень сильно вырастает производительность приложении и соответственно можно Ну как бы устраивать такую большую нагрузку и Ну это будет держать очень хорошо PHP это по факту тотже только написанный с оёр для PHP а соответственно когда допустим у нас на eng приходят запросы а получается с помощью вот этого протокола FG Он передаёт данные на PHP fpm и соответственно тот обрабатывает очень
00:30:50 - 00:32:51
быстро поэтому как правило PHP fpm с связки с энжин сом очень любит высоконагруженных приложениях вот и ну там это пользуется большим спросом потому что он действительно держит очень большое количество соединений Вот и с учётом того что он при этом маленькую нагрузку на сервер оказывает Да верно идём дальше какие инструменты и методики вы используете для отладки и профилирования PHP приложений Расскажите о случае когда вам удалось значительно улучшить с помощью профилирования так для отладки и Угу Ну для отладки
00:31:52 - 00:33:28
м я обычно использую либо какой-нибудь А xdb вот либо это может быть просто какой-то Лог файл аа в котором в принципе ну как бы обычно записываются различные полезные вот сейчас ещё много есть сервисов последний мы ставили по-моему он назывался blackfire а то есть это коммерческая разработка они дают PHP расширение которое надо поставить у себя на сервере и оно автоматически собирает всю информацию с как бы приложения вот там по-моему надо Е Ну прописать там пару пару настроек у себя в приложении
00:32:43 - 00:34:28
но суть в том что он собирает это всё и потом получается в как бы ихнем кабинете ты можешь всё это очень в удобной панели изучать то есть там есть различные фильтры там по событиям типа ещ какой-нибудь там это всё красиво помечается и тебе прям очень-очень удобно это всё разглядывать А профилирование для этого последнее мы использовали xh proof от от Фейсбука вот оно довольно классное то есть оно позволяет прямо увидеть полный как бы стек вызова и позволяет посмотреть Сколько памяти на каждом этапе там
00:33:36 - 00:35:28
условно съело Вот но допустим в том же самом U фреймворке У него своя очень классная дебаг панель а которая я вот как раз-таки нам и помогла в в одном из проектов Когда у нас когда у нас была большая задержка мы не не до конца понимали где именно на каком этапе и эта панель нам как раз-таки показала А какие запросы очень долго выполняются и ну условно Где больше всего съедается ресурсов Вот и когда мы эти запросы привели в порядок соответственно у нас всё заработало вот а ну и тоже на на одном из предыдущих
00:34:31 - 00:36:18
проектов у нас была проблема Аа там по-моему связанное с категориями было у нас были большие данные которые подвязали категориям и тоже страница начала Долго грузиться и вот благодаря вот этой панельке в юи А мы очень быстро обнаружили в чём проблема И соответственно пофиксили буквально за там полдня наверное Ну у самой панельки тоже есть наверное недостаток так как она по сути чтобы её вызвать надо ж наверное в деф моде работать да и соответственно приложение уже замедляется Мне кажется да вот как когда начинает собирать вот
00:35:30 - 00:36:52
эту всю статистику и всё-таки наверное вот эти внешние Как пруфы де баге они более как сказать не то что независимые но дают более информацию Ну да независимую информацию Да потому что сам сам этот панель нагружает его ну есть такое Но на самом деле все эти приложения что X proof что blackfire то есть у них в принципе даже у самих написано там на сайте что как бы ну нагрузка так или иначе создаётся с помощью этого приложения с ними можно гораздо более точно определить то есть там более как хирургическим таким путём найти точки
00:36:13 - 00:37:53
Вот Но когда условно у тебя прям страница очень медленно грузится то по сути тот же он тебе в первую очередь покажет хотя бы куда тебе в целом смотреть куда направить взгляд Вот и условно мы вот эти там два-три запроса когда пофиксили то есть мы опустили планку Примерно в три раза и у нас там с 3 секунд упало до А 0,5 или 0,2 секунды Вот то есть мы очень сильно опустили И если бы как бы Ну понятное дело Если бы там надо было бы ещё опускать то здесь Да здесь бы уже бы какой-нибудь X proof или Black Fire он бы помог бы более
00:37:04 - 00:38:43
точнее определить на на Что делать ещё упор Вот но как бы да эти инструменты есть конечно лучше ими всеми так или иначе пользоваться А согласен абсолютно согласен А есть два отсортированных массива целых чисел необходимо составить третий массив который будет включать все элементы этих двух массивов сохраняя сортировку нужно сделать алгоритм обладающий минимальной сложностью Угу алгоритмическая Задачка Да давай тогда наверное Давай я экран Раша так-с давай всё это уберём Так значит у нас есть два
00:37:53 - 00:39:25
сортированный массива надо объединить их сохраняя сортировку Да сохраняя сортировку хорошо условно У нас есть массив какой-нибудь 1 2 3 и есть второй массив 4 5 пример А здесь в принципе можно использовать можно использовать алгоритм слияния То есть это будет что-то типа какой-нибудь АК То есть получается мы Один массив получаем и второй массив соответственно нам надо важно сохранить порядок а таким образом возьмём указатели пусть будет два основных указателя на каждый массив и результирующая выборка которая
00:38:51 - 00:41:04
сохраняется и по факту по факту здесь а мы бежим мы можем бежать одновременно как бы по двум массивам Вот и поскольку у нас есть сортировка условно от большего к меньшему мы соответственно в таком порядке должны их разложить и если у нас эти условно там два массива Ну то есть при переборе то есть Сначала мы как бы их два берём для того чтобы взять из них то количество данных которое имеется То есть у нас условно тут вот сейчас по три в каждом массиве то есть они как бы ну как бы по количеству значения они
00:40:10 - 00:41:47
одинаковые Вот если бы здесь например было бы семь то соответственно он бы уже ну он бы был больше чем первый массив получается Мы сначала бежим по обоим складываем это всё А сохраняя сортировку И после этого мы уже забираем То что осталось как бы ну не задействовано то есть А примерно это выглядит таким вот образом здесь у нас R1 здесь соответственно мы бежим по R2 и здесь нам по сути надо проверять что если у нас значение первого массива меньше чем значение второго то тогда мы его положим получается мы его кладём и
00:41:05 - 00:42:52
соответственно после этого увеличиваем иначе То есть если мы понимаем что значение в Первом массиве больше чем во втором тогда получается нам надо сначала взять из второго точно также увеличить и здесь у нас получается ещё есть остатки которые могут появиться могут не появиться здесь получается мы берём а сами остатки и доки ды их в массив соответственно точно также чего я и здесь у нас второй массив так который тоже таким образом м ну и в конце мы делаем Return соответственно здесь мы передаём
00:42:24 - 00:44:39
R1 R2 и в конце выводим результат так R1 R2 а а здесь всё верно Можно попробовать запустить наверное даже А понял Так 1 2 3 А я что-то Я передал [музыка] а а Сорри всё вот сортировка у нас сохранилась и соответственно результирующий массив вот такой вышел Угу есть так е чтото осталось Нет это был последний в принципе вопрос а так секунду а всё я я понял было спасибо большое за ответы было очень интересно что ж я передам информацию руководству и мы свяжемся через 2-3 дня Угу спасибо большое спасибо большое так
00:44:07 - 00:46:26
а ребят кто там сейчас на эфире вопросы чат gpt сделал вопросы ча нет вопросы не ptl вопросы и думали вопросы Думали да вопросы думали Может быть там какой-то был вопрос из чата gpt а но как бы основные вопросы они они наши так если вопросы то напишите Если нет то давайте заканчивать В общем вопросов нету Так что я предлагаю завершать всё тебе большое спасибо А да взаимно всё
готово сейчас сдаётся так-с так [музыка] Угу Так сейчас я секундочку А запись Угу всё всё поехали да Готово Представься пожалуйста а меня зовут Руслан Расскажи о своём опыте немного а в общей сложности Я где-то уже 15 лет Ну даже уже шестнадцатый год пошёл в разработки вот основной опыт это на PHP Ну если брать в целом То есть были периоды когда писал на пайтоне примерно полтора года вот около года писал на на Джаве Вот но ну и там ещ где-то 67 месяцев писал на гон вот в перерывах там были разные
00:00:08 - 00:02:17
языки был там CP А какое-то время Ну что-то такое небольшое делал совсем на c+ псе Вот Но всё равно возвращался на PHP Так что вот в основном это PHP довольно такой широкий спектр стек Ну да я старался перепробовать всё что всё что мне нравится отлично Давай приступим Расскажи о проектах архитектуры которую вы разрабатывали и в значительной степени улучшали Какие ключевые решения вы приняли и почему как вы обеспечили масштабируемость и поддерживаемой этой архитектуры Угу а из проектов Ну буду брать в целом
00:01:36 - 00:02:57
наверное одни из последних которые были А ну если брать какие-то крупные то это был а предпоследний проект это что-то типа Яндекс Маркета мы а как бы забираем Excel о эмки там порядка на старте было Это около 20-30 млн товаров которые в этих ексель ках расположены вот сейчас там насколько я знаю около 50 млн может быть уже и больше вот а по сути это всё было разработано на PHP использо Framework U второй данных mysql и для того чтобы мы могли каждый день обновлять вот эти вот там 20-30 мл товаров потому что каждый день позиции
00:02:17 - 00:04:00
меняется там что-то условно Ну там просто товар уже недоступен там какие-то товары распроданы и так далее и нам надо постоянно чтобы э актуальность поддерживала для этого Я использовал сервер очередей то есть в фоновом пускаются задачи там порядка 15 процессов Ну п потоков одновременно и соответственно всё это обновляет базу ежедневно вот там у нас в принципе ну это основное как бы то что использовалось и А для того чтобы масштабировать во-первых он довольно масштабируемая система То есть к нему можно подключать другие сер и
00:03:11 - 00:04:45
соответственно можно а ну делать его как бы а мощнее то есть там по сути можно использовать как А ну за счёт именно того что мы добавляем его мощности и соответственно там мы количество потоков можно можно кратно увеличивать а второе по сути mysql Она из коробки не масштабируется так на другие серваки Но есть уже готовые расширение которое позволяет базу данных туже mysql тоже соответственно на разные серваки устанавливать и таким образом мы тоже можем масштабировать Но при нашей загрузке там в 50 условно там даже
00:04:00 - 00:05:30
миллионов А у нас один сервер спокойно с нагрузкой справляется мо отлично Давай следующий вопрос как реализуете паттерн проектирования стратегия в PHP и в каких ситуациях его применение будет наиболее целесообразным Ну если можешь Приведи пример кода Угу давай сейчас я наверно расскажу как бы для чего этот паттерн а потом уже покажу какой-нибудь пример а по сути основная задача этого паттерна условно [музыка] м сделать так чтобы в например могут быть похожие классы но у них может быть реализация разная
00:04:46 - 00:06:20
допустим там класс который скажем а для подключение к базе там можно использовать это подключение к mysql Можно Можно например там к постгрес можно вообще какой-нибудь монко db базе то есть в целом у них функционал похожий это Select Ну условно это вывод это обновление данных delet там ление данных но как бы сами запросы они могут отличаться и по сути стратегия она как бы позволяет создать некий интерфейс который устанавливается всем этим классам и он как бы им говорит что ты должен реализовать условно вот название
00:05:33 - 00:06:46
метода у тебя быт точно такое же как задано в интерфейсе А ну реализацию уже можешь а придумать любую ну как которая тебе необходима А ну давай тогда сейчас я экран рас так тогда надо те остановить наверное будет и [музыка] Угу сечас секундочку так должно быть видно Да видно Так а ну по сути реализовать можно следующим образом можно взять допустим за пример м например архиваторы существуют разного типа архиваторы там есть rar например Zip T Вот ну как бы основные и у них по факту у всех есть разархивировать и либо
00:06:11 - 00:08:08
заархивировать а то есть ну методы но как бы реализация у них разная А по факту мы можем сделать некий интерфейс назвать его чив к примеру дальше мы внутри него можем сказать что у всех классов должен быть какой-нибудь чив к примеру Угу и принимать допустим он должен string и А это тоже должен быть там эрч какой-нибудь F name Вот и возвращает какое-то булевое значение а то есть по факту у нас этот интерфейс он отвечает за то чтобы а говорить Тем классам который мы будем реализовать что там должен быть
00:07:16 - 00:09:16
обязательно этот метод nch соответственно я могу реализовать какой-нибудь rar Strategy условно там и с имплементировать этот чив а соответственно я обязан буду реализовать данный метод Вот и здесь получается уже ну я могу реализовать там условно любую логику которая мне необходима то есть Ну связанно с конкретным типом уже архива да да ну как бы по факту я пока могу просто он требует возвращать какой-то булевой значение То есть я просто буду возвращать True а то есть это может быть rar допустим второе - это допустим Zip
00:08:19 - 00:09:59
тоже соответственно он тоже должен а реализовывать и далее Далее получается Мне нужен некий а некая как бы Центральный класс у словно Да который будет подключать эти стратегии назовём его как-нибудь л допустим л а и здесь получается во-первых некая свойства пусть она называется STR вот здесь получается также мы в Конструктор тоже передаём м по факту мы здесь можем Ну передать именно стратегию которую мы будем использовать далее Мы наш straty straty здесь мы присваиваем ту стратегию которую мы используем и соответственно а
00:09:17 - 00:11:27
ниже ниже А я могу реализовать опять-таки некий метод А который будет Ну в принципе то же самое слово вот а но он будет вызывать метод у конкретной Стратеги Стратеги Угу Так и здесь получается Вот и тут получается передаём ему архив и далее мы это просто можем сделать Рен а соответственно здесь у нас далее мы это делаем во-первых мы стратегию саму запускаем например Пусть это будет rar а далее мы сам можем запустить л мы передаём Стратегию и далее Мы у кла уже вызываем nch вот ну и сюда передаём какой-то
00:10:42 - 00:13:03
там rch rar к примеру Угу всё по факту получается Если я захочу вдруг там Zip я могу там Zip передать и так далее вот таким образом Ну это очень удобно на самом деле шаблон проектирования вот в принципе вот вот вот сам код Понятно так не останавливай да так идём тогда к следующему вопросу Угу Так а как вы оптимизирует запросы к базе данных в PHP для улучшения производительности приложений с большим объёмом данных Расскажи о своём опыте опыте э оптимизации SQL запросов и работе с индексами а оптимизация по сути там есть
00:12:02 - 00:13:44
большое количество Ну условно параметров которые можно оптимизировать Ну во-первых так или иначе это индексы индексы нам в любом случае ускоряют выборку из базы Вот Но у индексов есть Как положительна так и отрицательная сторона то есть они могут ускорять выборку но при этом они замедляют ставку Обычно я [музыка] использую колонки которые используются в условиях там V или Group вот или Order by то есть на них как правило в первую очередь выставляются индексы а далее то что касается оптимизация -
00:12:58 - 00:14:30
это второй момент при селекте мы указываем непосредственно те колонки которые нам нужны то есть не через звёздочку что типа мы там все да а только те которые нужны второе я обычно использую - это лимит то есть в запросе как правило лучше использовать лимит чтобы указать Ну как бы то количество а данных которые тебе требуется а соответственно Также можно использовать каширование запросов обычно Ну допустим А в проектах где я использую там ui2 там как правило есть методы которые реализуют кэширование запросов
00:13:46 - 00:15:08
Вот сам кэш он может по сути находиться либо в Диси либо например в файлах Вот то есть что доступно Но как правило естественно если сам по себе запрос тяжёлый то лучше конечно ну кэшировать его из последнего опыта где у нас порева пря такая опция как раз-таки вот тоже был проект где у нас было вот этих вот много там данных там А 20 млн там этих 30 млв товаров и там а была сильная задержка на главной странице Она грузила порядка 2,5т секунд что это как бы крайне неприемлемо Вот то есть страница как правило же там не должна грузиться
00:14:29 - 00:16:21
Ну больше чем 1 Секунда в идеале это там пол полсекунды Вот И там потом Выяснилось что есть там два запроса которые довольно тяжёлые они непосредственно выбирают данные и из таблицы вот во-первых этих запросов было несколько поэтому мы сделали Join запросы для того чтобы как бы более такой жадный жадный запрос был вот во-вторых использовали этих лых запросах Вот и плюс ко всему ещ мы подключили эластик который помог очень сильно при поиске в целом Вот потому что там тоже были определённые проблемы Вот то ну как бы это основное
00:15:24 - 00:17:20
то что оптимизации запросов естественно все остальные соответственно там по колонкам точно также использовалось вот понятно скажи пожалуйста вот Join Да вот затронул тему Join то есть какая что мы можем как сказать какой недостаток если мы будем Джони много данных сразу то есть да мы можем делать у нас жеж есть ленивая и жадная загрузка но как бы если сильно жадною загрузку в что мы можем упереться ну Join по сути Если брать то мы можем опереться в Ну в память так или иначе лимиты памяти да да потому что Join по факту если брать
00:16:23 - 00:17:59
на Ну как бы на уровне базы данных то она же тоже хранит где-то данные то есть условно Join - это просто несколько файлов которые она условно пытается как бы в один такой совместить и Ну соответственно ей надо подтягивать одновременно данные из разных соно если в разных файлах Ну как бы там данных довольно много то Ну это ВС так или иначе упрётся в Ну в производительность память Да это тоже надо за этим следить особенно если к примеру вот сталкивался бывает страницы неважно там категории ещё что-то у них бывают описание И в то
00:17:11 - 00:18:29
описание часто запихивают готовые куски HTML кода и его бывает достаточно много и когда делаешь выборку таких данных получается что Т упирается очень быстро в лимиты Да дада да да за этим Ну это очень жно Да особенно когда у тебя там несколько миллионов данных то там прям аккуратно надо быть переходим к следующему вопросу Представьте что у вас есть очень тяжёлый SQL Запрос который выполняется одну минуту и никак его оптимизировать нельзя причём запрос инициализируется с клиентской стороны а значит Ни в коем
00:17:50 - 00:19:00
случае нельзя допустить чтобы пользователь ждал для получения ответа Разумеется можно зашивать данные запросы например на 5 минут и в дальнейшем пользователи будут работать с этим кешем Ну есть может быть такая ситуация когда через 5 минут кш выпадает и Одновременно несколько десятков пользовательских процессов инициируют запросы которые уже теперь пойдут напрямую в базу опять-таки пользователи будут ждать ону минуту конечно нагрузка рат на базу данных как бы вот такую задачу можно решить пово это можно Каширова условно фоновыми
00:18:26 - 00:19:37
задачами то есть написать например некую консольную улитку и в идеале чтобы она обновлялась делала это заранее А если мы никак не можем оптимизировать уже данный зат который можно было бы использовать подключить например тот же эластик или Сфинкс а то есть это по сути поисковый движки они как бы работают на на то чтобы быстро искать Ну и в то же время быстро отдавать данные Поэтому в целом тоже их можно было бы использовать Это не совсем прямое их назначение но тем не менее А я думаю что они здесь
00:19:03 - 00:20:40
довольно сильно ускорили бы сам запрос а второе в целом можно было бы сделать так чтобы данные подгружать асинхронно вот через тот же акс допустим просто какой-то блок Ну условно Там наша страница подгрузило соответственно какой-то тяжёлый блок он может погрузиться через какое-то количество времени Угу третий момент но здесь опять-таки написано оптимизировать его никак нельзя то есть но в целом можно было бы если я понимаю что это довольно Большая таблица и там очень много данных то можно было бы использовать
00:19:59 - 00:21:30
партиции то есть условно мы можем нарезать одну большую таблицу на как бы на маленький точки вот причём Мы её нарезаем не по столбцам а условно А можно сказать по строкам Аа то есть внутри условно большой таблицы появляется много-много маленьких таблиц и А мы как-то использовали такой подход в нескольких проектах у нас такое было когда это действительно очень сильно помогает Ну вот какой-то из этих бы наверное я думаю точно сработал бы Ну понятно нужно каждый подход тестировать и смотреть искать где у нас
00:20:49 - 00:22:18
Что даёт большее преимущество также и смотреть что нам тяжелее что проще сделать Да выполнить Понятно переходим тогда к следующему так в разрезе mysql база данных Расскажите про отличие от UN по Су это у на первичный ключ он может быть только один бы ну колонка в целом Может быть одна которая у нас Prim обозначается а ри по сути то есть ну условно в базе данных mysql если мы говорим какая-то колонка обычно это ID какая-нибудь вот а то есть значения В этой колонке они все уникальные они не могут никогда
00:21:33 - 00:23:04
повторяться во-первых во-вторых в Пра колонки не должно быть никаких нуль значений Вот и эта колонка Она обычно как правило используется для быстрого поиска То есть у нас там есть условно Ну база данных там любая в принципе без разницы они умеют автоинкремент колонки соответственно у нас там условно мы добавили запись у нас один появился Ну цифра один потом второй у нас д и так далее и как бы эти цифры никогда не повторяются Даже если мы будем удалять соответственно новые данные отсчёт пойдёт с последней там удалённой строчки
00:22:20 - 00:23:50
вот то что касается UN UN тоже как бы эта колонка она должна иметь все значения уникальными но у нас UN как бы может быть несколько как правило колонок либо сери тоже может быть UN и у нас UN может быть нуль в принципе это ну допустимо для этой колонки в принципе основное отличие согласен переходим к следующему вопросу А ну частично уже затронули тему партицирование Да что такое партицирование Что будет если разбить партию по одному параметру к примеру по ID а запрашивать данные по-другому к примеру по User Sex будет ускорение
00:23:06 - 00:24:55
выборки замедление выборки или не будет отличий вообще и от чего это зависеть может но по сути если если мы а разбиваем условно по айди А запрашиваем по секс то а как правило как правило будет замедление а потому что для партиции очень важно использовать ту колонку в качестве условно как бы основного ключа по которой она была разбита А и по факту если мы разбили по одной колонке а используем другую колонку то а всё преимущество по сути партиции оно как бы улетучивается и оно М не даёт нам никаких преимуществ вот поэтому условно
00:24:03 - 00:25:54
если мы Ну как бы там разбили по колонке ID Вот соответственно по колонке ID мы должны делать запросы вот тогда это будет какой-то эффект давать Да логично переходим к следующему есть постоянно обновляемая таблица из несколько миллионов записей о пользователях и их очков необходимо на клиентской стороне показать топ 100 пользователей как бы ты это реализовал [музыка] ну здесь по сути тоже есть несколько вариантов Первый вариант - это опять-таки реализовать с помощью такой фоновой команды которая
00:24:57 - 00:26:22
будет условно там ну я не знаю просто как часто там например эти топ 100 надо показывать Ну в смысле как как часто их нужно обновлять но допустим если это там Раз в час к примеру мы просто пишем одну консольную улитку который раз в час делает запросы к этой тяжёлой таблице и эти там топ 100 пользователей она их хранит условно например там в кэше Вот и на фронт она просто отдаёт уже условно готовый готовый ответ который будет показываться мгновенно хорошо А если бы это какие-то ну более динамичные
00:25:42 - 00:26:57
пользователи то есть игра какая-то идёт она быстрее надо обновлять её можно можно использовать опять-таки какой-нибудь что-то типа что-то типа веб сокетов а которые допустим постоянно опрашивают фронт Ой этот ПК Вот и с небольшой задержкой будут отдавать эти данные То есть тут получается Ну если у нас таблице несколько миллионов записей о пользователях и их очках то по сути какой-то из этих вариантов в зависимости от того насколько быстро их нужно отдавать и насколько частое будет обновление А какой ещё вариант можно было бы
00:26:20 - 00:28:01
использовать наверное Это основное веб сокеты и ну даль сделать насколько это возможно максимально оптимизировать сам запрос то есть индексы которые он используют соответственно там лимиты о и так далее То есть если сам запрос оптимизирован реально уже до там ну прям до максимума до предела да до предела и как бы с ним уже ничего не сделаешь больше то соответственно Т только какие-то вот такие моменты связа СМИ даже по сути даже если Ну там условно таблица будет наверно обновляться Ну данные там не знаю Раз в
00:27:18 - 00:28:50
5 минут к примеру вот а запрос у нас условно там отдаётся там не знаю за 30 секунд или там максимум за минуту то в принципе тот же самый фоновый Ну фоновый этот фоновое приложение который будет его пересчитывать оно здесь тоже подой вот и может минут спокойно обновлять эту таблицу и выдавать данные вот Но дальше уже можно экспериментировать опять-таки с какими-то там дополнительными поисковыми движками которые будут как-то это дело ускорять насколько это возможно Вот либо же если для нас критично чтобы вот прямо
00:28:03 - 00:29:36
в данный момент только из базы мы вытягивали никаких фоновых и так далее а Ну возможно тогда допустим выбрать какую-то другую базу данных которая гораздо быстрее чем там условно текущий там вот если там это mysql соответственно что-то другое попробовать опять-таки какую-нибудь но SQL базу какую-нибудь типа мо db там поставить кассандру Вот и посмотреть Насколько быстро она будет отдавать Ну то есть тут уже в принципе надо экспериментировать Понятно согласен чем в Гид команда отличается от команды по
00:28:51 - 00:30:18
сути когда мы объединяем там условно две ветки то ч переносит историю как бы одной ветки в Ну он её объединяет с историей там условно второй ветки То есть он подтягивает собой саму историю Ну как бы историю он как бы её с нуля перезаписывает вот ну это ну это основное ихнее отличие по сути согласен А что такое PHP fpm и Fast cgi F cgi - это у нас это у нас по сути протокол Он позволяет веб-сервера общаться с какими-то там условно внешними там приложениями вот он имеет очень крутое как бы крутой функционал в том плане что он
00:29:37 - 00:31:38
может открыть несколько соединений и удерживать их итно запросы на эти соединения и Ну то есть он их не закрывает за счёт этого очень сильно вырастает производительность приложении и соответственно можно Ну как бы устраивать такую большую нагрузку и Ну это будет держать очень хорошо PHP это по факту тотже только написанный с оёр для PHP а соответственно когда допустим у нас на eng приходят запросы а получается с помощью вот этого протокола FG Он передаёт данные на PHP fpm и соответственно тот обрабатывает очень
00:30:50 - 00:32:51
быстро поэтому как правило PHP fpm с связки с энжин сом очень любит высоконагруженных приложениях вот и ну там это пользуется большим спросом потому что он действительно держит очень большое количество соединений Вот и с учётом того что он при этом маленькую нагрузку на сервер оказывает Да верно идём дальше какие инструменты и методики вы используете для отладки и профилирования PHP приложений Расскажите о случае когда вам удалось значительно улучшить с помощью профилирования так для отладки и Угу Ну для отладки
00:31:52 - 00:33:28
м я обычно использую либо какой-нибудь А xdb вот либо это может быть просто какой-то Лог файл аа в котором в принципе ну как бы обычно записываются различные полезные вот сейчас ещё много есть сервисов последний мы ставили по-моему он назывался blackfire а то есть это коммерческая разработка они дают PHP расширение которое надо поставить у себя на сервере и оно автоматически собирает всю информацию с как бы приложения вот там по-моему надо Е Ну прописать там пару пару настроек у себя в приложении
00:32:43 - 00:34:28
но суть в том что он собирает это всё и потом получается в как бы ихнем кабинете ты можешь всё это очень в удобной панели изучать то есть там есть различные фильтры там по событиям типа ещ какой-нибудь там это всё красиво помечается и тебе прям очень-очень удобно это всё разглядывать А профилирование для этого последнее мы использовали xh proof от от Фейсбука вот оно довольно классное то есть оно позволяет прямо увидеть полный как бы стек вызова и позволяет посмотреть Сколько памяти на каждом этапе там
00:33:36 - 00:35:28
условно съело Вот но допустим в том же самом U фреймворке У него своя очень классная дебаг панель а которая я вот как раз-таки нам и помогла в в одном из проектов Когда у нас когда у нас была большая задержка мы не не до конца понимали где именно на каком этапе и эта панель нам как раз-таки показала А какие запросы очень долго выполняются и ну условно Где больше всего съедается ресурсов Вот и когда мы эти запросы привели в порядок соответственно у нас всё заработало вот а ну и тоже на на одном из предыдущих
00:34:31 - 00:36:18
проектов у нас была проблема Аа там по-моему связанное с категориями было у нас были большие данные которые подвязали категориям и тоже страница начала Долго грузиться и вот благодаря вот этой панельке в юи А мы очень быстро обнаружили в чём проблема И соответственно пофиксили буквально за там полдня наверное Ну у самой панельки тоже есть наверное недостаток так как она по сути чтобы её вызвать надо ж наверное в деф моде работать да и соответственно приложение уже замедляется Мне кажется да вот как когда начинает собирать вот
00:35:30 - 00:36:52
эту всю статистику и всё-таки наверное вот эти внешние Как пруфы де баге они более как сказать не то что независимые но дают более информацию Ну да независимую информацию Да потому что сам сам этот панель нагружает его ну есть такое Но на самом деле все эти приложения что X proof что blackfire то есть у них в принципе даже у самих написано там на сайте что как бы ну нагрузка так или иначе создаётся с помощью этого приложения с ними можно гораздо более точно определить то есть там более как хирургическим таким путём найти точки
00:36:13 - 00:37:53
Вот Но когда условно у тебя прям страница очень медленно грузится то по сути тот же он тебе в первую очередь покажет хотя бы куда тебе в целом смотреть куда направить взгляд Вот и условно мы вот эти там два-три запроса когда пофиксили то есть мы опустили планку Примерно в три раза и у нас там с 3 секунд упало до А 0,5 или 0,2 секунды Вот то есть мы очень сильно опустили И если бы как бы Ну понятное дело Если бы там надо было бы ещё опускать то здесь Да здесь бы уже бы какой-нибудь X proof или Black Fire он бы помог бы более
00:37:04 - 00:38:43
точнее определить на на Что делать ещё упор Вот но как бы да эти инструменты есть конечно лучше ими всеми так или иначе пользоваться А согласен абсолютно согласен А есть два отсортированных массива целых чисел необходимо составить третий массив который будет включать все элементы этих двух массивов сохраняя сортировку нужно сделать алгоритм обладающий минимальной сложностью Угу алгоритмическая Задачка Да давай тогда наверное Давай я экран Раша так-с давай всё это уберём Так значит у нас есть два
00:37:53 - 00:39:25
сортированный массива надо объединить их сохраняя сортировку Да сохраняя сортировку хорошо условно У нас есть массив какой-нибудь 1 2 3 и есть второй массив 4 5 пример А здесь в принципе можно использовать можно использовать алгоритм слияния То есть это будет что-то типа какой-нибудь АК То есть получается мы Один массив получаем и второй массив соответственно нам надо важно сохранить порядок а таким образом возьмём указатели пусть будет два основных указателя на каждый массив и результирующая выборка которая
00:38:51 - 00:41:04
сохраняется и по факту по факту здесь а мы бежим мы можем бежать одновременно как бы по двум массивам Вот и поскольку у нас есть сортировка условно от большего к меньшему мы соответственно в таком порядке должны их разложить и если у нас эти условно там два массива Ну то есть при переборе то есть Сначала мы как бы их два берём для того чтобы взять из них то количество данных которое имеется То есть у нас условно тут вот сейчас по три в каждом массиве то есть они как бы ну как бы по количеству значения они
00:40:10 - 00:41:47
одинаковые Вот если бы здесь например было бы семь то соответственно он бы уже ну он бы был больше чем первый массив получается Мы сначала бежим по обоим складываем это всё А сохраняя сортировку И после этого мы уже забираем То что осталось как бы ну не задействовано то есть А примерно это выглядит таким вот образом здесь у нас R1 здесь соответственно мы бежим по R2 и здесь нам по сути надо проверять что если у нас значение первого массива меньше чем значение второго то тогда мы его положим получается мы его кладём и
00:41:05 - 00:42:52
соответственно после этого увеличиваем иначе То есть если мы понимаем что значение в Первом массиве больше чем во втором тогда получается нам надо сначала взять из второго точно также увеличить и здесь у нас получается ещё есть остатки которые могут появиться могут не появиться здесь получается мы берём а сами остатки и доки ды их в массив соответственно точно также чего я и здесь у нас второй массив так который тоже таким образом м ну и в конце мы делаем Return соответственно здесь мы передаём
00:42:24 - 00:44:39
R1 R2 и в конце выводим результат так R1 R2 а а здесь всё верно Можно попробовать запустить наверное даже А понял Так 1 2 3 А я что-то Я передал [музыка] а а Сорри всё вот сортировка у нас сохранилась и соответственно результирующий массив вот такой вышел Угу есть так е чтото осталось Нет это был последний в принципе вопрос а так секунду а всё я я понял было спасибо большое за ответы было очень интересно что ж я передам информацию руководству и мы свяжемся через 2-3 дня Угу спасибо большое спасибо большое так
00:44:07 - 00:46:26
а ребят кто там сейчас на эфире вопросы чат gpt сделал вопросы ча нет вопросы не ptl вопросы и думали вопросы Думали да вопросы думали Может быть там какой-то был вопрос из чата gpt а но как бы основные вопросы они они наши так если вопросы то напишите Если нет то давайте заканчивать В общем вопросов нету Так что я предлагаю завершать всё тебе большое спасибо А да взаимно всё
00:45:57 - 00:47:27