Я как-то не заметил особой разницы российским и американским обслуживанием в ресторанах/кафе. Разве что в штатах принято воду приносить и в недорогих заведениях refreshment напитков бывает. Правда вода иногда оказывается платной, а иногда и чаевые в счёт включены.
Назвать javasript интерпретатор v8 engine было офигеннейшей идеей для американского рынка. V8 — это мощность, скорость. Классика американского моторостроения, живая легенда, сердце любого маслкара, ну и заодно болидов наскара, драг-рейсовых и вообще почти всего, что движется на колёсах и похоже на машину.
Мне кажется, самый сложный момент — это нарезка 3д модели на слои, в результате которой уже получается G-Code. С одной стороны, у MS есть ресурсы (как финансовые, так и интеллектуальные) на разработку хорошего алгоритма. С другой стороны — а можно ли делать нарезку не зная ничего о возможностях принтера? Если они предложат схему, которая была 10-15 лет назад с обычными принтерами, когда всем занимался драйвер принтера — ну, будет просто чуть менее неудобно, чем сейчас. В стандартном окошке «Печать» появятся новые опции. Если смогут решить проблему нарезки и будет настоящий plug'n'play, как с флешками-мышками, то будет очень круто.
Перебалансировка — это когда фотография попадает на другой шард, в терминологии backpack. После замены диска надо запускать восстановление, а не перебалансировку, на другой шард фотография при этом естественно не переместится.
Перебалансировка может возникать при добавлении новых дисков в шард, когда увеличивается его ёмкость. Но в Topface решили не увеличивать шарды, и на то есть причины.
Тут не поспоришь. Только данные нужно линейно читать. В общем случае при ресайзе сетевые задержки гигабитного канала даже близко не сравнимы с disk read + resize.
Конечно с линейным чтением, без него весь смысл теряется. Про сеть я несколько другое имел в виду, с одного диска можно снять порядка 50 мегабайт линейного чтения. 2 диска, в итоге, забивают гигабитную сеть. У нас обычно стоят полки на 24 диска, я своими глазами видел 700 мегабайт в секунду в dstat. Сами понимаете, в сеть такое не запихнёшь. А надо же ещё данные отдавать.
Ничего из перечисленного не тянет на космические технологии, если честно :) Запускать задачи можно и вне хранилища, что куда удобнее, имея окружения для процессинга, которое можно растянуть по cpu гораздо дальше, чем себе могут позволить сервера с данными.
А у нас как раз есть опенсорсный app engine, я его для ресайзера предлагал как «одну штуку». Но некоторые задачи удобнее запускать на той же машине, где и данные лежат, это тупо быстрее из-за отсутствия сети между приложением и данными. Хорошо, когда есть выбор, правда? Кстати, приложения node.js мы в нашем app engine уже умеем запускать :)
При добавлении новых серверов elliptics на них перетащит часть данных, так ведь? Вот это нам как раз не сильно нужно в append-only хранилище.
И я вас прекрасно понимаю! Сейчас у нас есть вариант, когда при добавлении машин мы не перетаскиваем данные. Есть с этим некоторые неудобства, но тут у вас, на сколько я понимаю, похожая фигня: вы же запоминаете где-то, в какой шард положили фоточку? Кстати, 20млрд мы храним всё таки в старом варианте с DHT, на тех объёмах технология со скрипом, но работает.
Это задача мониторинга, а не системы хранения. У вас же вроде кластер заббикса для таких дел был.
Задача мониторинга — задетектить поломавшийся диск. Но мы хотим в этом месте проинтегрироваться с ним, чтобы автоматически восстанавливать всё сразу, как только сотрудники ДЦ заменили диск на новый. А если новый нельзя поставить — то восстановиться на какую нибудь другу машину.
Посмотрел ваши слайды. У нас есть одна штука и на тему ресайзера, и ещё пара дополнений для nginx кеша.
Из очевидных плюсов elliptics для хранения — просто сохраняешь и всё, не надо даже думать о том, что происходит под капотом: восстановления там всякие, миграция данных между серверами и прочее. Вам пришлось всё же всё это написать в backpack. У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности». Для загрузки процессоров серверов хранилищ — возможность загружать программки типа «пробежаться по фоткам и найти лица этим новым алгоритмом».
Вы же в Питере, да? Будете в мск — заходите, расскажем про космические технологии :)
Некий софт = система стабилизации и ориентации в пространстве как раз квадрокоптера paparazzi. Сложность в том, что в варианте для коптеров она управляет полётом путём изменения скорости вращения винтов. Я же собираю коптер с variable pitch винтами. По механике всё вроде хорошо складывается, надо только немножко поработать дрелью и напильником. А вот как настраивать стабилизацию — фиг знает, скорость реакции коптера на управляющий сигнал будет выше на порядок, но надо придумывать, как управлять оборотами винтов, чтобы они не проседали при резких изменениях угла атаки.
Как показывает наша практика, каждый раз, когда количество картинок значительно вырастает (тысяча, миллион, миллиард) — появляются проблемы, о которых раньше даже не предполагали. Если вдруг надумаете попробовать ещё раз — пишите. Если не секрет — почему именно для хранения фотографий не вдохновились?
Кстати, а вы про какие видео говорите? Выступление Жени на yac'2010?
А если у меня уже есть некий софт, и даже контроллер есть, куда я могу залить этот софт, то как делают software in the loop и hardware in the loop симуляции?
Это я развивал мысль, которая с комментария roman_kashitsyn началась:
Кому-то ещё охота возиться с кучей локов и мутексов, корректно и быстро работать с которыми получается практически никогда?
Уж либо использовать атомарные примитивы, либо строить приложение на базе более высокоуровневых конструкций вроде тредпулов с фьючерами, очередей с производителями/потребителями или fork/join (одно не исключает другого).
Тредпул с фьючерами и очередью перед пулом — как раз такая конструкция, в которой мы в очередь запихиваем нечто и потом ожидаем ответа. А если очередь рассматривать как элемент пайплайна (вы же такое использование предполагали, да?), то тогда действительно раундтрип может оказаться цифрой, которая не имеет смысла.
P.S. мне кажется, наша с вами переписка могла дать много новых знаний программистам, только начинающим изучать многопоточность
Есть опен-сорс реализация по мотивам FB Haystack — github.com/reverbrain/eblob/. Это низкоуровневая часть. А собственно хранилище — github.com/reverbrain/elliptics/. Храним всякое разное, начиная от картинок и заканчивая видео. Правда у нас кластерки побольше слегка, тот, что с картиночками — около 20 000 000 000 картинок :)
Всё опенсорс, и есть даже несколько инсталляций за пределами нашей компании. undev, например, у себя пробует. Есть множество плюшек кроме непосредственно хранения.
«хорошие сапоги надо брать» :) Да просто снимите жирное, или раскидайте по всему тексту, сейчас все 4 слова в одном абзаце и глаз сразу всю фразу выхватывает, а мозг шепчет «СЕО!»
16 запусков, 1 неудачный (всего в мире 34/2)
2012 год:
24 запуска, 1 неудачный, 1 частично неудачный (всего в мире 78/4)
2011 год:
32 запуска, 4 неудачных (всего в мире 83/6)
2010 год:
31 запуск, 1 неудачный (всего в мире 74/4)
Данные из википедии.
Перебалансировка может возникать при добавлении новых дисков в шард, когда увеличивается его ёмкость. Но в Topface решили не увеличивать шарды, и на то есть причины.
© www.tomshardware.com/news/Leef-Bridge-Jelly-Bean-USB-OTG-micro-USB-ASTRO-File-Manager,23246.html
Конечно с линейным чтением, без него весь смысл теряется. Про сеть я несколько другое имел в виду, с одного диска можно снять порядка 50 мегабайт линейного чтения. 2 диска, в итоге, забивают гигабитную сеть. У нас обычно стоят полки на 24 диска, я своими глазами видел 700 мегабайт в секунду в dstat. Сами понимаете, в сеть такое не запихнёшь. А надо же ещё данные отдавать.
А у нас как раз есть опенсорсный app engine, я его для ресайзера предлагал как «одну штуку». Но некоторые задачи удобнее запускать на той же машине, где и данные лежат, это тупо быстрее из-за отсутствия сети между приложением и данными. Хорошо, когда есть выбор, правда? Кстати, приложения node.js мы в нашем app engine уже умеем запускать :)
И я вас прекрасно понимаю! Сейчас у нас есть вариант, когда при добавлении машин мы не перетаскиваем данные. Есть с этим некоторые неудобства, но тут у вас, на сколько я понимаю, похожая фигня: вы же запоминаете где-то, в какой шард положили фоточку? Кстати, 20млрд мы храним всё таки в старом варианте с DHT, на тех объёмах технология со скрипом, но работает.
Задача мониторинга — задетектить поломавшийся диск. Но мы хотим в этом месте проинтегрироваться с ним, чтобы автоматически восстанавливать всё сразу, как только сотрудники ДЦ заменили диск на новый. А если новый нельзя поставить — то восстановиться на какую нибудь другу машину.
Из очевидных плюсов elliptics для хранения — просто сохраняешь и всё, не надо даже думать о том, что происходит под капотом: восстановления там всякие, миграция данных между серверами и прочее. Вам пришлось всё же всё это написать в backpack. У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности». Для загрузки процессоров серверов хранилищ — возможность загружать программки типа «пробежаться по фоткам и найти лица этим новым алгоритмом».
Вы же в Питере, да? Будете в мск — заходите, расскажем про космические технологии :)
Кстати, а вы про какие видео говорите? Выступление Жени на yac'2010?
А если у меня уже есть некий софт, и даже контроллер есть, куда я могу залить этот софт, то как делают software in the loop и hardware in the loop симуляции?
Тредпул с фьючерами и очередью перед пулом — как раз такая конструкция, в которой мы в очередь запихиваем нечто и потом ожидаем ответа. А если очередь рассматривать как элемент пайплайна (вы же такое использование предполагали, да?), то тогда действительно раундтрип может оказаться цифрой, которая не имеет смысла.
P.S. мне кажется, наша с вами переписка могла дать много новых знаний программистам, только начинающим изучать многопоточность
Всё опенсорс, и есть даже несколько инсталляций за пределами нашей компании. undev, например, у себя пробует. Есть множество плюшек кроме непосредственно хранения.