Как стать автором
Обновить

Комментарии 17

Так вот что с rutube приключилось!

Когда увидел заголовок, решил что речь как раз о RuTube. Видимо, не я один так решил.

Как по мне, это уж слишком умный и хитрый джуниор.

Джуниор - это про отсутствие опыта, а не ума.

Просто звёзды неудачно сошлись. Провайдер видеохостинга со своими джунами в поддержке + автор, решивший запилить одноразовый велосипед all-in-one.

20тб диск стоит тысячу долларов. Берем два делаем raid1, надежно! Итого две тысячи долларов. Диски останутся в вашем сервере до следующего такого же случая. Они прослужат годы.

20тб в облаке Амазона стоит 500 долларов за месяц. Месяца всяко хватит на все эксперименты, пока все успешно не перенесется.

О чем вообще речь? Зарплата джуна с налогами и офисом за месяц выходит больше чем надежное место чтобы эти данные положить временно для экспериментов.

Не экономьте на спичках. При любом переносе данные в начале кладем в надежное и простое место, и только потом экспериментируем как переложить туда куда надо. Нервы или тем более потерянные данные выйдут гораздо дороже чем любое адекватное хранилище для них.

Я так понимаю, данные у них хранились в надёжном месте, а проблема была с автоматизацией загрузки и скоростью передачи

А тогда зачем суетится и волноваться? Не получилось - снесли и перелили ещё раз. Более правильно. Передача 20тб по сети не стоит почти ничего.

Стоит время, и много, когда его уже нет

В статье пишется, что нужно было загрузить 8Тб на скорости 30Мбит. Это порядка 600 часов, или 24 дня. Даже на скорости 100Мбит ушло бы 7 дней. В итоге, как я понял, загрузили напрямую с Google Диска, о чём собственно и написана статья.

Берем два делаем raid1, надежно

я тоже так думал, только вот из-за бага в биосе через месяц все данные на диске превратились в кашу. понятно что не надо сравнивать десктоп и сервер, но все же.

давно было? Просто когда денег на raid стало хватать, ни разу таких проблем ни на десктопах, ни на серверах не встречал

НЛО прилетело и опубликовало эту надпись здесь
ИМХО, основная проблема показанного подхода в осуществлении опасных операций (удаления) сразу при проходе по страницам.
Я бы делал в три этапа:
1) Собирал два списка с id видео с обеих сервисов
2) Сравнивал два списка, заодно проверив их реальное содержимое и количество элементов
3) И уже только имея готовый сформированный список id на удаление запускал по нему саму процедуру удаления.

Вот кстати да, это было первое что я заметил в скрипте. Причём каждый запуск он бы перекачивал всё заново. Гораздо логичнее выкачать данные (первый кэш), обработать собрав список «действий» (второй кэш), и запустить действия на выполнение. Тогда при сбое на третьем этапе не придётся заново выполнять предыдущие. Ну и результат валидировать поэтапно (вручную при необходимости).

Я сильно привык к React и почему-то думал, что url обновится, как только изменится page. Конечно, это не так.

На всякий случай напоминаю, что в React никакой url бы не обновился автоматически тоже.

и правда какой-то бред... как url обновится? :)

ладно если в page лежит какой-то обсервабл, и на изменение его меняется url, но код иначе бы выглядел... я сейчас не про реакт, конечно — сама суть, реактивная природа просто так в коде не появляется... она выражена кучей сущностей фреймворка :)

Поставщик громких историй: школа SkillFactory :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий