Мы стараемся делать более общее решение, а сервисы уже используют его слегка по-разному. Если UGC — то 3 копии в 3 разных ДЦ, сервис может полноценно работать даже при потере одного ДЦ. Большинство хочет хранить много данных, и производительность лимитируется диском. Для внутренних нужд сервисов применяются и другие конфигурации. Недавно прикидывали производительность при чтении/записи в память селких ключей (эдакий аналог memcache) — получилось больше 200 тысяч запросов в секунду обрабатывать на одной машине, 8 ядер из настоящих 16 были в sys :) Это как раз вариант, когда надо хранить мало данных, но очень быстро их в реалтайме обрабатывать, агрегировать и изредка скидывать на диск.
Из сильных отличий от всяких метрокластеров — работа с объектами, а не с блочными устройствами. Существенно упрощается синхронизация записей, можем делать какую-то работу на стороне хранилища, да хоть MapReduce организовать по данным. Ну и полностью горизонтальное масштабирование, чего совсем нет у NetApp и прочих производителей хранилищ с FC/iSCSI/AoE интерфейсами, которые предоставляют именно блочные устройства. Причём масштабирование как по объёму, так и по количеству клиентов — нет никаких ограничений, сколько машин работают с данными клиентов, каждый объект блокируется независимо от остальных. Но какой нибудь Оракл уже не запустишь, факт.
Чаще всего для того, чтобы не убивать каналы, достаточно тегировать траффик, только литься будет дольше. Всё равно есть часы наименьшей нагрузки. А вот когда надо именно относительно быстро перелить данные (а такое иногда бывает) — то тут уже надо что-то придумывать. И у перевозки на грузовиках есть куча минусов, типа неизбежных потерь дисков при погрузке-разгрузке, перевозке и т.д., требуется какая-никакая логистика, да и банально полки с дисками тяжёлые, инженеры ДЦ могут и не согласится забесплатно их тягать целый день. Но зато очень быстро.
Amazon AWS — это сервисы, которые были разработаны изначально для работы самой компании, но потом стали продаваться наружу. Почти каждый из них изначально был сделан именно для внутренних нужд: понадобилась аналитика для рекламы — научились поднимать Hadoop — сделали Elastic MapReduce. Аналогично, построили несколько ДЦ, в которых есть S3 — научились записывать данные в разные ДЦ для увеличения доступности площадки amazon.com — стали продавать за деньги. Если кто-то не хочет покупать эту услугу за дополнительные деньги (а аренда каналов между ДЦ не бесплатная), то он сам себе злобный буратино. Почему это должно быть бесплатно? Почему вы считаете, что свои данные Амазон хранит в одном ДЦ?
Совет про вникание в суть неплохой, прислушайтесь к нему и сами :) В контексте тредика (напомню, 1 петабайт данных) вы делали следующие высказывания и предположения: 1 копия данных, бэкап, несколько месяцев переливки данных это не проблема, никто не хранит живые копии в нескольких ДЦ.
Чтобы развеять ваши сомнения — я, внезапно, занимаюсь разработкой хранилища данных в Яндексе, с объёмами пользовательских данных порядка петабайтов. И я, как мне кажется, несколько в курсе проблем, упомянутых в тредике.
Очень жду вашего ответа с рассказом о вашем опыте в сфере хранения больших объёмов данных. Ещё раз прошу прощения за диванного теоретика.
Вы смешной такой, типичный диванный теоретик. Свои данные Амазон хранит в разных ДЦ. Яндекс хранит свои данные в разных ДЦ. Да любая компания, которая хочет работать при потере одного ДЦ (а это случается не так уж и редко, Амазон тому пример). И процесс перевоза данных, который растягивается на месяцы — это большая проблема.
Бекап и 1 петабайт данных — уже смешно. Как вы предлагаете это осуществить? Гугл просто держит 3 копии. Амазон в своём S3 тоже три копии. Яндекс тоже старается в 3 копиях.
Простите, но какой же надо иметь мозг, чтобы хотя бы подумать о том, чтобы хранить 1ПБ данных в одной копии? Конечно же, данные живые, и конечно же перенос, но есть ещё как минимум 1 копия (а лучше две) в других датацентрах. Писать данные сразу в 3 копиях обычно не такая большая проблема, как перенести одну из копий.
На досуге, посчитайте, сколько времени придётся переливать через 10G канал 1 петабайт данных, причём только по ночам. Через несколько лет скорость каналов увеличится на порядок, и объёмы данных увеличатся на порядок, время переноса полной копии же изменится слабо.
1 петабайт — это минимум 500 SATA дисков обычно в полках по 24 диска, каждая полка подключена к отдельному серверу. 4 диска легко забивают 1 гигабит при линейном чтении или записи. И когда идёт разговор о переносе 1 петабайта данных в другой ДЦ — чаще всего это означает, что надо не копию сделать, а именно перенести данные, дабы освободить место в старом ДЦ или перераспределить нагрузку.
Из моего опыта, узкое место при подобных операциях — именно сеть, гигабитный интерфейс машинки и 10-гигабитные меж-ДЦ линки. При нормальной работе сервиса этих показателей вполне достаточно, но вот если хочется БЫСТРО перетащить подобные объёмы данных — грузовик рулит. Это — практика, коллеги так делали :)
Потому что надо однозначное понимание, что делать в случае split brain. Если у вас репликасет из 4 машин развалится напополам, то он либо не будет работать совсем, либо будут работать обе половинки, данные вы потом будете с большим трудом восстанавливать. Репликасет с нечётным количеством реплик в принципе не может развалиться напополам, и именно для этого добавляют арбитра (по сути — бесполезную ноду, которая не делает ничего и просто болтается в реплика сете) в сеты с чётным количеством машин.
На сколько я понял, это не камера с передатчиком, а камера, которая записывает на флешку. Удалённо управлять с такой конечно же не получится. А передатчики аналогового видеосигнала весят обычно довольно много, так что об этой идее, скорее всего, придётся забыть.
Если кто-то захочет повторить подвиг автора и склеить свой первый самолёт — то настоятельно рекомендую делать плосколёт, т.е. самолёт с плоским крылом и плоским фюзеляжем. Иногда их крестолётами за это называют. Вот, например, статья про подобную модель: rc-aviation.ru/x-plane, только там крыло слегка объёмное всё же получилось. Куча чертежей тут: rc-aviation.ru/chertplosk/841-ploskolet-3d.
Получившийся плосколёт будет весить 300-500 грамм, в зависимости от размера, батарейки и кривости рук :) С лёгкостью будет переживать морковки, элементарно садиться на траву, взлетать с рук и легко настраиваться. Чинится в поле с помощью скотча, потом дома UHU por (кстати, рекомендую). В качестве лонжерона отлично работает карбоновая полоска 4.5мм в ширину (http://www.pilotage-rc.ru/catalogue/88_/88_55/RC7056/?flt[]=clf_88-55), ставить перпендикулярно плоскости крыла. Я делал из 2 слоёв 3мм потолочки, жёсткость отличная. Минус один — очень лёгкий, летать можно только при совсем слабом ветре. Ну и после него надо будет обязательно тренера с объёмным крылом, и только потом переходить к бальзовым моделям.
Ещё один момент, который автор не уточнил — делайте очень контрастную окраску модели, причём верх и них крыла должен сильно отличаться. С расстояния в 50м должно быть моментально понятно, как имеено расположен в воздухе самолёт.
И, что уж совсем плохо, автор не упомянул симуляторов. Я использую Reflex XTR, у китайцев проводок для подключения пульта к USB стоит около 10 баксов всего. Основные навыки тренирует отлично: полёт носом от себя, полёт носом к себе, посадка, полёт в перевёрнутом виде. Экономит просто кучу времени на ремонт. Думаю, если бы автор сначала научился летать в симуляторе, то первый полётный день прошёл бы существенно успешнее.
Допустим, компания делает для заказчика новую версию продукта каждые 6 месяцев. За 6 месяцев до начала разработки компания-заказчик начинает обсуждать с компанией-исполнителем, что они хотели бы видеть в новой версии, что именно исполнитель может успеть сделать в этой версии, как можно изменить требования для того, чтобы успели сделать законченную часть требований и т.д. Т.к. разговор в том числе и о деньгах — то в процессе этих переговоров регулярно оцениваются сроки для каждого из требований, суммарно набегает довольно большая цифра затраченного времени. Делается предварительная оценка — прикидываются деньги — изменяется изначальное требование, цикл повторяется иногда несколько раз, затем финализируется ТЗ и даётся окончательная оценка в деньгах = времени, т.к. оплата по человеко-месяцам.
Дать сразу готовый большой ТЗ и подождать пол года — это вариант с новым большим проектом, на который объявляют тендер. Там правда много человеко-лет на оценку будет потрачено :) Но для заказчика главное, чтобы потом не в сроки попали (хотя и это важно), а в деньги.
Вы, видимо, не поняли, что я имел в виду. Смысл статьи, каким увидел его я: «мы не можем поставлять готовый продукт в срок, потому что не знаем точно, что именно надо заказчику, и не знаем, как мы это будем делать, и не умеем делать из разработки конвеер». Я привёл пример компании, где конвеер успешно сделали )
Выпуск новой версии = несколько десятков человекомесяцев разработки. И не «смена дизайнов», дизайн изменений — это такой документ, где написано, где и какие именно изменения надо вносить для того, чтобы реализовать новый функционал, который хочет заказчик. На каждый более-менее независимый кусок изменений, запланированный на разрабатываемую версию, делается отдельный такой дизайн. Работа программистов, как это ни странно, заключалась в программировании :) Они внимательно читали дизайны изменений и эти самые изменения вносили.
Подкопите денег и приеприезжайте на 2 недели раньше, если боитесь именно акклиматизации ) Думаю, пары тысяч долларов хватит на оплату отеля, еды и транспорта на этот срок.
Пффф, да сколько угодно. У того же Вымпелкома с несколько десятков систем, на обсуждение каждой новой версии которой они тратят сильно больше, чем пол человеко/года. Как и у практически любой крупной компании. И почему-то у их исполнителей очень часто получается соблюдать сроки. Вы сейчас мыслите в масштабах фрилансера-одиночки, мир вокруг сильно больше и разнообразнее.
Вам неправильно кажется. В крупных интеграторах такое нередко бывает. Или в компаниях, которые продают крупный, но не совсем коробочный продукт типа CRM. На нижнем звене программисты заменяются легко благодаря чёткому ТЗ, мощной платформы, методологии и детально описанных документов с дизайном изменений.
Т.к. на разных проектах программисты работают, по сути, с одной и той же кодобазой, то замена нижнего звена программистов совсем проста, им совсем не надо «въезжать в код» — что и где менять написано в дизайне изменения, а как менять — они и сами знают. Замена людей, пишущих эти дизайны, требует небольшого лишь периода времени на ознакомление с ситуацией в конкретном проекте. Нелегко менять только тех людей, которые дают оценки по времени и решают в крупных мазках, где и что надо сделать для решения проблемы бизнеса заказчика, т.к. они обязаны хорошо знать конкретную систему этого заказчика.
Да, программирование в таких конторах — это скорее ремесло, чем искусство.
Я работал в компании, которая продавала заказчикам здоровенную систему (несколько миллионов строк кода), а затем регулярно делала новые версии, внося изменения по требованиям заказчика. Цикл сбор требований — их обсуждение — проектирование изменений — собственно из программирование — тестирование занимал год и при этом сроки чётко соблюдались. Да, waterfall. И, в пику рассуждениям автора, программисты там могли быть заменены почти безболезненно, потери времени минимальные благодаря чётко поставленному процессу и наличию большого количества программистов, работающих на соседнем похожем проекте.
Иногда мне кажется, что всякие agile техники популярны потому, что команда не понимает важности наличия аналитика, который вытащит из заказчика, что же он хочет на самом деле, нежелания зафиксировать эти самые желания и неумения оценивать сроки. Возможно, всё и не так на самом деле, но ощущение вот такое. И мне до сих пор не ясно, как команды, применяющие гибкие методологии, могут гарантировать поставку продукта до дедлайна.
Обычно подобные статьи являются научными работами или докладами на конференциях. У гугла есть целый сайт: research.google.com/. Регулярно подобные статьи появляются на highscalability.com/. И, конечно же, надо отлично знать сложность базовых алгоритмов и операций со структурами данных в О-нотации.
Задачи на собеседованиях обычно дают практического характера: как сделать top5 статей (и ответ «select * from… order by views limit 5 явно не подходит), как сделать новостную ленту типа фейсбучной, или как сохранить миллиард файликов. При этом обязательно надо понимать, какую производительность можно получить с диска и из памяти, на сколько хорошо параллелится задача при одновременных запросах от разных клиентов, и когда стоит записывать данные из памяти на диск.
Когда вы решаете задачу — надо мыслить на уровне алгоритмов и структур данных. Если вы отвечаете „а вот тут поставлю mongo/mysql/oracle/btrfs“ — почти наверняка последует вопрос „а почему именно это“ и „почему оно выдержит требуемые нагрузки“. Кстати, какие именно нагрузки будут — отдельный вопрос, который надо задавать интервьюеру, и в том числе и по подобным вопросам становится понятна квалификация собеседуемого.
Ну и отдельно стоит посмотреть задачки со всяких квалификационных раундов hacker cup и с собеседований, иногда там попадаются именно алгоритмические штуки. Можно почитать про штуки типа хэштаблицы локов, lock-free структуры или boost intrusive. Обязательно понимать, как могут синхронизироваться треды или процессы. В процессе использования готовых фреймворков-приложений-серверов пытаться понять, как именно они работают, и почему именно так.
Про DMCA уже упоминали в каментах, напомню только о законном рутките, который распространяла SONY на своих дисках в качестве DRM.
Далее, в начале 2012 года Обама говорил, что он против принятия SOPA. Осенью 2012 года состоялись выборы, гонка же началась аж за 1.5 года до выборов. Петицию подписали более 7 миллионов человек, как подсказывает мне википедия. А Обаме очень сильно были нужны голоса на предстоящих выборах.
Как думаете, какова вероятность принятия нового аналога SOPA в США, если смягчить его до российского законопроекта, да ещё и не перед выборами продвигать? Например OPEN, который продвигается Facebook и Google. Тем более, что в области борьбы за права (копирайт) и патенты США впереди планеты всей.
Что-то мне кажется, что SOPA или что либо подобное в штатах намного раньше введут. Просто вспомните, как быстро и лихо там ввели антитеррористические законы. Достаточно какой нибудь Apple, как одному из крупнейших игроков на рынке, поддержать подобный закон — его моментально введут, а пользователи ещё и рады будут.
Из сильных отличий от всяких метрокластеров — работа с объектами, а не с блочными устройствами. Существенно упрощается синхронизация записей, можем делать какую-то работу на стороне хранилища, да хоть MapReduce организовать по данным. Ну и полностью горизонтальное масштабирование, чего совсем нет у NetApp и прочих производителей хранилищ с FC/iSCSI/AoE интерфейсами, которые предоставляют именно блочные устройства. Причём масштабирование как по объёму, так и по количеству клиентов — нет никаких ограничений, сколько машин работают с данными клиентов, каждый объект блокируется независимо от остальных. Но какой нибудь Оракл уже не запустишь, факт.
Кстати, фейсбук, оказывается, именно от NetApp и отказался, когда перешёл на самопальное хранилище haystack: www.niallkennedy.com/blog/2009/04/facebook-haystack.html
Amazon AWS — это сервисы, которые были разработаны изначально для работы самой компании, но потом стали продаваться наружу. Почти каждый из них изначально был сделан именно для внутренних нужд: понадобилась аналитика для рекламы — научились поднимать Hadoop — сделали Elastic MapReduce. Аналогично, построили несколько ДЦ, в которых есть S3 — научились записывать данные в разные ДЦ для увеличения доступности площадки amazon.com — стали продавать за деньги. Если кто-то не хочет покупать эту услугу за дополнительные деньги (а аренда каналов между ДЦ не бесплатная), то он сам себе злобный буратино. Почему это должно быть бесплатно? Почему вы считаете, что свои данные Амазон хранит в одном ДЦ?
Совет про вникание в суть неплохой, прислушайтесь к нему и сами :) В контексте тредика (напомню, 1 петабайт данных) вы делали следующие высказывания и предположения: 1 копия данных, бэкап, несколько месяцев переливки данных это не проблема, никто не хранит живые копии в нескольких ДЦ.
Чтобы развеять ваши сомнения — я, внезапно, занимаюсь разработкой хранилища данных в Яндексе, с объёмами пользовательских данных порядка петабайтов. И я, как мне кажется, несколько в курсе проблем, упомянутых в тредике.
Очень жду вашего ответа с рассказом о вашем опыте в сфере хранения больших объёмов данных. Ещё раз прошу прощения за диванного теоретика.
Бекап и 1 петабайт данных — уже смешно. Как вы предлагаете это осуществить? Гугл просто держит 3 копии. Амазон в своём S3 тоже три копии. Яндекс тоже старается в 3 копиях.
На досуге, посчитайте, сколько времени придётся переливать через 10G канал 1 петабайт данных, причём только по ночам. Через несколько лет скорость каналов увеличится на порядок, и объёмы данных увеличатся на порядок, время переноса полной копии же изменится слабо.
1 петабайт — это минимум 500 SATA дисков обычно в полках по 24 диска, каждая полка подключена к отдельному серверу. 4 диска легко забивают 1 гигабит при линейном чтении или записи. И когда идёт разговор о переносе 1 петабайта данных в другой ДЦ — чаще всего это означает, что надо не копию сделать, а именно перенести данные, дабы освободить место в старом ДЦ или перераспределить нагрузку.
Из моего опыта, узкое место при подобных операциях — именно сеть, гигабитный интерфейс машинки и 10-гигабитные меж-ДЦ линки. При нормальной работе сервиса этих показателей вполне достаточно, но вот если хочется БЫСТРО перетащить подобные объёмы данных — грузовик рулит. Это — практика, коллеги так делали :)
Получившийся плосколёт будет весить 300-500 грамм, в зависимости от размера, батарейки и кривости рук :) С лёгкостью будет переживать морковки, элементарно садиться на траву, взлетать с рук и легко настраиваться. Чинится в поле с помощью скотча, потом дома UHU por (кстати, рекомендую). В качестве лонжерона отлично работает карбоновая полоска 4.5мм в ширину (http://www.pilotage-rc.ru/catalogue/88_/88_55/RC7056/?flt[]=clf_88-55), ставить перпендикулярно плоскости крыла. Я делал из 2 слоёв 3мм потолочки, жёсткость отличная. Минус один — очень лёгкий, летать можно только при совсем слабом ветре. Ну и после него надо будет обязательно тренера с объёмным крылом, и только потом переходить к бальзовым моделям.
Ещё один момент, который автор не уточнил — делайте очень контрастную окраску модели, причём верх и них крыла должен сильно отличаться. С расстояния в 50м должно быть моментально понятно, как имеено расположен в воздухе самолёт.
И, что уж совсем плохо, автор не упомянул симуляторов. Я использую Reflex XTR, у китайцев проводок для подключения пульта к USB стоит около 10 баксов всего. Основные навыки тренирует отлично: полёт носом от себя, полёт носом к себе, посадка, полёт в перевёрнутом виде. Экономит просто кучу времени на ремонт. Думаю, если бы автор сначала научился летать в симуляторе, то первый полётный день прошёл бы существенно успешнее.
Дать сразу готовый большой ТЗ и подождать пол года — это вариант с новым большим проектом, на который объявляют тендер. Там правда много человеко-лет на оценку будет потрачено :) Но для заказчика главное, чтобы потом не в сроки попали (хотя и это важно), а в деньги.
Выпуск новой версии = несколько десятков человекомесяцев разработки. И не «смена дизайнов», дизайн изменений — это такой документ, где написано, где и какие именно изменения надо вносить для того, чтобы реализовать новый функционал, который хочет заказчик. На каждый более-менее независимый кусок изменений, запланированный на разрабатываемую версию, делается отдельный такой дизайн. Работа программистов, как это ни странно, заключалась в программировании :) Они внимательно читали дизайны изменений и эти самые изменения вносили.
Т.к. на разных проектах программисты работают, по сути, с одной и той же кодобазой, то замена нижнего звена программистов совсем проста, им совсем не надо «въезжать в код» — что и где менять написано в дизайне изменения, а как менять — они и сами знают. Замена людей, пишущих эти дизайны, требует небольшого лишь периода времени на ознакомление с ситуацией в конкретном проекте. Нелегко менять только тех людей, которые дают оценки по времени и решают в крупных мазках, где и что надо сделать для решения проблемы бизнеса заказчика, т.к. они обязаны хорошо знать конкретную систему этого заказчика.
Да, программирование в таких конторах — это скорее ремесло, чем искусство.
Иногда мне кажется, что всякие agile техники популярны потому, что команда не понимает важности наличия аналитика, который вытащит из заказчика, что же он хочет на самом деле, нежелания зафиксировать эти самые желания и неумения оценивать сроки. Возможно, всё и не так на самом деле, но ощущение вот такое. И мне до сих пор не ясно, как команды, применяющие гибкие методологии, могут гарантировать поставку продукта до дедлайна.
Обычно подобные статьи являются научными работами или докладами на конференциях. У гугла есть целый сайт: research.google.com/. Регулярно подобные статьи появляются на highscalability.com/. И, конечно же, надо отлично знать сложность базовых алгоритмов и операций со структурами данных в О-нотации.
Задачи на собеседованиях обычно дают практического характера: как сделать top5 статей (и ответ «select * from… order by views limit 5 явно не подходит), как сделать новостную ленту типа фейсбучной, или как сохранить миллиард файликов. При этом обязательно надо понимать, какую производительность можно получить с диска и из памяти, на сколько хорошо параллелится задача при одновременных запросах от разных клиентов, и когда стоит записывать данные из памяти на диск.
Когда вы решаете задачу — надо мыслить на уровне алгоритмов и структур данных. Если вы отвечаете „а вот тут поставлю mongo/mysql/oracle/btrfs“ — почти наверняка последует вопрос „а почему именно это“ и „почему оно выдержит требуемые нагрузки“. Кстати, какие именно нагрузки будут — отдельный вопрос, который надо задавать интервьюеру, и в том числе и по подобным вопросам становится понятна квалификация собеседуемого.
Ну и отдельно стоит посмотреть задачки со всяких квалификационных раундов hacker cup и с собеседований, иногда там попадаются именно алгоритмические штуки. Можно почитать про штуки типа хэштаблицы локов, lock-free структуры или boost intrusive. Обязательно понимать, как могут синхронизироваться треды или процессы. В процессе использования готовых фреймворков-приложений-серверов пытаться понять, как именно они работают, и почему именно так.
Про DMCA уже упоминали в каментах, напомню только о законном рутките, который распространяла SONY на своих дисках в качестве DRM.
Далее, в начале 2012 года Обама говорил, что он против принятия SOPA. Осенью 2012 года состоялись выборы, гонка же началась аж за 1.5 года до выборов. Петицию подписали более 7 миллионов человек, как подсказывает мне википедия. А Обаме очень сильно были нужны голоса на предстоящих выборах.
Как думаете, какова вероятность принятия нового аналога SOPA в США, если смягчить его до российского законопроекта, да ещё и не перед выборами продвигать? Например OPEN, который продвигается Facebook и Google. Тем более, что в области борьбы за права (копирайт) и патенты США впереди планеты всей.