Comments 35
UFO just landed and posted this here
Одноклассники — первая социальная сеть по просмотрам видео в рунете — 350 млн в сутки, а общая длительность просмотров увеличилась на 63%. Одним из важнейших запусков прошлого года стало приложение OK Live, которое стало популярным не только в России, но и в США, Германии, Украине, Турции и странах СНГ. Каждые сутки в приложении создается 40 тысяч новых трансляций, которые набирают 4 млн просмотров.
Источник:
Бизнес-завтрак Одноклассников, февраль 2017
Источник:
Бизнес-завтрак Одноклассников, февраль 2017
Святая простота. Кто-то что-то взял… где-то попробовал, оно зачем-то до сих пор работает. Где-то… Короче, хорошее хранилище.
Если внимательно прочитать текст, то видно, что речь шла о конкретно версии 1.2. а так — хранилище неплохое, широко используются версии 0.6 и 2.0 ( сильно перепиленные для того чтобы работало хорошо ), общее число порядка 1000 нод ( в разных кластерах ).
Интересно сравнение Cassandra с HBase. Идеолгоически-то они очень похожи, а вот как они отличаются на серьзных нагрузках — интересно.
Идеологически оба как раз разные. hbase работает по модели single-master. То есть в каждый момент времени есть 1 нода, овечающая за каждый регион ключей ( она так и называется — region master). Соотвественно при потере этой нода начинает происходить failover. Во время failover данные региона невозможно ни читать ни писать.
Кассандра же работает по masterless quorum — то есть за «регион» в простейшем случае отвечают не менее 3 нод. При этом запись считается успешной, если большинство нод подтвердит запись. Соответственно, выход из строя одной ноды никак не влияет на работоспособность системы — может и принимать запись и читать. А при использовании спекулятивного ретрая — и на скорость работы системы не влияет.
Кассандра же работает по masterless quorum — то есть за «регион» в простейшем случае отвечают не менее 3 нод. При этом запись считается успешной, если большинство нод подтвердит запись. Соответственно, выход из строя одной ноды никак не влияет на работоспособность системы — может и принимать запись и читать. А при использовании спекулятивного ретрая — и на скорость работы системы не влияет.
Эта часть — да. Но модель данных у них очень похожа (Row -> Colum Family->Column) и хранение в файлах тоже (с поправкой на разный подход к разбиению на регионы). Лично мне интересно как они сравниваются на 50/50 чтении и записи.
Вы про скорость и все такое? Я не большой поклонник бенчмарков и т.п. — они все лгут ( тут картинка с Мюллером ;-) ), да и вас-то интересует не то, как быстро та или иная система выполяют высосанный из пальца бенч, а как та и другая работают с вашей конкретной задачей.
Поэтому лучше сделать тест для своей задачи с реальными данными и сравнить самому как они быстро работают на важных для задачи кейсах.
Поэтому лучше сделать тест для своей задачи с реальными данными и сравнить самому как они быстро работают на важных для задачи кейсах.
Это правда, просто имея бенчмарки по крайней мере можно как-то сверяться. У своего бенчмарка проблема в том, что не зная системы и каких показателей ожидать можно получить недостоверные данные и не заметить этого.
Ой, я не заметил что Вы — человек из статьи :) Мне очень интересно узнать про ваш собственный координатор транзакций поверх Cassandra. Нет ли в про него статей/записанных выступлений? Например, интересно как в случае недоступности одной из 3 реплик она (реплика) потом «нагоняет» остальные две? Как она вводится в строй, учитывая что нагрузка есть постоянно? Как происходит fail-over нод транзакционного менеджера?
есть вот тут За гранью NoSQL: NewSQL на Cassandra
Cassandra сравнима разве что с Riak и DynamoDB. А HBase по CAP это CP система, такие системы проигрывают AP системам по доступности, latency, и, соответственно, производительности, просто потому, что обязаны ждать консенсуса по каждой операции.
— Сейчас в индустрии понятие «архитектор» означает некоего человека с огромной головой, который всё всегда знает наперёд, естественно, давно отошедшего от дел и уже не марающего руки кодом. Его задача — раздавать указания тем, кто ещё не дорос до архитектора, максимум — рисовать квадратики, соединять их стрелочками. Как строительный архитектор, который рисует, но ничего сам не делает.
Мне запомнились слова тур гида на острове Крит:
Все считают архитекторов белыми воротничками в глянцевом офисе. На нашем острове пыльный архитектор в грязных сапогах носится по стройке, проверяет состав глины, качество блоков, контролирует всё. Потому что если дом по его проекту разрушится от землетрясения (землетрясения там часто бывают), когда соседские всё ещё останутся стоять — он больше заказов не получит. Карьере конец.
начало взял от мартина фовлера
не брал я ни у кого ни начало, ни середину, ни конец. А Мартин вообще по русски не умеет ;-)
Спасибо за ссылку на видео. Добавлю ссылку на статью, упомянутую в нем (опубликованную в 2003 году).
Еще есть неплохое рассуждение об архитекторах в книге Сэма Ньюмена «Создание микросервисов». Фрагмент:
Так что это может быть мнение разработчика с хорошим опытом, чувством здравого смысла, ценящего ROI и разницу между профессиональным и чисто карьерным ростом.
Мне приходилось работать в команде с архитекторами, которые адекватно понимали свою роль и обязанности, активно принимая участие в разработке — трудно было переоценить их вклад в общий результат. К сожалению был и противоположный опыт, хорошо описанный в этом видео.
Еще есть неплохое рассуждение об архитекторах в книге Сэма Ньюмена «Создание микросервисов». Фрагмент:
Нужно признать, что после того как большинство создаваемых нами продуктов попадают к потребителям, мы вынуждены реагировать на все замечания последних и подстраивать продукты под них, поэтому нашу продукцию нельзя признать незыблемым творением искусства. Следовательно, архитекторам нужно избавиться от мысли о создании совершенного конечного продукта, а вместо этого сфокусироваться на содействии созданию программной структуры, в которой могут появляться подходящие системы, способные расти по мере более глубокого осмысления стоящих перед нами задач.
Так что это может быть мнение разработчика с хорошим опытом, чувством здравого смысла, ценящего ROI и разницу между профессиональным и чисто карьерным ростом.
Мне приходилось работать в команде с архитекторами, которые адекватно понимали свою роль и обязанности, активно принимая участие в разработке — трудно было переоценить их вклад в общий результат. К сожалению был и противоположный опыт, хорошо описанный в этом видео.
спасибо, было очень интересно.
То есть выяснилось, что объём работы совершенно колоссальный. И если четыре года назад, когда Андрей начинал рассказывать про one-nio, зацепиться за это и начать делать из этого OpenSource, наверное, имело бы смысл, то сейчас подобных решений на рынке появилось довольно много и, пожалуй, этот момент уже упущен.
Например каких решений?
на OffHeap уже много кто много что делает.
Эти много кто это обычно closed-world фреймворки, поэтому что раньше, что сейчас это несколько ортогонально к тому off-heap который дает one-nio. Я думал про сетевой стек и сериализацию. То есть какие-нибудь netty и protobuf/jackson. Ну, пожалуй они не стояли на месте 4 года, да.
one-nio тоже не стоял на месте, но, конечно, развивался не так активно, как ведущие опенсорс-конкуренты.
Ром, ты же хорошо этот рынок знаешь. Как думаешь, имеет смысл сейчас им заниматься в плане маркетинга и опенорса или поезд уже уехал?
Ром, ты же хорошо этот рынок знаешь. Как думаешь, имеет смысл сейчас им заниматься в плане маркетинга и опенорса или поезд уже уехал?
Глобальный open-source это рынок брендов. С Гуглом, Фейсбуком, Эпплом и Нетфликсом тягаться бесполезно.
Для русской аудитории, мне кажется, более чем есть смысл сделать доклад, где рассказать с техническими деталями, чем, допустим, HTTP-сервер из one-nio хорош и как его применить. Или какой-то другой компонент разобрать.
Скажите это то человек благодаря которому Одноклассники постоянно глючат? Плохая реклама.
Какой-то странный когнитивный диссонанс возник по ходу рассказа. С одной стороны m0nstermind говорит, что они очень внимательно относятся к распределению знаний между людьми для исключения фактора трамвая, а с другой — выясняется, что тот-же one-nio нормально знает только apangin и для толкового документирования этой библиотеки нужно очень серёзно отвлекать автора. И тут же вопрос:"А зачем нам тратиться на оформления OpenSourse проекта?"
Не знаю как на счёт конкретно OpenSourse, но в целом подобного рода работа даже просто на уровне компании как раз и гарантирует качественное распределение знаний между сотрудниками. Т.к. если сторонний человек таки написал, например, документацию к проекту и у автора библиотеки не возникло к итоговому варианту претензий, то это значит что человек уже разобрался в проекте достаточно хорошо. Да автора отвлекать придётся. Но как ещё знания-то передавать?
А если ещё и по коду прилизать что-то корректно смог, то по поводу трамвая уже можно не так сильно париться :-)
А вот уже от OpenSourse можно получить бонус в другом плане: при поиске специалистов для найма. Если человек воспользовался библиотекой такого уровня в своём проекте и сделал это корректно, то он уже может являться хорошим кандидатом для привлечения в компанию. Возможно выхлоп от такого подхода будет ничуть не хуже, чем от организации конференций ;-)
P.S. Всё это чисто мои умозаключения. Возможно ложные.
P.P.S. Надеюсь не очень путано изложил свои мысли.
и m0nstermind не врет, собака ;-). Знания передаются отлично — вот скриншот коммитов в one-nio репу как он виден на внутренней репе ( замазал фамилии людей, которые не apangin и m0nstermind, а то вдруг обидятся ). OpenSource тут как раз вообще не при чем.
Но основная проблема в том, что OpenSource проект нужно продавать и рекламировать, а хорошие евангелисты (те которые доки делают, примеры и ездят по конфам ) так же редки как хорошие программисты, которые понимают в one-nio. А чтобы сразу и то и другое — то это вообще редкий фрукт. Поэтому, либо из хорошего программиста делать маркетолога/евангелиста, либо из маркетолога — программиста. Оба пути как вы понимаете имеют свои минусы ;-) В это имеет смысл вкладываться, если у вас бизнес вокруг этого построен — как у Spring, Cassandra, etc.
Как это влияет ( и влияет ли ) на найм, эффективнее ли это конференций — мне сложно судить. На ум приходит только пример с Disruptor — один их нишевых hpc проектов, чем-то похожий на one-nio, только значительно сильнее распиаренный. Готовы ли вы взять тех, кто его использует на работу делать высокочастотный трейдинг?
Возможно кто-то, у кого был и тот и другой опыт и может сравнить оба подхода и напишет свое мнение? Думаю всем было бы интересно.
Но основная проблема в том, что OpenSource проект нужно продавать и рекламировать, а хорошие евангелисты (те которые доки делают, примеры и ездят по конфам ) так же редки как хорошие программисты, которые понимают в one-nio. А чтобы сразу и то и другое — то это вообще редкий фрукт. Поэтому, либо из хорошего программиста делать маркетолога/евангелиста, либо из маркетолога — программиста. Оба пути как вы понимаете имеют свои минусы ;-) В это имеет смысл вкладываться, если у вас бизнес вокруг этого построен — как у Spring, Cassandra, etc.
Как это влияет ( и влияет ли ) на найм, эффективнее ли это конференций — мне сложно судить. На ум приходит только пример с Disruptor — один их нишевых hpc проектов, чем-то похожий на one-nio, только значительно сильнее распиаренный. Готовы ли вы взять тех, кто его использует на работу делать высокочастотный трейдинг?
Возможно кто-то, у кого был и тот и другой опыт и может сравнить оба подхода и напишет свое мнение? Думаю всем было бы интересно.
Пиар по большому счету Disruptor'у был не нужен. Как только Мартин упомянул его в своем блоге, все заинтересованные лица скачали исходники, прочитали, протащились и начали использовать :) То что в последующие годы доклады (не Мартина) по нему появились на рускоязычных конфах это скорее желание «докладчиков» использовать «халявный корм» — придумывать то ничего не надо — берешь и рассказываешь (хотя это тоже работа не спорю)…
Так что нет смысла слишком «опекать» one-nio — достаточно его упомянуть в блоге, в интервью или на конфе и все кому интересно скачают, прочитают, возможно (не) оценят и возможно (не) используют.
А пиар пошел дизраптору во вред… Сравните исходники первой версии и третьей…
Так что нет смысла слишком «опекать» one-nio — достаточно его упомянуть в блоге, в интервью или на конфе и все кому интересно скачают, прочитают, возможно (не) оценят и возможно (не) используют.
А пиар пошел дизраптору во вред… Сравните исходники первой версии и третьей…
Вы очень грамотно и по делу написали, спасибо. У вас очень правильные вопросы. Попробую ответить по порядку.
Как всегда, глубже всех код понимает его автор. И one-nio — не исключение. Коллеги тоже понимают, но наверное не настолько супер-супер детально. Это совешенно нормальная ситуация для любого кода.
Снова все правильно пишете. В долгосрочной перспективе компания заинтересована в том, чтобы код важной библиотеки знало как можно больше людей. Поэтому, в том числе, используется принцип, что человек не просит Андрея пофиксить библиотеку, а предлагает патч. И уже дальше с Андреем обсуждает, как этот патч сделать, чего этот патч стоит с точки зрения совместимости, перфоманса и т.п. Таким образом, знания шарятся внутри компании.
И снова классный вопрос. Ответ будет такой: тут экономику довольно сложно считать, потому что речь идет о довольно нишевом инструменте, и вопрос я бы ставил так: не будет ли вся эта деятельность по опенсорсу оверкиллом? Возможно, проше нанять толкового компетентного специалиста, который не знает конкретного фреймворка, но будет (за счет собственных компетенций) в состоянии разобраться с ним. Учитывая, что фреймворков становится все больше и больше, мне этот подход нынче видится более правильным — искать умного и способного разобраться вместо того, чтобы искать того, кто уже и сразу умеет то, что нужно. Потому, что подход с умным — более универсальный, чем подход со знающим конкретный тул. Он банально позволяет не зависить от тула.
Какой-то странный когнитивный диссонанс возник по ходу рассказа. С одной стороны m0nstermind говорит, что они очень внимательно относятся к распределению знаний между людьми для исключения фактора трамвая, а с другой — выясняется, что тот-же one-nio нормально знает только apangin и для толкового документирования этой библиотеки нужно очень серёзно отвлекать автора. И тут же вопрос:«А зачем нам тратиться на оформления OpenSourse проекта?»
Как всегда, глубже всех код понимает его автор. И one-nio — не исключение. Коллеги тоже понимают, но наверное не настолько супер-супер детально. Это совешенно нормальная ситуация для любого кода.
Не знаю как на счёт конкретно OpenSourse, но в целом подобного рода работа даже просто на уровне компании как раз и гарантирует качественное распределение знаний между сотрудниками. Т.к. если сторонний человек таки написал, например, документацию к проекту и у автора библиотеки не возникло к итоговому варианту претензий, то это значит что человек уже разобрался в проекте достаточно хорошо. Да автора отвлекать придётся. Но как ещё знания-то передавать?
Снова все правильно пишете. В долгосрочной перспективе компания заинтересована в том, чтобы код важной библиотеки знало как можно больше людей. Поэтому, в том числе, используется принцип, что человек не просит Андрея пофиксить библиотеку, а предлагает патч. И уже дальше с Андреем обсуждает, как этот патч сделать, чего этот патч стоит с точки зрения совместимости, перфоманса и т.п. Таким образом, знания шарятся внутри компании.
А вот уже от OpenSourse можно получить бонус в другом плане: при поиске специалистов для найма. Если человек воспользовался библиотекой такого уровня в своём проекте и сделал это корректно, то он уже может являться хорошим кандидатом для привлечения в компанию. Возможно выхлоп от такого подхода будет ничуть не хуже, чем от организации конференций ;-)
И снова классный вопрос. Ответ будет такой: тут экономику довольно сложно считать, потому что речь идет о довольно нишевом инструменте, и вопрос я бы ставил так: не будет ли вся эта деятельность по опенсорсу оверкиллом? Возможно, проше нанять толкового компетентного специалиста, который не знает конкретного фреймворка, но будет (за счет собственных компетенций) в состоянии разобраться с ним. Учитывая, что фреймворков становится все больше и больше, мне этот подход нынче видится более правильным — искать умного и способного разобраться вместо того, чтобы искать того, кто уже и сразу умеет то, что нужно. Потому, что подход с умным — более универсальный, чем подход со знающим конкретный тул. Он банально позволяет не зависить от тула.
Sign up to leave a comment.
«Сложную архитектуру очень просто сделать» — интервью с Олегом Анастасьевым из Одноклассников