на чем написан twitter
Советы по Twitter для чайников: то, что мне стоило бы знать, когда я начинал
Еще три недели назад мой аккаунт в Twitter был практически заброшен.
Он существовал в гордом одиночестве в течение нескольких лет в качестве отвлечения от работы, когда последняя позволяла мне найти время на то, чтобы постить твиты. И вот, три недели назад этот день настал, и я бросился в омут с головой, применяя все знания о Twitter, которые были в моем арсенале. И даже несмотря на то, что я взял хороший разбег на старте, мне нужно было еще многому научиться.
Знания редко заменяют опыт. Так что пока я кое-как экспериментировал и всячески химичил, пытаясь разобраться в Twitter в течение моих первых нескольких недель общения с сервисом, я заметил, что многим вещам можно научиться только на практике. В этой статье я расскажу о самых главных из них. Итак, встречайте: полезные советы по Twitter для чайников.
1. Вы не обязаны читать каждый твит.
Если у вас 100 последователей, то ежедневно они постят порядка 2200 твитов.
500 последователей = 10 тыс. твитов ежедневно.
1000 последователей = 22 тыс. твитов ежедневно.
Иными словами, так как длина твитов составляет в среднем 30 символов, то человек с 1000 последователей будет в течение дня видеть столько контента, что по размеру он мог бы в четыре раза превзойти «Скотный Двор» Джорджа Оруэлла*.
Вы не обязаны читать каждый твит. Вместо этого…
2. Занесите любимых пользователей в отдельный список.
К счастью я открыл для себя списки.
Для меня главным преимуществом списков является то, что я вижу наиболее важный и оригинальный контент от избранных групп пользователей. Здесь нет проспонсированного контента. По сути, мы имеем дело с эдаким минималистическим вариантом Twitter.
Мои интересы весьма разнообразны, так что я создаю разные списки. У меня есть список для маркетинга в цифровой сфере, для New England Patriots и многие другие списки. Это хорошая альтернатива прочесыванию всей ленты.
3. Всегда отвечайте всем и на всё.
Когда люди ретвитят ваши твиты, упоминают вас в своих постах или добавляют ваши записи в избранное, они ищут связи с вами. В какой-то мере это можно даже назвать почетным. Кто-то оценил ваш профиль столь высоко, что захотел связаться с вами – это своего рода честь.
Один из наиболее популярных брендов на Twitter – аккаунт @notebook – уделяет огромное внимание ответам пользователям.
«Независимо от того, управляете ли вы таким международным брендом как Nike или местным продуктовым магазинчиком, очень важно выражать благодарность каждому вашему подписчику, который задает вопрос, делает вам комплимент или обращается с проблемой. Одни ответят вам, а другие сделают ретвиты вашего ответа, потому что они хотели бы показать своим друзьям, что вы с ними общаетесь».
4. Используйте приложение-планировщик наподобие Buffer.
Здесь нам на помощь приходят инструменты для работы с соцсетями. С помощью Buffer я могу выбирать хороший контент, которым хочу поделиться (в том числе и ретвиты), и добавлять его в очередь, благодаря которой можно разделить контент на порции для публикации в течение всего дня в наиболее подходящее время. Я могу контролировать этот процесс так, как сам пожелаю, и позднее я могу следить за статистикой того, какие из твитов были наиболее популярны.
5. Правильно подавайте информацию о себе.
По умолчанию мне всегда хочется написать о себе что-нибудь оригинальное. Мне нравятся странички пользователей в Twitter, которые заставляют смеяться. Но то, что кажется остроумным для меня, может не являться таковым для кого-то еще. Так что вместо смешной биографии мне пришлось написать что-то более информативное, оставив в стороне свое творческое эго.
6. Общайтесь напрямую с другими.
«Когда вы найдете общий язык с другими людьми и начнете общаться с ними, вы сразу же обзаведетесь друзьями в Twitter, и это сделает ваш опыт работы с сервисом еще более приятным».
Самым лучшим для меня методом в этом плане является собственное сочинение твитов. Каждый раз, когда я даю ссылку на новый контент или делюсь какой-либо информацией, полученной от кого-то еще, я упоминаю автора (используя стандартный символ @) или составителя, или «HT» (или hat tip, что в данном контексте можно перевести как благодарность «за наводку» другому пользователю – прим. переводчика). Другими словами, я отдаю должное там, где нужно. Очень часто люди это ценят.
Оказывается, что я не знал первого правила написания твитов: если вы хотите, чтобы каждый видел ваш твит, не начинайте его с символа @.
Twitter расценивает такие твиты (и в большинстве случаев это верно) как приватные, адресованные конкретному пользователю. Только пользователь, опубликовавший твит, адресат, а также последователи обоих аккаунтов смогут увидеть подобные посты в своих лентах.
Эта информация сильно повлияла на мое поведение. Я нервничал, публикуя твиты с @-ответами другим пользователям, так как я не хотел заполнять ленты своих последователей твитами, которые могли бы быть для них неинтересны. Зная, что такие твиты находятся в стороне от основного потока, я чувствовал себя куда более комфортно.
7. Постить одно и то же не зазорно.
Белль Бет Купер (Belle Beth Cooper) написала отличную статью, развенчав все мифы по поводу репостов одного и того же контента. Она подает три основные причины, почему стоит это делать:
Знание того, что в повторной публикации одного и того же контента нет ничего зазорного, снимает напряжение при отборе контента для постов. Если я нашел классную ссылку, то мне не стоит переживать, что я уже твитил ее. Репостинг тоже может быть отличной штукой!
8. Забудьте о соотношении Following / Followers и просто подписывайтесь на стоящие аккаунты.
Каким бы не было идеальное соотношение, для себя я открыл, что погоня за ним не приносит никакой пользы в самом начале жизни аккаунта.
Я присоединился к Twitter, чтобы находить новых людей, что я и делал.
Моим камнем преткновения было то, что мне не давало покоя соотношение Following / Followers в аккаунтах топ-пользователей Twitter. Часть меня хотела, чтобы у меня было такое же крутое соотношение, говорящее о том, что у меня многотысячная армия подписчиков, в то время как сам я являюсь подписчиком только горстки аккаунтов. Для того, кто только присоединился к Twitter, это было довольно эгоистично.
Идеальное соотношение может и подождать. Тем временем я принял за правило становиться подписчиком тех, кто подписался на получение обновлений моего аккаунта.
Избирательность может негативно отразиться на вашем росте. В соответствии с данными KissMetrics, самый быстрый путь набрать подписчиков – это стать подписчиком как можно большего числа аккаунтов.
Такой метод добавляет индивидуальный подход вне зависимости от вашей популярности в Twitter. Он показывает, что вы заметили появление нового последователя и уделили время тому, чтобы стать его подписчиком.
Правда в том, что наилучшее соотношение Following/ Followers действительно существует, сокрытое в тайных глубинах алгоритмов Twitter. Когда вы становитесь подписчиком 2000 аккаунтов, вы не сможете продолжать подписываться на новые, если ваше соотношение не удовлетворяет определенным требованиям. Я еще далек от цифры в 2000, но, когда я буду приближаться к этому числу, такие инструменты как Followerwonk окажутся суперполезными.
Напоследок, самый лучший совет, который я слышал в Twitter.
«Не пиши о себе, пиши о них».
А какой совет хотели бы получить вы в самом начале своего общения с сервисом?
* Официальная математика: 22000 твитов по 30 символов в каждом = 660 000 символов ежедневно. Учитывая средний показатель в 5 букв на слово, 660 000 букв – это 132 000 слов. «Ферма животных» насчитывает около 30 000 слов.
На каком языке пишутся сложные сайты?
Здравствуйте, хотелось бы начать изучать языки для создания веб-сайтов, но не обычных, простеньких, а сложных, например: vk.com, imhonet, youtube. На каких языках подобные сайты пишутся? Что нужно вообще знать для написания подобных проектов?
P.S. Я понимаю, что сразу не напишу такие сайты и я готов тратить время на обучение, поэтому жду серьезных ответов.
Оценить 1 комментарий
Их не пишут, нельзя вот так вот взять и написать yotube.
Во первых не стоит называть такие проекты сайтами. Сайт это просто аккуратно оформленная страничка с данными доступная по протоколу http.
Т.е вордовский документ размещенный в сети интернет это и есть сайт.
Давайте не будем столь категоричны. Известно что вк и фейсбук изначально небыли сложными, программно аппаратными комплексами. У них просто не было на все это денег.
Оба они начинались с самого банального PHP, несмотря на что этот язык всегда в «догоняющих», он остается самим популярным для сайтов и веб стартапов. Низкий уровень вхождения, рождает тучу фанатов, что рождает предложение и удовлетворяет спрос.
Далее, конечно для вк и фб было мало пхп, и начались переделки. Не скажу за сегодня, но последний раз когда слышал об этом.
— для фб написана собственная база данных на С(не вспомню каких именно), и по сути, вся нагрузка лежит на этой базе.
— для вк они разработали собственный язык программирования, FastPHP, где от php остались только названия функций. В тоже время, у них еще есть Jabber сервер, это то где все ваши сообщения, обновления стены и прочее, этот сервер написан на Node.js.
Как видите, «крутые» ресурсы, так или иначе используют легендарную сишку, для разработки собственных инструментов.
Можно также вспомнить и ноду, запущенную на вк, как видим она справляется, возможно она подходит для таких проектов, но это уже темы для целой статьи.
140 миллионов твитов в день: как работает Twitter изнутри?
Содержание статьи
Сервис, предлагающий делиться микросообщениями, ввел новый термин в языки всех стран мира, изменил образ жизни активной аудитории интернета и стал принципиально новым источником информации для миллионов людей. У разработчиков на это ушло 5 лет.
Что такое твит? Это сообщение длиной до 140 символов с возможность @ссылки на пользователя и указания темы с помощью #хэш-тега. Человек публикует твиты в своем Twitter-аккаунте — их читают его подписчики (они же — follower’ы). С точки зрения архитектуры сервиса все просто и примитивно, а рабочий прототип аналогичного ресурса можно написать за час-другой, но… только если у тебя не 175 000 000 пользователей.
Twitter стартовал как небольшой побочный проект научно-исследовательской компании Odeo, но темпы его роста оказались ошеломительными. Путь от нуля до миллионов просмотров страниц занял всего несколько коротких месяцев. Ранние решения о проектировании системы неплохо справлялись с небольшими нагрузками, но они начали быстро сдавать позиции под напором огромного количества пользователей, желающих разослать всем своим друзьям весточки с ответом на простой вопрос «Чем ты занимаешься?». 140 000 000 — столько сообщений в среднем отправляют пользователи Twitter каждый день. И сервис хорошо выдерживает такую нагрузку.
Любопытная статистика
3 года, 2 месяца и 1 день потребовалось Twitter, чтобы набрать миллиард твитов. Сегодня для этого пользователям нужна всего одна неделя.
460 000 аккаунтов в среднем создается каждый день.
6 939 твитов составляет рекордный показатель TPS (твитов в секунду), поставленный через 4 секунды после наступления Нового года в Японии.
Обработка запросов пользователей
Активная аудитория Twitter генерирует неимоверное количество запросов через веб-страницы и программный интерфейс, который используют для своей работы все приложения-клиенты (как для десктопных, так и для мобильных ОС). Любопытно, что лишь 25% трафика приходится на веб-сайт, остальное идет через API. Это легко объяснить: только за последний год рост числа мобильных пользователей, которые активно твиттерят, составил 182%. Статистика впечатляет: 6 000 000 000 запросов к API в день, около 70 000 в секунду! Так как оба способа взаимодействия с сервисом основаны на HTTP, методы их обработки практически идентичны. Для генерации страниц используется в основном известный фреймворк Ruby on Rails, притом практически вся работа «за сценой» реализована на чистом Ruby или Scala. Многие говорят, что Ruby on Rails — далеко не самый производительный фреймворк, на что представители Twitter отвечают, что использование более быстрого решения позволило бы выиграть 10-20% в производительности, но благодаря RoR на ранних стадиях проекта был быстро реализован механизм горизонтального масштабирования. Последний позволил легко подключать новые сервера к системе без изменения кода и, как следствие, достичь роста производительности системы на несколько порядков. Сейчас проект использует более тысячи серверов, которые расположены в NTT America, однако планируется переезд в собственный датацентр. От «облаков» и виртуализации разработчики отказались с самого начала: существующие решения страдают слишком высокими задержками, особенно при доступе к дисковой подсистеме.
В роли балансировщика нагрузки используется привычный Apache httpd, но с учетом основного инструмента разработки, для обработки самих запросов необходим сервер приложений для Ruby. Для этого используется Unicorn, который имеет массу положительных сторон — например, развертывание новых версий кода без простоя, более низкое (до 30% меньше) потребление вычислительных ресурсов и оперативной памяти по сравнению с другими решениями. Связка «Apache + Unicorn» хорошо работала в начале. Но по мере развития проекта начали всплывать и серьезные недостатки решения: в подсистеме кэширования стали наблюдаться проблемы с инвалидацией (удалением устаревших данных), а ActiveRecord, автоматический генератор SQL-запросов в Ruby, как оказалось, использует не самые удачные варианты, что непременно замедляет время отклика и приводит к высоким задержкам в очереди и при репликации. Эти проблемы пришлось решать.
Архитектура средств для обработки запросов
Кэширование
При таком потоке входящих запросов очень важно всеми доступными способами снижать нагрузку на прослойку базы данных, иначе расходы на приобретение нового оборудования начнут зашкаливать. Наиболее распространенным решением в этой области является кэширование сериализованных объектов и значений, полученных ранее из базы данных или от пользователя. Они хранятся в специализированном сервисе, представляющем собой распределенную хэш-таблицу в оперативной памяти с примитивным протоколом доступа (по сути, есть два элементарных действия: «взять» и «положить»). Самым популярным решением в этой области является memcached, который заслужил доверие благодаря своей универсальности и чрезвычайно высокой производительности. Впрочем, даже тот факт, что инструмент используется практически в каждом высоконагруженном проекте, вовсе не означает, что он идеален. Вот и Twitter, используя чистый memcached, очень рано начал сталкиваться с ошибками Segmentation Fault (сбой при обращении к недоступным для программы участкам памяти). Более того, большинство стратегий кэширования основывается на длинных TTL (более минуты), а вытеснение информации делает его непригодным для хранения важных конфигурационных данных. Поэтому кэширующие сервера пришлось распределять на несколько групп для улучшения производительности и снижения риска вытеснения данных. Не обошлось без собственных доработок. В Twitter используется оптимизированная библиотека для доступа к memcached из Ruby на основе libmemcached и алгоритма хэширования FNV вместо чистого Ruby и md5.
Хранение данных
На сегодняшний день в Twitter используется множество различных систем хранения данных, у каждой из которых есть свои слабые и сильные стороны. В разных частях проекта применяется соответствующее поставленным задачам решение. Изначально для постоянного хранения твитов и других данных использовалась MySQL. Но на практике оказалось, что данные социальных сетей плохо подходят для хранения в реляционных СУБД. Этому есть немало причин: отношение «многие ко многим», сложность социального графа, необходимость обхода деревьев. Фактически использование привычных СУБД выливается в проблемы с дисковой подсистемой. Решением этих проблем стало использование FlockDB — масштабируемого хранилища для данных социального графа, построенного поверх множества серверов MySQL. Разбиение данных берет на себя сервис под названием Gizzard. Ребра графа хранятся и индексируются в обоих направлениях, помимо этого производится распределенный подсчет количества строк.
Приведу немного цифр. В базах Twitter’а содержится более 13 000 000 000 ребер графа, при этом осуществляется 20 000 операций записи и 100 000 операций чтения в секунду. Среднее время на выполнение операций в FlockDB достаточно низкое:
Ранее в Twitter’е планировали для хранения всех твитов постепенно перейти на другой проект, а именно Cassandra. Решение изначально был разработано в Facebook как распределенная система хранения данных, ориентированная на работу в реальном времени. Ее основная отличительная особенность — невероятно высокая производительность на запись, но за это пришлось заплатить высокими задержками при случайном доступе к данным. Так как система децентрализована, сбои в оборудовании переносятся практически незаметно. Однако переход на Cassandra в Twitter не состоялся: стратегия по этому вопросу изменилась. Попытки использовать ее в роли основного хранилища для твитов прекратились, но она продолжает использоваться для составления аналитики в реальном времени.
Кластеры внутри Twitter
Пользователи Twitter генерируют огромное количество данных: около 15-25 Гб в минуту, то есть более 12 Тб в день. Цифра удваивается несколько раз в год. Если считать, что средняя скорость записи современного жесткого диска составляет 80 Мб в секунду, запись 12 Тб данных заняла бы почти 48 часов. На одном даже очень большом сервере данную задачу не решить. Логичным выходом стало использование кластера для хранения и анализа таких объемов данных. Подходящим решением в этой сфере оказался свободный Java-фреймворк Apache Hadoop для выполнения распределенных приложений, работающих на больших кластерах, построенных на обычном оборудовании. Hadoop прозрачно предоставляет приложениям надежность и быстродействие операций с данными. В проекте реализована вычислительная парадигма, известная как MapReduce. Согласно этой парадигме, приложение разделяется на большое количество небольших заданий, каждое из которых может быть выполнено на любом из узлов кластера. В дополнение предоставляется распределенная файловая система HDFS (Hadoop Distributed File System), использующая для хранения данных вычислительные узлы кластера, что позволяет достичь очень высокой агрегированной пропускной способности кластера. Эта система позволяет приложениям легко масштабироваться до уровня тысяч узлов и петабайт данных. Источником вдохновения для разработчиков Hadoop послужили материалы по Google File System (GFS).
Другими словами, HDFS занимается автоматической репликацией и помогает справляться со сбоями оборудования, а MapReduce позволяет обрабатывать огромные объемы данных, анализируя пары ключ-значение с помощью разработки специального кода на Java. Типичные вычислительные задачи, которые решаются с помощью Hadoop в Twitter: вычисление связей дружбы в социальном графе, подсчет статистики (количество пользователей и твитов, например подсчет количества твитов занимает 5 минут при 12 000 000 000 записей), подсчет PageRank между пользователями для вычисления репутации.
Чтобы анализировать данные с помощью MapReduce, обычно необходимо разрабатывать код на Java, что довольно трудоемко. Поэтому для упрощения обработки больших объемов данных обычно разрабатываются специализированные системы, доступные людям и без навыков программирования. Так, в Twitter используют Pig, как раз один из такого рода продуктов, предназначенный для работы с данными в Hadoop. Он представляет собой высокоуровневый язык, позволяющий трансформировать огромные наборы данных шаг за шагом. Синтаксис немного напоминает SQL, но гораздо проще, что позволяет писать в 20 раз меньше кода, чем при анализе данных с помощью обычных MapReduce-работ. Большая часть действий по анализу данных в Twitter осуществляется именно с помощью Pig. Вообще на основе Hadoop в Twitter начинают строить ряд сервисов — например, поиск людей. Для этого используется opensource распределенная система хранения данных HBase, построенная по подобию основной базы данных в Google — BigTable. По сути, она представляет собой изменяемую прослойку над HDFS, позволяющую осуществлять доступ к данным в структурированном виде. В отличие от традиционных СУБД, данные хранятся по столбцам, а не по строкам, а также для всех ячеек хранится история, то есть возможность получить данные на какой-то момент времени в прошлом, даже если они были перезаписаны.
Внутренние подпроекты Twitter
В крупных интернет-компаниях часто находятся задачи, которые не удается решить средствами готовых opensource или даже платных решений. В таких ситуациях небольшая часть команды проекта начинает разработку собственной подсистемы для решения возникшей задачи: зачастую она идет вразрез с общей платформой из-за своей специфики. С течением времени такие подпроекты становятся все более обособленными и в какой-то момент команда решает, что продукт стал достаточно зрелым, универсальным и независимым, чтобы опубликовать его как opensource. Cassandra и Scribe, например, в свое время полностью прошли этот путь в Facebook, а на сегодняшний день используются и в Twitter.
В самом Twitter ведется работа над несколькими собственными инструментами, которые, правда, еще не успели полноценно «встать на ноги» в качестве отдельных продуктов:
Обработка статистических данных
Еще один важный тип данных — это различного рода журналы, которые необходимо не просто ввести, но еще и анализировать. Изначально для сбора логов использовали привычное для этих целей решение syslog-ng, но оно очень быстро перестало справляться с нагрузкой. Решение нашлось очень просто: программисты Facebook, столкнувшиеся с аналогичной задачей, разработали проект Scribe, который был опубликован в opensource и позже был взят на вооружение в Twitter. По сути это фреймворк для сбора и агрегации логов. Ты пишешь текст для логов и указываешь категорию записи — остальное инструмент берет на себя. Scribe работает локально и надежен даже в случае потери сетевого соединения. Каждый используемый узел знает только, на какой сервер передавать логи, что позволяет создавать масштабируемую иерархическую систему для сбора логов. Поддерживаются различные схемы для записи данных, в том числе обычные файлы и HDFS (к этой файловой системе мы вернемся ниже). Этот продукт полностью решил проблему Twitter со сбором логов, позволив логически разбить поток информации на примерно 30 категорий. В процессе использования программисты активно сотрудничали с командой Facebook, была создана и опубликована масса доработок.
Как они справляются с такими темпами роста?
Хороший вопрос. Рецепт от Twitter довольно прозаичен, но зато эффективен и подходит практически для любого интернет-проекта:
На словах это может звучать довольно примитивно, но на практике нужно предпринять ряд мер, чтобы такой подход был реализуем. В первую очередь это автоматический сбор метрик (причем в агрегированном виде), построение графиков, а также сбор и анализ логов. Все данные должны появляться с минимальной задержкой, то есть как можно более близко к реальному времени. При анализе логов необходимо не просто получать информацию, а следить за динамикой показателей: стало лучше или хуже? Особенно это актуально при развертывании новых версий кода.
Золотое правило: планирование использования ресурсов намного проще, чем решение экстренных ситуаций, когда доступные ресурсы на исходе. Примерами агрегированных метрик в Twitter являются «киты» и «роботы», вернее их количество в единицу времени. Что такое «робот»? Ошибка внутри Rails (HTTP 500), непойманное исключение, проблема в коде или нулевой результат. Что такое «кит»? Это HTTP-ошибки 502 и 503, таймаут в 5 секунд (лучше кому-то показать ошибку, чем захлебнуться в запросах), убитый слишком длинный запрос к базе данных (mkill). Значительное превышение нормального количества китов или роботов в минуту является поводом для беспокойства. Механизм подсчета их количества реализован простым bash-скриптом, который просматривает агрегированные логи за последние 60 секунд, подсчитывает количество китов/роботов и рассылает уведомления, если значение оказалось выше порогового.
Для экстренных ситуаций в Twitter даже предусмотрен так называемый «темный режим», который представляет собой набор механизмов для отключения тяжелых по вычислительным ресурсам или вводу-выводу функциональных частей сайта. Получается что-то вроде стоп-крана для сайта. Есть около шестидесяти выключателей, в том числе и полный режим «только для чтения». Все изменения в настройках этого режима фиксируются в логах и сообщаются руководству, чтобы никто не баловался :).
Подводим итоги
Какие рекомендации дают разработчики Twitter создателям быстро растущих стартаптов?
Работа Twitter далеко не всегда была гладкой. Бывали простои, сложности получения данных через API и другие проблемы. Более того, архитектура проекта сильно изменилась за последнее время. Если взять презентации разработчиков двухгодичной давности и сравнить их с положением дел сегодня, то это будут две очень разные системы. Но по-другому, вероятно, и быть не могло. Сейчас это один из наиболее стремительно растущих стартапов, на которые можно смотреть лишь с восхищением.