память девичья? «Прогресс-М-57», был состыкован с МКС 26 июня 2006 года. «Прогресс М-57» доставил на станцию около 2,6 тонн различных грузов, в том числе научную аппаратуру и оборудование для проведения работ по программам российских и зарубежных партнеров.
по стоимости, зачем эта клоунада? совсем недавно навернулся прогресс к мкс, цена пуска озвучена (~$45 млрд):
«Общие затраты на пуск ракеты-носителя и транспортного грузового корабля составляют 2 млрд 589 млн руб. Из них матчасть, то есть ракета-носитель, обтекатель и грузовой корабль — 1 млрд 986 млн руб.», — заявил он.
ну мочу всегда вылить можно. прогрес 2.6 тонны доставлял, а они обещали уделать не легкий союз из 60х, а тяжелый протон. т.е. порядка 25 тонн на НОО и порядка 6 на мкс. и где? тем более, что пуск дрегона наса оплачивает $140 млн, союзов штуки четыре можно уже запустить за такую сумму
спасибо за статью и апдейт, тема интересная и было познавательно для меня. пришло понимание на кой такие сервисы клауды предлагают.
имхо без HDInsight это уже слабый конкурент. гемор в администрировании, даже ноды уже так просто не добавишь, нужно погружаться в толмуды манулов. я посмотрел у гугла минимальный, как мне показалось, вариант с их аналогом HDInsight (google dataproc). вышло около $181 за one node cluster на high-mem машинке: 26Gb ram + kafka кластер предустановленный из 3х микронод (+$105). Итого порядка $286 без сториджа. сторидж был бы еще +$82 за 2Tb.
вот это уже будет ближе к вашему азур варианту, где администрирование на себя клауд берет. тут уже сам клиент сможет ноды добавлять. что касается перфоменса one node cluster я гонял cloudera quickstart vm на i7 с 12Gb у виртуалки с 4 spark executors по 2Gb. запросы SQL spark неплохо прожувал.
как-то не впечатлило. 3 ноды по 4 ядра хадупа явно на два-три порядка более, чем 1к событий/сек прожуют, а тысячу событий просто же в mysql/postgres легко писать можно. выглядит что если цену азур стека пересчитать под более близкую нагрузку к kafka+spark (за $1181) разница будет в тысячи долларов.
плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.
в следующей статье хотелось бы обновить расчеты посерьезней нагрузкой, такой с какой имеет смысл влезать в бигдату. с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих. останутся ли адекватными расходы на азур стек при нагрузках, какие по зубам трем нодам хадуп?
В декабре прошлого года челябинец Дмитрий Дик взял потребительский кредит в Сбербанке. Сумма платежа ежемесячно списывалась с зарплатной карты. В феврале 2017-го мужчина переехал в Ставрополь, а к очередному платежу у карты закончился срок действия. Заёмщика припугнули просрочкой, хотя деньги на счёте есть. Почему возникла такая проблема и как её решить – разбирался ...
санкции сша наложили на конкретные предприятия, ВТБ то самое конкретное предприятие под санкциями. продукты они рекламируют тем, кто еще не попали в список. почитать можно начать отсюда ria.ru/economy/20180208/1514199450.html
у ВТБ по ядрам.
что считаю или не считаю объективно мало кому интересно. я могу сочинять, я могу быть заинтересованным продажником. я просто поработал и с тем и с другим, а теперь в принципе понимаю «Почему Сбербанк использовал». наша кантора пришла абсолютно к тем же выводам, не на пустом месте.
ничего забавного, просто вы похоже не задумывались ради чего эти снежинки и звезды, как внутри устроены рдбмс.
1. отказ от звезд не отменяет экономию пространства в паркетниках, лишь подчеркивают. хадуп может по разному, может как ваш постгрес, делать ETL и класть в звезду. эта звезда будет жрать много меньше места за счет колончатой структуры более экономного формата. у рдбмс же масса всего в блоке данных, у оракла там и место под блокировки и заголовок и много, много другого не нужного в задачах DWH/аналитики. у постгрес вовсе мрак — старые версии строк в датафайле живут, которые раздувают размер и которые GC вычищает. плюс индексы удваивают размер.
но звезда или снежинка не единственный поход в хадупе, сейчас вот модно с минимум трансформаций пихать в паркетник, тратя меньше ресурсов на ETL. витрины под отчетные системы из сырых данных строят. с рдбмс такое не выйдет.
2. вы путаете параллельные термины. то что хадуп много больше вычитывает не делает его менее масштабируемым. как раз эти чтения/писанина и позволяют ему дальше чем рдбмс масштабироваться. так же как оракловый кластер масштабируется дальше чем один узел, за счет гоняния огромных объемов данных по сети интерконекта, так и хадуп раскидывает на еще большее число узлов, но обычно и выполняя на порядок-два больше работы.
как пример в хадупах зачастую не напрягаются с мутными ETL которые вычислят что изменилось, а тупо перестраивают всю витрину после каждого обновления хранилища. и это часто много быстрее выходит, чем мутные ETL рдбмс, которые зачастую однопоточный pl/sql код.
в реляционных субд туча лишнего, чего не столь уж нужно для задач dwh и анализа. таблички оракла в 25 гб длегко превращаются в 3-4 гб parquet файла. хадупам не нужно преобразовывать данные во всякие звезды и снежинки, там нет проблем поставить 100500 узлов и просто решать задачи в лоб вычитывая каждый раз всю историю всех транзакций на каждый чих за счет чудовищных ресурсов. с рдбмс такие фокусы не проходят: ораклы и мсскл требуют непомерных денег за каждое ядро, постгрес хреново масштабируется, не имеет кластера. есть варианты типа гринплум, там вроде лучше, но все равно там больше от реляционной бд — с ETL в звезды/снежинки, форейн кеи, индексы.
хадупы выглядят модно потому, что не отменяют конечному пользователю похожие на реляционные таблички, SQL и прочие привычные аналитикам вещи, при этом в параллель читают на 100500 узлах, которые не требуют лицензирования каждого ядрышка.
уже случилось, новые лицензии втб от оракла уже не получит. тайный смысл в санкциях которые уже ударили.
креститься надо было когда гром грянул. много лет назад, а теперь надо выбрать кто ответит за глупые решения. платформа слабая, выше я показал тесты spec_rate где power8 почти в двое уступает x86. зачем было выбирать более слабую и менее любимую ораклом платформу? ведь и патчи оракл с огромной задержкой под эту платформу выпускает. через какого индуса теперь втб доставать будет патчи для этой полумертвой платформы? но главное кто ответит за столь прогнозируемый финал?
оракл первый, ibm будет вторым:
Oracle ужесточила условия предоставления продуктов и услуг российским клиентам из нефтегазовой отрасли, включенным в американский санкционный список, пишет газета «Коммерсант» со ссылкой на письмо компании от 12 января.
www.mcc.rsa.ru/progress_m09m.htm
«Прогресс-М-57», был состыкован с МКС 26 июня 2006 года. «Прогресс М-57» доставил на станцию около 2,6 тонн различных грузов, в том числе научную аппаратуру и оборудование для проведения работ по программам российских и зарубежных партнеров.
РИА Новости ria.ru/spravka/20060919/54041326.html
по стоимости, зачем эта клоунада? совсем недавно навернулся прогресс к мкс, цена пуска озвучена (~$45 млрд):
www.gazeta.ru/science/news/2015/04/29/n_7154561.shtml
имхо без HDInsight это уже слабый конкурент. гемор в администрировании, даже ноды уже так просто не добавишь, нужно погружаться в толмуды манулов. я посмотрел у гугла минимальный, как мне показалось, вариант с их аналогом HDInsight (google dataproc). вышло около $181 за one node cluster на high-mem машинке: 26Gb ram + kafka кластер предустановленный из 3х микронод (+$105). Итого порядка $286 без сториджа. сторидж был бы еще +$82 за 2Tb.
вот это уже будет ближе к вашему азур варианту, где администрирование на себя клауд берет. тут уже сам клиент сможет ноды добавлять. что касается перфоменса one node cluster я гонял cloudera quickstart vm на i7 с 12Gb у виртуалки с 4 spark executors по 2Gb. запросы SQL spark неплохо прожувал.
плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.
в следующей статье хотелось бы обновить расчеты посерьезней нагрузкой, такой с какой имеет смысл влезать в бигдату. с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих. останутся ли адекватными расходы на азур стек при нагрузках, какие по зубам трем нодам хадуп?
Оригинал материала: chel.74.ru/text/economics/302514805440512.html
зато есть отдел разработки лабораторного кластера супермассивов (тм)
у ВТБ по ядрам.
1. отказ от звезд не отменяет экономию пространства в паркетниках, лишь подчеркивают. хадуп может по разному, может как ваш постгрес, делать ETL и класть в звезду. эта звезда будет жрать много меньше места за счет колончатой структуры более экономного формата. у рдбмс же масса всего в блоке данных, у оракла там и место под блокировки и заголовок и много, много другого не нужного в задачах DWH/аналитики. у постгрес вовсе мрак — старые версии строк в датафайле живут, которые раздувают размер и которые GC вычищает. плюс индексы удваивают размер.
но звезда или снежинка не единственный поход в хадупе, сейчас вот модно с минимум трансформаций пихать в паркетник, тратя меньше ресурсов на ETL. витрины под отчетные системы из сырых данных строят. с рдбмс такое не выйдет.
2. вы путаете параллельные термины. то что хадуп много больше вычитывает не делает его менее масштабируемым. как раз эти чтения/писанина и позволяют ему дальше чем рдбмс масштабироваться. так же как оракловый кластер масштабируется дальше чем один узел, за счет гоняния огромных объемов данных по сети интерконекта, так и хадуп раскидывает на еще большее число узлов, но обычно и выполняя на порядок-два больше работы.
как пример в хадупах зачастую не напрягаются с мутными ETL которые вычислят что изменилось, а тупо перестраивают всю витрину после каждого обновления хранилища. и это часто много быстрее выходит, чем мутные ETL рдбмс, которые зачастую однопоточный pl/sql код.
хадупы выглядят модно потому, что не отменяют конечному пользователю похожие на реляционные таблички, SQL и прочие привычные аналитикам вещи, при этом в параллель читают на 100500 узлах, которые не требуют лицензирования каждого ядрышка.
креститься надо было когда гром грянул. много лет назад, а теперь надо выбрать кто ответит за глупые решения. платформа слабая, выше я показал тесты spec_rate где power8 почти в двое уступает x86. зачем было выбирать более слабую и менее любимую ораклом платформу? ведь и патчи оракл с огромной задержкой под эту платформу выпускает. через какого индуса теперь втб доставать будет патчи для этой полумертвой платформы? но главное кто ответит за столь прогнозируемый финал?
Oracle ужесточила условия предоставления продуктов и услуг российским клиентам из нефтегазовой отрасли, включенным в американский санкционный список, пишет газета «Коммерсант» со ссылкой на письмо компании от 12 января.
РИА Новости ria.ru/economy/20180208/1514199450.html