Комментарии 56
НЛО прилетело и опубликовало эту надпись здесь
«Глупо отвечать на вопрос, который вы не понимаете. Грустно стремиться к цели, которую вы не желаете достичь.»
Дык, это ж про любого политика. То, что для одних глупо, для других — суть их работы
аффтор вероятно студент и делает первые шаги в индустрии. студент так и не понял что популярность бигдата стека не от размера данных, а от бесплатности. те кто внедряют хорошо понимают что они не гугл. они внедряют хадупы в первую очередь, что бы не платить миллионы за лицензии. они не гугл, они просто считают деньги.
постгрес бесплатный
платный. как минимум та вариация (greenplum), которая хоть как то соревнуется с хадупами и мап-редюсами.
а обычный постгрес совсем под аналитику не подходит. там нет колончатых структур и мусор в таблицах раздувает файлы данных. и партишенинг лишь в пг10 обещают завести, то что там есть пародия, не партишенинг.
а обычный постгрес совсем под аналитику не подходит. там нет колончатых структур и мусор в таблицах раздувает файлы данных. и партишенинг лишь в пг10 обещают завести, то что там есть пародия, не партишенинг.
Вот как раз по моему опыту студенты очень легко поддаются хайпу на технологии, ибо собственного критического опыта пока еще не хватает, зато энтузиазм так и прет, и очень хочется добавить красивые строчки к своему пока полупустому резюме.
Ну, вы не совсем правы точно. Хотя то что написано в посте про хадуп, с моей точки зрения тоже так себе формулировочки.
Во-первых, насчет бесплатности. Владение хадупом очень даже платно. У нас скажем CDH, и он не бесплатный, и включает поддержку. Возможно по сравнению с аналогичным ораклом тут и есть какая-то экономия, но весьма не очевидная. Не говоря уже о том, что ресурсы железа хадуп вполне себе потребляет, и масштабируется неплохо, поэтому машинки с терабайтом памяти в кластере на сегодня уже вполне типичны (и недешевы). Ну и своя поддержка тоже нужна.
Во-вторых, упоминание отказоустойчивости и MapReduce. Вот уж для чего хадуп точно не ставят — так это ради отказоустойчивости. Максимум чего от него стоит ждать — обеспечения _некоторой_ отказоустойчивости на «обычном» железе.
Дальше, сам MapReduce. Уже давно, на момент написания оригинала точно, в мире почти не пишут на чистом MapReduce. Это не значит, что таких нет, я сам писал — ровно одно приложение. Ну хорошо — одно писал, и одно использовал, компилировал и т.п. Но в среднем доля MapReduce быстро стремится к нулю, замещаясь спарком, включая сюда и Python, Hive, и так далее. И этот стек — он не просто сопоставим с любым другим (PL/SQL условно), он зачастую лучше. Он более открыт, гибок, и при этом производителен (при правильной настройке).
Ну и все остальное, по мелочи… Автор похоже не понимает, что компаний, у которых данных завались, на самом деле очень много. Все сотовые операторы с их биллингом, все банки с их карточным процессингом — это генераторы приличных потоков. Сколько нужно данных, чтобы они перестали влезать в один диск? Хм. Я думаю одного дня достаточно, сколько там нынче на один шпиндель, терабайт 8?
Во-первых, насчет бесплатности. Владение хадупом очень даже платно. У нас скажем CDH, и он не бесплатный, и включает поддержку. Возможно по сравнению с аналогичным ораклом тут и есть какая-то экономия, но весьма не очевидная. Не говоря уже о том, что ресурсы железа хадуп вполне себе потребляет, и масштабируется неплохо, поэтому машинки с терабайтом памяти в кластере на сегодня уже вполне типичны (и недешевы). Ну и своя поддержка тоже нужна.
Во-вторых, упоминание отказоустойчивости и MapReduce. Вот уж для чего хадуп точно не ставят — так это ради отказоустойчивости. Максимум чего от него стоит ждать — обеспечения _некоторой_ отказоустойчивости на «обычном» железе.
Дальше, сам MapReduce. Уже давно, на момент написания оригинала точно, в мире почти не пишут на чистом MapReduce. Это не значит, что таких нет, я сам писал — ровно одно приложение. Ну хорошо — одно писал, и одно использовал, компилировал и т.п. Но в среднем доля MapReduce быстро стремится к нулю, замещаясь спарком, включая сюда и Python, Hive, и так далее. И этот стек — он не просто сопоставим с любым другим (PL/SQL условно), он зачастую лучше. Он более открыт, гибок, и при этом производителен (при правильной настройке).
Ну и все остальное, по мелочи… Автор похоже не понимает, что компаний, у которых данных завались, на самом деле очень много. Все сотовые операторы с их биллингом, все банки с их карточным процессингом — это генераторы приличных потоков. Сколько нужно данных, чтобы они перестали влезать в один диск? Хм. Я думаю одного дня достаточно, сколько там нынче на один шпиндель, терабайт 8?
я прав и это факт.
у нас CDH кластер на 600 cores и не платили ни копейки. денег там стоит исключительно супорт, мы супорт не брали. даже 200 ядер на оракле с rac, партишенингом, компрессией, датагвардом это миллионы баксов только лицензий. + еще супорт.
отказоустойчивость в хадупе бай дизайн. вылет любой ноды — штатная ситуация, есть понятие rack awareness. в оракле же rac не отменяет обязанности иметь датагвард, что скорее костыль.
map-reduce, да отходит, но у нас еще вовсю применяется главным образом из-за дубовости и надежности. если у канторы суровые SLA, быстрый спарк с его 100500 нюансов на тему поломанных кешей, меняющимися планами и кастрацией от клоудеры бывает не самый лучший выбор. в map-reduce нечему ломаться и время исполнения много проще предсказать.
у нас CDH кластер на 600 cores и не платили ни копейки. денег там стоит исключительно супорт, мы супорт не брали. даже 200 ядер на оракле с rac, партишенингом, компрессией, датагвардом это миллионы баксов только лицензий. + еще супорт.
отказоустойчивость в хадупе бай дизайн. вылет любой ноды — штатная ситуация, есть понятие rack awareness. в оракле же rac не отменяет обязанности иметь датагвард, что скорее костыль.
map-reduce, да отходит, но у нас еще вовсю применяется главным образом из-за дубовости и надежности. если у канторы суровые SLA, быстрый спарк с его 100500 нюансов на тему поломанных кешей, меняющимися планами и кастрацией от клоудеры бывает не самый лучший выбор. в map-reduce нечему ломаться и время исполнения много проще предсказать.
Я не говорил, что вы не сэкономите по сравнению с ораклом. Я говорю, что это нужно считать. Вас устраивает без поддержки? Ну так у вас и кластер маленький, и вероятно один.
И вот не надо мне рассказывать про отказоустойчивость — вылет namenodes вполне обычное явление, и оно зачастую НЕ выживает после такого. У хадупа еще полно подобных точек отказа, если специально этим не озаботиться.
И вот не надо мне рассказывать про отказоустойчивость — вылет namenodes вполне обычное явление, и оно зачастую НЕ выживает после такого. У хадупа еще полно подобных точек отказа, если специально этим не озаботиться.
вы говорили, что владение хадупом «очень даже платно». надеюсь я доступно это опроверг. кластер по меркам оракла огромный, по меркам хадупа конечно не из больших, но повторюсь, мы не гугл, для нас все дело в тех миллионах, что не ушли на оракловые лицензии.
на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу. если мапер стартовал, то блоки данных у него локальны и от неймноды ничерта уже не нужно. лично я наблюдал много больше проблем при вылетах датанод. инфраструктуру передали кому то внешнему и теперь у нас это не такая уж редкость когда целиком мап-редюс джоб фейлится и у ярна не выходит рестартануть. но к отказу и это не приводит, опять же во многом из-за того что у хадупа файлики имутабл бай дизайн. такие джобы рестартит наш шедулер и никто никогда особо даже такие инциденты на хадупе не замечает. лично у нас устойчивость системы выросла многократно. rac бы сравнимых издевательств не пережил бы однозначно. ни за какие деньги.
а на счет кол-ва у нас еще полно микрокластеров под игрушки, плюс у каждого девелопера все компоненты апликухи в докерах. от куду и импалы, до того самого спарка. на фоне оракла мягко говоря другой уровень. и снова в первую очередь не от того что оракл не могёт в докерах-шмокерах, а лицензионный бред и бабло.
на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу. если мапер стартовал, то блоки данных у него локальны и от неймноды ничерта уже не нужно. лично я наблюдал много больше проблем при вылетах датанод. инфраструктуру передали кому то внешнему и теперь у нас это не такая уж редкость когда целиком мап-редюс джоб фейлится и у ярна не выходит рестартануть. но к отказу и это не приводит, опять же во многом из-за того что у хадупа файлики имутабл бай дизайн. такие джобы рестартит наш шедулер и никто никогда особо даже такие инциденты на хадупе не замечает. лично у нас устойчивость системы выросла многократно. rac бы сравнимых издевательств не пережил бы однозначно. ни за какие деньги.
а на счет кол-ва у нас еще полно микрокластеров под игрушки, плюс у каждого девелопера все компоненты апликухи в докерах. от куду и импалы, до того самого спарка. на фоне оракла мягко говоря другой уровень. и снова в первую очередь не от того что оракл не могёт в докерах-шмокерах, а лицензионный бред и бабло.
Повторюсь, я и не говорил что оно дороже оракла. Я говорил что оно не бесплатное само — и структура этих трат другая, так что нужно считать все равно, за какой-то период. Вы вот похоже почему-то свою работу по настройке кластера не считаете вообще, как будто ее и нет.
>на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу.
Хм. Рассказываю: вы запускаете задачу, длинную, на пару дней. Она в момент перед завершением собирается записать результат в файл, и в это время неймнода того… Ваша задача пытается повторить операцию несколько раз, и завершается с ошибкой. Очень даже незаметно, когда вы теряете работу за два дня.
>на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу.
Хм. Рассказываю: вы запускаете задачу, длинную, на пару дней. Она в момент перед завершением собирается записать результат в файл, и в это время неймнода того… Ваша задача пытается повторить операцию несколько раз, и завершается с ошибкой. Очень даже незаметно, когда вы теряете работу за два дня.
я кластер не настраивал, этим занимается отдельные 1.5 человека. это вполне сравнимо с той командой DBA которые возились с десятком наверно инстансов относящихся к не OLTP задачам.
по неймноде я чуть ниже расписал. хадуп так не работает. zookeeper назначит главной одну из секондари неймнод и джоб ничего не заметит. даже в совсем трагической ситуации джоб не метиться как фейлед целиком, пометится лишь один из тасков редюсера. один из многих сотен. в худшем случае ярн рестартанет один-два редюсера.
по неймноде я чуть ниже расписал. хадуп так не работает. zookeeper назначит главной одну из секондари неймнод и джоб ничего не заметит. даже в совсем трагической ситуации джоб не метиться как фейлед целиком, пометится лишь один из тасков редюсера. один из многих сотен. в худшем случае ярн рестартанет один-два редюсера.
HA для нейм нод без простоя (совсем без простоя все равно нет) давно завезли в хадуп?
у нас вылетала и главная неймнода и секондари. софту это хлопот вообще не доставляло. при файловере zookeeper просто назначает глвной другую неймноду и все. таски мап-редюс или спарка если стартанули, то им пофигу, если они пытаются стартануть прямо во время фаловера, ну пару раз фейлятся, ярн рестартанет.
но суть даже не в том что у хадупа все обложено всякими HA, зукиперами и автоматами на рестарт, а то что там вообще вся идеология строится на имутабл файликах. че-то там зафейливось — не трагедия. минут через 5 можно смело пробовать еще разок стартануть. в традиционных субд же такие фокусы не проходят.
но суть даже не в том что у хадупа все обложено всякими HA, зукиперами и автоматами на рестарт, а то что там вообще вся идеология строится на имутабл файликах. че-то там зафейливось — не трагедия. минут через 5 можно смело пробовать еще разок стартануть. в традиционных субд же такие фокусы не проходят.
Кто такой автор легко выяснить, если перейти по ссылке на оригинал или погуглить «Ozan Onay».
github.com/ozan
Этот?
Этот?
Да, это он.
Скажем прямо, из его github совершенно не очевидно, знает ли он что-то о том, про что пишет. Впрочем, из моего тоже :)
НЛО прилетело и опубликовало эту надпись здесь
Использование излишне сложных инструментов, это одна сторона проблемы. Другая сторона — когда люди/компании пытаются «упросить» задачу путем её усложнения. Например используя фреймворки для статических вебсайтов или прокладки-генераторы запросов для работы с базами данных. Почему то некоторые считают, что язык и синтаксис фреймворка сильно легче, чем любой язык программирования, а выучить sql сложнее, чем разбираться с его интерпретатором.
Отдельным идиотизмом попахивает тенденция к оутсорсингу всего и вся. Одна транснациональная компания, производитель специализированного оборудования, купила решение для создания интерфейсов к софту для управления оборудованием. Для чего им нужен этот фреймворк? Для того, что бы любая секретарша или фрилансер или целая специализированная фирма могли им на коленке мышкой нарастягивать интерфейс за 5 копеек/пучек. Учитывая крайнюю консервативность среды этого софта и редкость релизов, необходимость в дополнительном модуле, который конечно устанавливается отдельно и кушает память и озу, крайне сомнительна. Зато эффективные менеджеры внедрили и освоили и будут экономить по рублю на лайоут. А то, что в релизах у пользователей висят левые строки в меню и разъезжаются панели — зато программисты освоили новый продукт и больше не думают над интерфейсами. Можно сокращать, если что.
Отдельным идиотизмом попахивает тенденция к оутсорсингу всего и вся. Одна транснациональная компания, производитель специализированного оборудования, купила решение для создания интерфейсов к софту для управления оборудованием. Для чего им нужен этот фреймворк? Для того, что бы любая секретарша или фрилансер или целая специализированная фирма могли им на коленке мышкой нарастягивать интерфейс за 5 копеек/пучек. Учитывая крайнюю консервативность среды этого софта и редкость релизов, необходимость в дополнительном модуле, который конечно устанавливается отдельно и кушает память и озу, крайне сомнительна. Зато эффективные менеджеры внедрили и освоили и будут экономить по рублю на лайоут. А то, что в релизах у пользователей висят левые строки в меню и разъезжаются панели — зато программисты освоили новый продукт и больше не думают над интерфейсами. Можно сокращать, если что.
Полезность ORM уже 100 раз обсудили, и давно все сошлись на мнении что если у вас не high-perf случай, то они прекрасно выполняют свою работу. Один язык, автогенерируемые миграции, защита от инъекций, красивый микс исполнения трансформаций на базе и на сервере. Плюсов море, из минусов — пониже перфоманс (часто сильно), и не всегда удобно когда нужно вклиниться с очень кастомным SQL (решаемо).
Про jekyll (github pages) я даже не знаю что вам сказать. Вы хотите чтобы на каждый запрос на статику проворачивалась машинерия рендерящая html? Даже если он не менялся год? Может вам в архитекторы?
Аутсорс — это бизнес решение. Ваша еденичная история — это безусловно повод чтобы сделать обобщение на всех, но возможно стоит посмотреть немного шире.
Про jekyll (github pages) я даже не знаю что вам сказать. Вы хотите чтобы на каждый запрос на статику проворачивалась машинерия рендерящая html? Даже если он не менялся год? Может вам в архитекторы?
Аутсорс — это бизнес решение. Ваша еденичная история — это безусловно повод чтобы сделать обобщение на всех, но возможно стоит посмотреть немного шире.
Из всех плюсов ORM я бы всё же только миграции отметил. Всё остальное решается ничуть не более сложнее, чем без ORM. В этом смысле Dapper мне ближе.
Читая обсуждения тут же на Хабре я совсем не уверен в "сошлись во мнении". Плюс к этому если у вас "не high-perf" то можно и без автомиграций обойтись. Тем более, если у вас "не high-perf" где стоимость оборудования не плюс минус лям, а гораздо меньшие суммы, нативно используя SQL можно сильно экономить.
Про оутсорс это может быть особенность американской среды, но тут это очень популярно у крупных компаний. До степени идиотизма, когда органично внутренние сервисы покупают у сторонних производителей тратя деньги на адаптацию и получая "универсальное" решение в разы сложнее в поддержке, безопасности, трудозатратнее при использовании и тп но зато любую секретаршу обучить можно.
ORM ORM-у рознь. Например, Eloquent очень сильно подставила тем, что вместо LEFT JOIN, она сначала сделала SELECT всех id(загрузив их в память процесса), а затем вставила другой большой SELECT WHERE [id] IN (… и здесь через запятую подставила более 2000+ всех id продаж). Со временем, отображение страницы замедлялось, пока БД не поругалась, что батька передаёт слишком много параметров в одном запросе.
Вместо одного красивого и быстрого запроса она сделала 2 больших, некрасивых, и по моему мнению хуже этого и придумать было невозможно запрос хуже.
Лечить пришлось глубоким изучением синтаксиса Eloquent, чтобы понять в каком же волшебном порядке нужно передавать параметры, чтобы на выходе получился желаемый быстрый SQL-запрос без лишних сущностей и подзапросов. Таким образом, ваш разработчик сначала учит ORM, потом учит SQL, потом доучивает ORM чтобы он был похож на SQL, потом плюётся и не понимает, зачем ему ORM, когда он уже знает SQL (который к тому же мало чем отличается от БД к БД).
Вместо одного красивого и быстрого запроса она сделала 2 больших, некрасивых, и по моему мнению хуже этого и придумать было невозможно запрос хуже.
Лечить пришлось глубоким изучением синтаксиса Eloquent, чтобы понять в каком же волшебном порядке нужно передавать параметры, чтобы на выходе получился желаемый быстрый SQL-запрос без лишних сущностей и подзапросов. Таким образом, ваш разработчик сначала учит ORM, потом учит SQL, потом доучивает ORM чтобы он был похож на SQL, потом плюётся и не понимает, зачем ему ORM, когда он уже знает SQL (который к тому же мало чем отличается от БД к БД).
Я что-то не понял аргумента против кафки. Кто в здравом уме будет руководствоваться идеей "эта штука слишком хороша для нас, поэтому давайте не будем её использовать"? Давайте тогда писать неэффективные sql запросы, индексы не создавать — у нас же не хайлоад, чего уж там.
В случае 100 событий в день можно не запариваться над установкой Кафки и логировать прямо в базу данных, например :)
Могу по своему опыту сказать, что таки да, лучше кафку для нехайлоада не использовать. Нюансов настройки на порядок больше, чем в РСУБД. Плюс они неочевидные. И проблема в том, что они вылезают даже для хеллоувордов в виде различных падений коннекшена по таймаутам, ребалансировкам.
Схема с двумя таблицами в СУБД — одна для данных, вторая для оффсетов, и поллинг раз в н секунд этого дела решит проблему большинства бизнесов, требующих очереди, и при этом одновременно даст ниже стоимость владения и отказоустойчивость из коробки в виде репликации и бекапов.
Схема с двумя таблицами в СУБД — одна для данных, вторая для оффсетов, и поллинг раз в н секунд этого дела решит проблему большинства бизнесов, требующих очереди, и при этом одновременно даст ниже стоимость владения и отказоустойчивость из коробки в виде репликации и бекапов.
НЛО прилетело и опубликовало эту надпись здесь
И оно ведь работает и в обратную сторону. Использование хайповых технологий позволяет быстро набрать людей на рынке. И это тоже может быть осознанным решением — пожертвовать эффективностью и простотой рантайма ради хайринга.
все верно, Resume Driven Development.
позиция разработчика по-честному: зачем отказываться от опыта использования крутой технологии, когда можно ещё и тренинг за счёт работодателя получить^^
я немедленно начну получать предложения о работе — т.е. моя рыночная ценность увеличивается
Мне кажется, описанные в статье примеры по умолчанию содержат предусловие о том, что разработчик хочет в первую очередь решить бизнес задачу оптимальным способом, а не поднять денег или качнуть скилл за счет работодателя/заказчика.
НЛО прилетело и опубликовало эту надпись здесь
Мда, столько слов и все мимо, приплели сюда и концлагерь и политику и еще черти чего. Все проще гораздо.
Я этого и не отрицал, разработчик за выполненную бизнес задачу может получить премию и еще есть моральное удовлетворение — когда твой продукт востребован, им пользуется много людей и у разработчика возникает чувство гордости. Я знаю человека, который работал даже когда перестали платить зарплату, но, правда, таких людей совсем мало.
А есть другой пример, разработчик срать хотел на то, зачем вообще продукт делается, но он читал про микросервисы недавно и ему интересно их попробовать. Дальше все просто, он говорит что без микросервисов ничего не получится. Наигравшись, либо увольняется, либо узнает о новой серебряной пуле и требует все переделать.
Правда жизни такова — разработчик будет стремиться «бизнес задачу оптимальным способом» только тогда, когда это ему выгодно
Я этого и не отрицал, разработчик за выполненную бизнес задачу может получить премию и еще есть моральное удовлетворение — когда твой продукт востребован, им пользуется много людей и у разработчика возникает чувство гордости. Я знаю человека, который работал даже когда перестали платить зарплату, но, правда, таких людей совсем мало.
А есть другой пример, разработчик срать хотел на то, зачем вообще продукт делается, но он читал про микросервисы недавно и ему интересно их попробовать. Дальше все просто, он говорит что без микросервисов ничего не получится. Наигравшись, либо увольняется, либо узнает о новой серебряной пуле и требует все переделать.
Вот тут, мне кажется, вы подошли к сути проблемы. Разработчики используют те или иные технологии не для оптимального решения задачи, а для себя. Для улучшения своего резюме или получения навыков. Ещё есть конечно довольно сильные комплексы и гипертрофированное чувство собственной важности feel like Google. Поэтому гвозди забиваются микроскопом. Ведь микроскоп — это круто
Чтобы выбрать оптимальное решение, нужно много и детально знать, чтобы было что сравнивать. Не все так много знают, поэтому предлагают либо что хорошо знают, либо хайп.
Сколько раз спорил с коллегами, в итоге все равно разтащили систему по микросервисам, оказалось что и них есть минусы, но колеги то были уволены, а разгребать пришлось мне.
Решение микросервисы/монолит (как и любое другое решение) должно соответствовать запросам и учитывать не только сложность реализации и внедрения, но и последующее обслуживание (не говоря уже об решении поставленых задач и стоимости). А самое главное: для каждого отдельного проекта решение будет своё.
Где-то я это уже читал.
Ах да, вот где.
Ах да, вот где.
хочется или нет — но ты «обязан» использовать те или иные технологии. Вся соль в том, что большинство «избыточных» технологий имеют богатую человеко-читаемую документацию, бэст практикс, саксес сторис и т.д… Они не просто существуют — их вам продают. Это как МММ, серьёзно.Так или иначе, как сказали выше, вы придете к тому, что нужно и резюме наполнять и работать с тем, с чем работают в вашей нише. Этот вектор диктуете не вы, а рынок, при чем рынок «больших дядей», поскольку разработчик будет стремится именно в к ним.
Когда-то мы перешли на k8s, clickhouse, ceph и кучу других умных слов и тэгов — что-то попробовать, что-то было реально необходимо — куда не глянь в лицо пихают истории успеха, сравнительные тесты и.т.д… Мы перешли везде, где только смогли достать и «раздробить». По факту мы перешли в точку невозврата. Бич проблемы в том что мы не гугл, но не по тем причинам что написал автор. Мы не гугл в том, что в свое время решили покрыть свои амбиции роста и нагрузки с запасом опираясь на то, что это используют все и это правильный путь использовать «современное» и проверенное большими компаниями, а в итоге имеем то, что не можем позволить перечеркнуть месяцы разработки и отказаться от всего к чему пришли, ведь мы получили результат, хоть и не во всем нас устраивающий.
Когда-то мы перешли на k8s, clickhouse, ceph и кучу других умных слов и тэгов — что-то попробовать, что-то было реально необходимо — куда не глянь в лицо пихают истории успеха, сравнительные тесты и.т.д… Мы перешли везде, где только смогли достать и «раздробить». По факту мы перешли в точку невозврата. Бич проблемы в том что мы не гугл, но не по тем причинам что написал автор. Мы не гугл в том, что в свое время решили покрыть свои амбиции роста и нагрузки с запасом опираясь на то, что это используют все и это правильный путь использовать «современное» и проверенное большими компаниями, а в итоге имеем то, что не можем позволить перечеркнуть месяцы разработки и отказаться от всего к чему пришли, ведь мы получили результат, хоть и не во всем нас устраивающий.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вы не Google