А вы хотите менять основной паспорт каждые несколько лет? Некоторые ездят часто, у них странички за 3 год кончаются. Что им, без единственного айди оставаться?
На сколько я в курсе, терминал для оплаты картой для магазина стоит порядка 10 000 рублей. Это разве неподъёмная сумма для малого бизнеса? Кассовый аппарат и то дороже стоит.
Что-то у вас с арифметикой, 1 петабайт = 1000 терабайт = 1000 000 гигабайт.
1ПБ / 3.6ТБ/день = 278 дней. Вполне себе нормальная цифра.
И да, хранилища подобных масштабов редко когда наполняется внезапно, чаще всего это занимает время. Даже если видеоролики хранить в нём. Гигабит нужен для репликации, пики будут только при потере диска — надо будет из другого ДЦ перелить на него данные.
Про достаточность канала в один-два гигабита между ДЦ (если снаружи приходит меньше гигабита траффика, ессно) — это из личной практики, есличо.
А кто в этой схеме разруливает перекрёстные блокировки, ведущие к дедлокам? В варианте с 2 одновременными запросами, блокирующими одни и те же данные на разных AMP, кто следит за тем, что блокировки встанут в очередь в одинаковом порядке?
Главное — не закидывать в багаж те вещи, которые могут понадобиться в первый день после прилёта. Обычно, если багаж не улетел вмести с вами — его доставляют на следующем в течение суток. У хороших авиакомпаний — ещё и доставляют в отель/домой :) А уж купить вечером немножко одежды на завтра можно почти в любой стране за немного денег.
Ну и отдельная категория — полёт на 2-3 дня, для таких перелётов крайне рекомендую чемодан, который проходит по нормам ручной клади, но умеет расширяться. Существенно экономится время по прилёту, и, иногда, деньги. Если захочется чего нибудь булькающего привезти домой — то расширить чемодан и в багаж сдать.
Map-Reduce в принципе не предназначен для реалтайма. Гугл тоже это понимает и внутри себя они сделали Colossus. Если нужно именно моментально что-то обсчитывать — посмотрите в сторону twitter storm. Есть и другие похожие штуки, но всё оно основано на пайплайнах, по которым в реалтайме пробегают события-данные.
Ненене, про master-slave + nfs фейсбук ещё в прошлом году рассказывал, это не дело. Допустим, у меня 2, или лучше даже 3 ДЦ, хочу, чтобы всё (точнее, меня интересует хранение информации) работало при падении любого из ДЦ и при этом не помирало при несильном моргании сети.
Что-то я недавно слышал про master-master то ли в HDFS, то ли в HBase. Можете порассказывать про это? Я, к сожалению, не силён в экосистеме хадупа, поэтому сходу не знаю, где что искать и как оно должно называться.
Как разруливается ситуация, когда с разных PE запускаются 2 транзакции, которые выполняются на нескольких AMP одновременной (одних и тех же), обе транзакции пытаются обновить одни и те же строки? Если одна из них откатывается — как откатываются данные на остальных AMP?
То есть из своего опыта кажется, что транзакции должны быть распределёнными, что-то типа PAXOS или ZAB. Что в Teradata?
Ну то есть фигово скейлится :) Горизонтальное масштабирование — это когда в разы легко можно увеличить объём. Опять же, вопрос с пропаданием питания на стойке не решён, не всегда можно так делать.
Это я к тому, что вешать много полок на 1 машину — тупиковый путь, подходит только если не надо будет потом увеличивать объём.
Прочитал, ещё пдфку нашёл, и в википедии. Оказывается, у него ядро всегда в режиме реактивного двигателя работает, либо на жидком кислороде, либо на сильно охлаждённом воздухе. А в режиме ПВРД только второй контур, так что как взлетает — более менее ясно стало.
А зря смущает, вес не сильно больше только реактивной части, зато первые 30км полёта не надо тратить окислитель. А количество окислителя, по массе, сравнимо с количеством топлива. Так что существенная экономия будет. К тому же ступень — на то и ступень, в космос она не полетит :)
Классический «самолётный» — это турбореактивный двигатель, внутри обязательно присутствуют компрессор и турбина, если закрыть у него воздухозаборник — он в реактивный («ракетный») никак не превратится, разве что если в форкамере городить всё реактивное хозяйство. Ну и, самое главное то, даже форкамерные ТРД не могут разогнать летательный аппарат до скорости больше 3 махов.
Если же внимательно посмотреть на картинку из видео, то становится понятно, что на самом деле там прямоточный ВРД, причём больше похож на сверхзвуковой. Двигатели вот такого типа как раз могут работать на скорости до 5.5 маха. Но даже если их регулируемое сопло позволяет на дозвуке работать, то всё равно на скорости до 0.5 маха потери больше, чем тяга. А при нулевой скорости он в принципе работать не может, в отличие от турбореактивного.
Собственно, после именно таких рассуждений мне и стало интересно, как же они предлагают использовать такую штуку в качестве первой ступени.
Потом пропадает питание у ОДНОЙ полки и весь раздел разваливается. Или у вас 32 раздела получается? В каждой полке сколько дисков может вылететь, максимум один? Я уж не говорю про скорость восстановления реида под нагрузкой.
И эта схема не скейлится, 2ПБ уже не сделать никак.
Хотя я сейчас прочитал ещё раз описание сервиса на сайте амазона — тупо 24 диска предлагают, а это уже не интересно совсем.
Как же оно стартовать то будет на одной ступени? Прямоточные воздушно-реактивные двигатели, на сколько я в курсе, начинают работать на скорости больше 0.5 маха.
Я и так знаю, как сделать S3 петабайтового размера, и сколько это будет стоить :) Но при разумном ограничении размера каждого объекта в единицы и десятки гигабайт.
А вот как хранить 1ПБ файл (типа образ диска, на котором файловая система), чтобы он был в консистентном состоянии и уметь его восстанавливать — вопрос действительно интересный, и просто набиванием дисками стойки его не решить, тут должен быть какой-то софт. Может быть, специальная файловая система. Или на самом деле хранятся куски файла, а в линкусе специальный драйвер блочных устройств, который требует от хранилища только консистентность на уровне блока. Но про это как-то не пишут :(
1ПБ / 3.6ТБ/день = 278 дней. Вполне себе нормальная цифра.
И да, хранилища подобных масштабов редко когда наполняется внезапно, чаще всего это занимает время. Даже если видеоролики хранить в нём. Гигабит нужен для репликации, пики будут только при потере диска — надо будет из другого ДЦ перелить на него данные.
Про достаточность канала в один-два гигабита между ДЦ (если снаружи приходит меньше гигабита траффика, ессно) — это из личной практики, есличо.
Ну и отдельная категория — полёт на 2-3 дня, для таких перелётов крайне рекомендую чемодан, который проходит по нормам ручной клади, но умеет расширяться. Существенно экономится время по прилёту, и, иногда, деньги. Если захочется чего нибудь булькающего привезти домой — то расширить чемодан и в багаж сдать.
Кто нибудь уже пробовал?
Что-то я недавно слышал про master-master то ли в HDFS, то ли в HBase. Можете порассказывать про это? Я, к сожалению, не силён в экосистеме хадупа, поэтому сходу не знаю, где что искать и как оно должно называться.
То есть из своего опыта кажется, что транзакции должны быть распределёнными, что-то типа PAXOS или ZAB. Что в Teradata?
Ну то есть фигово скейлится :) Горизонтальное масштабирование — это когда в разы легко можно увеличить объём. Опять же, вопрос с пропаданием питания на стойке не решён, не всегда можно так делать.
Это я к тому, что вешать много полок на 1 машину — тупиковый путь, подходит только если не надо будет потом увеличивать объём.
Классический «самолётный» — это турбореактивный двигатель, внутри обязательно присутствуют компрессор и турбина, если закрыть у него воздухозаборник — он в реактивный («ракетный») никак не превратится, разве что если в форкамере городить всё реактивное хозяйство. Ну и, самое главное то, даже форкамерные ТРД не могут разогнать летательный аппарат до скорости больше 3 махов.
Если же внимательно посмотреть на картинку из видео, то становится понятно, что на самом деле там прямоточный ВРД, причём больше похож на сверхзвуковой. Двигатели вот такого типа как раз могут работать на скорости до 5.5 маха. Но даже если их регулируемое сопло позволяет на дозвуке работать, то всё равно на скорости до 0.5 маха потери больше, чем тяга. А при нулевой скорости он в принципе работать не может, в отличие от турбореактивного.
Собственно, после именно таких рассуждений мне и стало интересно, как же они предлагают использовать такую штуку в качестве первой ступени.
И эта схема не скейлится, 2ПБ уже не сделать никак.
Хотя я сейчас прочитал ещё раз описание сервиса на сайте амазона — тупо 24 диска предлагают, а это уже не интересно совсем.
А вот как хранить 1ПБ файл (типа образ диска, на котором файловая система), чтобы он был в консистентном состоянии и уметь его восстанавливать — вопрос действительно интересный, и просто набиванием дисками стойки его не решить, тут должен быть какой-то софт. Может быть, специальная файловая система. Или на самом деле хранятся куски файла, а в линкусе специальный драйвер блочных устройств, который требует от хранилища только консистентность на уровне блока. Но про это как-то не пишут :(