Я например использую реализацию, которая ресайзит 5120×2880 в 2048×1152 с фильтром Ланцоша за 150 ms на одном ядре процессора, т.е. делает это со скоростью 98 мегапикселей в секунду, и хорошо параллелится на все ядра сервера.
Теоретически да. Но тут есть подводные камни, основной из которых звучит так: какое количество объектов разумно хранить в одном пространстве ключей. Представьте себе, что у вас есть некий key-value сторадж, который одинаково хорошо хранит как большие, так и мелкие объекты (что уже не правда, но допустим).
Если все-все объекты всех пользователей хранить с таком сторадже, то при попытке пользователя получить доступ к своему файлу, нужно будет найти его среди триллиона остальных. Расширять такое хранилище будет очень сложно. Условно запись файла можно представить как запись строки в таблицу, и есть только одна таблица на всех. Сами понимаете, хранить триллион строк в таблице не очень здорово. Можно шардировать, но нужно будет уметь перешардировать на лету, это тяжёлая операция. А количество данных у успешного хранилища растёт по экспоненте.
Логично предположить, что файлы, лежащие в одном бакете, не имеют ничего общего с файлами, лежащими в других бакетах. Тогда можно изолировать пространства имён, делая новое для каждого бакета. Правда, тогда создание бакета станет не слишком простой операцией, и ограничения могут возникнуть из-за количества бакетов. Если продолжить аналогию с таблицами — каждый бакет это своя таблица, и проблема может быть с количеством таблиц. Особенно расточительно так делать для мелких бакетов.
Третий вариант — гибридный, использовать одно пространство ключей для нескольких бакетов. Как вы понимаете, есть как плюсы, так и минусы от обоих вариантов. При этом можно иметь возможность хранить один бакет в нескольких «таблицах».
Но какой бы вариант не использовали, количество ключей будет проблемой. Увеличивать его просто так, на ровном месте, используя цепочку, я бы не стал. Ну и слишком дорого будет делать листинг, удалять элементы и прочее. А если вспомнить о том, что эта штука должна быть распределённой, и нужно как-то консистентность листинга поддерживать… Лучше уж какое-нибудь b-tree, чем цепочка.
Лично мой мнение: сделайте версию с контроллером LiPo (зарядка, повышающий DC-DC для питания камер всяких), и делайте упор на автономность платки. И ещё, пожалуй, веб-сервер в платку или пример приложения для айфона с андроидом. Мол, приладил к велосипеду/камере/фотику и вот у тебя там контроллер со встроенным вайфаем, автономный, и сразу с телефона можно этим управлять. Virt2Real без мощного процессора, зато со встроенным WiFi.
Возможно, эта история слишком сильно пересекается с Virt2Real, и надо придумать другую. Но история нужна обязательно, потому что люди, всё же, покупают историю, потенциальную возможность, а не железку. Количество всяких RaspberryPi, пылящихся на полках у людей, подтверждает эту теорию.
Бакет — это список, при добавлении нового объекта в бакет обязательно нужно этот список обновлять, так что не могу однозначно согласиться с вами. Обновлять структурку на 400 млн элементов — это не тривиальная задача, у которой есть несколько путей решения. Я пытался найти какие либо презентации Амазона по поводу внутреннего устройства S3, но, к сожалению, ничего дельного не нашлось, поэтому вот приходится вот такие косвенные свидетельства искать.
Сколько моделей таких свитчей, по паре у самых крупных вендоров? :) А если серьёзно, у них разве совсем нету проблем с прокачкой между линейными картами? В этом эксперименте нагрузка на каждый порт порядка 20-25 гигабит. При этом каждый из 84 RU шлёт свои 20 гигабит в 64 BU, то есть каким либо образом разгрузить backplane (или как оно там у таких свитчей уже называется) не получится.
Ну и отдельный вопрос про стоимость, стойка довольно компактная, весь их инфинибанд на меди, судя по картинкам.
И если совсем уж начистоту, разве вам не хотелось бы участвовать в постройке инфраструктуры для таких потоков данных?
Крайне рекомендую посмотреть вот эти слайды: indico.cern.ch/event/192695/session/2/contribution/98/material/slides/0.pdf. В них описывается инфраструктура для всего лишь одного эксперимента под названием CMS, а точнее то, что планируется собрать к лету 2015 года. Лично меня особенно впечатлила EvenBuilder network — это сеть с суммарной пропускной способностью в 6 терабит в секунду!
Откуда берутся такие цифры? В процессе эксперимента каждый из 84 Readaut Unit'а (RU) генерирует свой кусочек события, и происходит это 100 тысяч раз в секунду. Событие — это данные со всех датчиков, собранные синхронно, в один момент времени. Суммарно эти кусочки составляют до 2 мегабайт данных. Все кусочки за какой либо конкретный момент времени в итоге должны оказаться на одном Builder Unit'е (BU), который отправит их в свою небольшую ферму компьютеров, на которой из всего потока выделяются только 0.5% интересных учёным событий.
99.9% (это моя оценка) пользователей автомобиля понятия не имеют, как гудит подшипник. Даже из оставшихся 0.1%, куда я имею наглость записать и себя, не все смогут сразу услышать и связать с оборотами-скоростью-передачей. Даже направление иногда сложно засечь.
Ну и все едут сильно далеко от предела сцепления шинс асфальтом и не догадываются, где он. Так что шум шин тут тоже не помощник. А в штатах, с их бетонными дорогами с насечками, так вообще ужас сплошной, никакого от него толку.
Типичный потребитель автомобиля показывает машину в техцентре, когда машина об этом напомнит, а если случилась проблема в дороге, то вызывает эвакуатор.
С редиректами есть очень неприятная проблема: локальные провайдеры не всегда пирятся друг с другом. Например, в Новосибирске есть аж 4 разных точки пиринга. Если ваш сервер не доступен напрямую хотя бы с одной из них — то пользователь будет ходить в него через Москву.
Второй момент — далеко не всегда можно по IP адресу определить регион пользователя. У тех же сотовых операторов айпишники по всей стране назначаются, блоки адресов «плавают» от Владивостока к Москве. В этом случае геобаза тоже никак не поможет.
Оба варианта закрываются редиректором, адрес которого эникастят, как вы и сказали. Так что своим комментарием я хочу добавить ваш, чтобы другие читатели ознакомились с этой гранью проблемы.
А получится ли питать lightning кабелем устройство, у которого нету своей батарейки? Или они измеряют сопротивление между определёнными пинами и там должно быть определённое значение?
Юбка коннектора соединяется с оплёткой кабеля. На устройствах обычно металлический корпус разъёма сажают на землю.
У меня дома 5м hdmi кабель соединяет телек и системник. Когда вставляю hdmi сначала в телек, а потом в комп, то там приличное переменное напряжение, пальцы дёргает. Навскидку как раз те 110 вольт, но тестером не замерял. Поменял уже телек и БП, ничего не изменилось, но ничего и не поломалось :) Старый телек работает отлично.
Док для 11" ноутбука выглядит так:
Основной минус конкретно этого дока — проприетарный видеочип и отсутствие питания для самого ноутбука. Если видео пустить через displayport, а ноутбук от дока запитать, то вообще отлично будет.
Кладёте вы, значит, разъём, у которого контакты по внешней стороне, на свой металлический макбук…
Именно по этой причине обычная электрическая вилка, в которой не может быть питания никогда, штырями наружу, а в розетке — отверстия. Я понимаю, что вы сейчас скажете про лайтнинг, контакты в углублении и прочее. Но тут начинает работать ещё один фактор. Фича USB в том, что он соединяет 2 устройства, у каждого из которых может быть своё питание от розетки, может быть даже разность потенциалов между нулями. И сначала в разъём попадает «юбка» коннектора, выравняет потенциалы, и только потом уже начнут соединяться сигнальные линии. 110 вольт (половина напряжения питания) между нулями принтера и десктопа как нефиг делать могут появиться.
Уже писал в прошлой статье про новый usb разъём :) Чтобы на ощупь втыкать micro usb разъём его надо щупать: на более широкой стороне торчат 2 прижимных усика, которые отлично чувствуются подушечкой пальца. Просто зажмите металлическую часть разъёма между большим и указательным пальцами и сразу поймёте, о чём я. После этого вам останется только запомнить, где «верх» разъёма у вашего телефона.
Я, к сожалению, методичку, по которой мне это рассказывали, показать не смогу, потому что она бумажная. Но вот более-менее похожее краткое описание: lpishnik.livejournal.com/1516.html. При этом нужно иметь в виду, что чистые типы встречаются крайне редко, обычно это смесь каждой части в разных пропорциях. При этом контролёр-поддержка и анализатор-мотор являются противоположными друг другу и плоховато друг друга понимают.
Всё это, понятное дело, линейкой не измерить, клеймо на людях ставить не стоит. Но можно попробовать увидеть основной тип в человеке и после этого выбирать «правильные» для него доводы, когда преподносите ему свою идею.
Поделитесь?
Если все-все объекты всех пользователей хранить с таком сторадже, то при попытке пользователя получить доступ к своему файлу, нужно будет найти его среди триллиона остальных. Расширять такое хранилище будет очень сложно. Условно запись файла можно представить как запись строки в таблицу, и есть только одна таблица на всех. Сами понимаете, хранить триллион строк в таблице не очень здорово. Можно шардировать, но нужно будет уметь перешардировать на лету, это тяжёлая операция. А количество данных у успешного хранилища растёт по экспоненте.
Логично предположить, что файлы, лежащие в одном бакете, не имеют ничего общего с файлами, лежащими в других бакетах. Тогда можно изолировать пространства имён, делая новое для каждого бакета. Правда, тогда создание бакета станет не слишком простой операцией, и ограничения могут возникнуть из-за количества бакетов. Если продолжить аналогию с таблицами — каждый бакет это своя таблица, и проблема может быть с количеством таблиц. Особенно расточительно так делать для мелких бакетов.
Третий вариант — гибридный, использовать одно пространство ключей для нескольких бакетов. Как вы понимаете, есть как плюсы, так и минусы от обоих вариантов. При этом можно иметь возможность хранить один бакет в нескольких «таблицах».
Но какой бы вариант не использовали, количество ключей будет проблемой. Увеличивать его просто так, на ровном месте, используя цепочку, я бы не стал. Ну и слишком дорого будет делать листинг, удалять элементы и прочее. А если вспомнить о том, что эта штука должна быть распределённой, и нужно как-то консистентность листинга поддерживать… Лучше уж какое-нибудь b-tree, чем цепочка.
Возможно, эта история слишком сильно пересекается с Virt2Real, и надо придумать другую. Но история нужна обязательно, потому что люди, всё же, покупают историю, потенциальную возможность, а не железку. Количество всяких RaspberryPi, пылящихся на полках у людей, подтверждает эту теорию.
Ну и отдельный вопрос про стоимость, стойка довольно компактная, весь их инфинибанд на меди, судя по картинкам.
И если совсем уж начистоту, разве вам не хотелось бы участвовать в постройке инфраструктуры для таких потоков данных?
Откуда берутся такие цифры? В процессе эксперимента каждый из 84 Readaut Unit'а (RU) генерирует свой кусочек события, и происходит это 100 тысяч раз в секунду. Событие — это данные со всех датчиков, собранные синхронно, в один момент времени. Суммарно эти кусочки составляют до 2 мегабайт данных. Все кусочки за какой либо конкретный момент времени в итоге должны оказаться на одном Builder Unit'е (BU), который отправит их в свою небольшую ферму компьютеров, на которой из всего потока выделяются только 0.5% интересных учёным событий.
Ну и все едут сильно далеко от предела сцепления шинс асфальтом и не догадываются, где он. Так что шум шин тут тоже не помощник. А в штатах, с их бетонными дорогами с насечками, так вообще ужас сплошной, никакого от него толку.
Типичный потребитель автомобиля показывает машину в техцентре, когда машина об этом напомнит, а если случилась проблема в дороге, то вызывает эвакуатор.
А если серьёзно — зачем вы используете эти здоровые 24-дисковые полки в новом ДЦ? У них же плотность размещения дисков совсем низкая.
Второй момент — далеко не всегда можно по IP адресу определить регион пользователя. У тех же сотовых операторов айпишники по всей стране назначаются, блоки адресов «плавают» от Владивостока к Москве. В этом случае геобаза тоже никак не поможет.
Оба варианта закрываются редиректором, адрес которого эникастят, как вы и сказали. Так что своим комментарием я хочу добавить ваш, чтобы другие читатели ознакомились с этой гранью проблемы.
Юбка коннектора соединяется с оплёткой кабеля. На устройствах обычно металлический корпус разъёма сажают на землю.
У меня дома 5м hdmi кабель соединяет телек и системник. Когда вставляю hdmi сначала в телек, а потом в комп, то там приличное переменное напряжение, пальцы дёргает. Навскидку как раз те 110 вольт, но тестером не замерял. Поменял уже телек и БП, ничего не изменилось, но ничего и не поломалось :) Старый телек работает отлично.
Основной минус конкретно этого дока — проприетарный видеочип и отсутствие питания для самого ноутбука. Если видео пустить через displayport, а ноутбук от дока запитать, то вообще отлично будет.
Именно по этой причине обычная электрическая вилка, в которой не может быть питания никогда, штырями наружу, а в розетке — отверстия. Я понимаю, что вы сейчас скажете про лайтнинг, контакты в углублении и прочее. Но тут начинает работать ещё один фактор. Фича USB в том, что он соединяет 2 устройства, у каждого из которых может быть своё питание от розетки, может быть даже разность потенциалов между нулями. И сначала в разъём попадает «юбка» коннектора, выравняет потенциалы, и только потом уже начнут соединяться сигнальные линии. 110 вольт (половина напряжения питания) между нулями принтера и десктопа как нефиг делать могут появиться.
Всё это, понятное дело, линейкой не измерить, клеймо на людях ставить не стоит. Но можно попробовать увидеть основной тип в человеке и после этого выбирать «правильные» для него доводы, когда преподносите ему свою идею.
(это я про классификацию, которая с моторами и контролёрами)
habrahabr.ru/post/185562/
habrahabr.ru/company/yandex/blog/223273/