Недавно мы посмотрели на наши данные и выяснили интересный факт. В совокупности люди задают Яндексу 100 миллионов вопросов в день. Если отключить поисковые подсказки, то в сумме все эти пользователи потеряют 60 лет. Это время уйдёт у них на формулировку запроса, его возможное исправление и новую формулировку после того, как они не нашли того, что им нужно. Получается, что если учитывать среднюю продолжительность жизни в России, каждый день саджест позволяет не потерять жизнь одного мужчины.
Да нет же, это способ понять, почему важно биться за доли секунды выгоды для пользователей в массовых сервисах. При этом указано ведь, что это число из другой статьи, в которой достаточно подробно объясняется, о чем речь.
При этом с моей стороны было бы глупо отрицать толику маркетинга ;)
Я не самый главный специалист по сетям, но проблематика тут примерно понятна и состоит из двух частей. Первая — историческая: расселить все имеющиеся сервисы на новые адреса — не за один день делается. Вторая — содержательная: единый балансер означает единую точку отказа, DDoS на один сервис затрагивает сразу и все остальные. Скажем, тот же саджест из-за своих RPS может кратно повышать нагрузку на балансеры.
Ещё остаётся добавить, что это не всегда оправданно. По сути, выигрыш для пользователя здесь заключается в экономии сетевых хендшейков и прочего, что в каких-то случаях существенно — например, для саджеста, который должен откликаться на каждую новую букву,
или для поиска, от скорости получения результатов которого радикально зависит качество пользовательского взаимодействия. В других случаях выгоды от этого могут быть неочевидными.
Ну, если вы каждому из миллиона пользователей экономите секунду, получается миллион сэкономленных секунд, как-то так :) Тут речь идёт об экономии в масштабах всех пользователей, а не каждого конкретного.
Валидный вопрос. К сожалению, речь идет о временах очень давних по айтишным меркам, и приходилось довольствоваться скриншотами двухлетней давности, которые удалось случайно сохранить. Во многом, этот пост возник еще и как попытка сохранить то, что иначе исчезнет навсегда :)
Старый код время от времени приходится удалять, поэтому восстановить состояние сервиса на произвольный момент времени в прошлом невозможно.
Почему же? Вопрос о количестве деревьев поиска с нулём вершин вполне валиден. Более того, «пустые объекты» в комбинаторике широко используются в самых разных ситуациях. Ну, например, сочетания из нуля объектов можно встретить в формуле бинома Ньютона :)
С точки зрения участника может быть несколько мотивов.
Это такое же олимпиадное соревнование, как и любое другое, и поэтому в нём просто будет интересно поучаствовать, попробовать свои силы, решить интересные задачи и научиться чему-то новому. Многие участвуют в подобного рода соревнованиях совершенно бесплатно и с большим удовольствием.
Победители получают денежные призы, и это тоже может быть небесполезно.
Это, действительно, способ избежать одного из этапов собеседования в Яндекс, заменив его процедурой более знакомой и приятной для многих, если сравнивать с традиционными интервью.
Ещё у этого соревнования есть особенность: задачи в нём некоторым образом связаны с теми задачами, которые приходится решать разработчикам Яндекса в повседневной жизни. Примеры таких связей мы постарались описать в статье. Это понимание может быть интересно и само по себе, и как способ понять, стоит ли пытаться устроиться на работу в Яндекс.
Мне кажется, что более-менее любое дополнительное знание способствует тому, что его носитель становится более восприимчив к новым идеям, быстрее учится и так далее, становится лучше, короче (впрочем, это мнение можно при желании оспорить).
В данном случае речь, конечно, не о каком-то магическом превосходстве знания алгоритмов над любыми другими знаниями. Тут намного более простая мысль: если вы разбираетесь в алгоритме, то сумеете относительно быстро его реализовать на более-менее любом употребимом языке программирования.
Одна из наших служб называется "служба свеже-социального поиска". Название такое сложилось исторически: когда-то давно в ней разрабатывалась поисковая свежесть и некоторые продукты, связанные с соцсетями.
С тех пор служба сильно выросла и занимается много чем ещё, но новое подходящее название мы придумать не смогли. Поэтому так и оставили её службой свеже-социального поиска :)
Внутри этой службы есть группа разработки свеже-социального поиска (а как же иначе?), которой руководит Никита и в которой по-прежнему сосредоточена разработка именно поисковой свежести и связанных с ней продуктов.
Я имею в виду, что к текущему моменту мы видели первые n элементов последовательности, и нам нужно получить ответ. Единственное, для чего нужно соображение о потенциальной бесконечности последовательностей — чтобы можно было спокойно говорить об обновлении статистик, т.е. о переходе то рассмотрения первых n элементов к рассмотрению первых (n+1) элементов, или (n+1000), или даже (n+k) :)
Вроде как в режиме черновика теперь приходится долго мотать вниз до кнопки "Редактировать", раньше она была прямо в тайтле статьи.
Еще раньше рядом с названиями глав была готовая ссылка, типа #4-some-thing, а теперь её нет, и приходится транслитерировать самостоятельно, ну либо делать якоря. Неудобно :(
Отличный пример, спасибо! Действительно, можно "сломать" метод, если разрядности не хватает для представления результата суммирования с нормированной разностью. В такой ситуации можно было бы использовать счётчик Кахана внутри метода Уэлфорда. Но я бы не стал рекомендовать такой способ в качестве стандартного, т.к. очень уж большие накладные расходы.
А какой метод используете вы в описанной ситуации?
Есть отличная статья про то, какие бывают классы метрик кластеризации, сами метрики и про критерии, которым эти метрики должны удовлетворять: http://nlp.uned.es/docs/amigo2007a.pdf
Таким образом, ответ: в день.
При этом с моей стороны было бы глупо отрицать толику маркетинга ;)
Ещё остаётся добавить, что это не всегда оправданно. По сути, выигрыш для пользователя здесь заключается в экономии сетевых хендшейков и прочего, что в каких-то случаях существенно — например, для саджеста, который должен откликаться на каждую новую букву,
или для поиска, от скорости получения результатов которого радикально зависит качество пользовательского взаимодействия. В других случаях выгоды от этого могут быть неочевидными.
Впрочем, в следующих статьях речь пойдет о менее отдаленных временах, поэтому качество картинок неминуемо улучшится :)
Старый код время от времени приходится удалять, поэтому восстановить состояние сервиса на произвольный момент времени в прошлом невозможно.
С точки зрения участника может быть несколько мотивов.
Ещё у этого соревнования есть особенность: задачи в нём некоторым образом связаны с теми задачами, которые приходится решать разработчикам Яндекса в повседневной жизни. Примеры таких связей мы постарались описать в статье. Это понимание может быть интересно и само по себе, и как способ понять, стоит ли пытаться устроиться на работу в Яндекс.
Мне кажется, что более-менее любое дополнительное знание способствует тому, что его носитель становится более восприимчив к новым идеям, быстрее учится и так далее, становится лучше, короче (впрочем, это мнение можно при желании оспорить).
В данном случае речь, конечно, не о каком-то магическом превосходстве знания алгоритмов над любыми другими знаниями. Тут намного более простая мысль: если вы разбираетесь в алгоритме, то сумеете относительно быстро его реализовать на более-менее любом употребимом языке программирования.
Всегда приятно, когда люди интересуются этой темой!
Привет :)
Одна из наших служб называется "служба свеже-социального поиска". Название такое сложилось исторически: когда-то давно в ней разрабатывалась поисковая свежесть и некоторые продукты, связанные с соцсетями.
С тех пор служба сильно выросла и занимается много чем ещё, но новое подходящее название мы придумать не смогли. Поэтому так и оставили её службой свеже-социального поиска :)
Внутри этой службы есть группа разработки свеже-социального поиска (а как же иначе?), которой руководит Никита и в которой по-прежнему сосредоточена разработка именно поисковой свежести и связанных с ней продуктов.
О поисковой свежести я писал вот тут: https://habrahabr.ru/company/yandex/blog/329946/, а потом рассказывал вот тут: https://events.yandex.ru/lib/talks/4690/
Я имею в виду, что к текущему моменту мы видели первые n элементов последовательности, и нам нужно получить ответ. Единственное, для чего нужно соображение о потенциальной бесконечности последовательностей — чтобы можно было спокойно говорить об обновлении статистик, т.е. о переходе то рассмотрения первых n элементов к рассмотрению первых (n+1) элементов, или (n+1000), или даже (n+k) :)
Вроде как в режиме черновика теперь приходится долго мотать вниз до кнопки "Редактировать", раньше она была прямо в тайтле статьи.
Еще раньше рядом с названиями глав была готовая ссылка, типа
#4-some-thing, а теперь её нет, и приходится транслитерировать самостоятельно, ну либо делать якоря. Неудобно :(Я вот об этом :) Вероятно, мешает моя привычка называть автора Каханом, а его алгоритм — счётчиком.
https://ru.wikipedia.org/wiki/Алгоритм_Кэхэна
По-моему, эту ситуацию обсуждали выше: https://habrahabr.ru/post/333426/#comment_10325964.
Спасибо, исправил ссылку!
Отличный пример, спасибо! Действительно, можно "сломать" метод, если разрядности не хватает для представления результата суммирования с нормированной разностью. В такой ситуации можно было бы использовать счётчик Кахана внутри метода Уэлфорда. Но я бы не стал рекомендовать такой способ в качестве стандартного, т.к. очень уж большие накладные расходы.
А какой метод используете вы в описанной ситуации?
Есть отличная статья про то, какие бывают классы метрик кластеризации, сами метрики и про критерии, которым эти метрики должны удовлетворять: http://nlp.uned.es/docs/amigo2007a.pdf