Комментарии 19
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я описал реальный пример иллюстрирующий те условия, которые актуальны на многих наших проектах. Для других систем требования могут меняться. Очень может быть, что модель останется той же, просто если у нас срок загрузки максимальный = 1 сутки, то в другой системе = 1 часу, например. Но суть, возможно, не поменяется от этого.
Не могу же я придумывать примеры для китайцев под каждый возможный временной дедлайн в самом деле )))
скорее всего просто нужно под соотвествующий дедлайн оценить экспериментально/аналитически нужный объем железа, чтобы обслужить прогнозируемый поток запросов.
В любом случае, владелец системы будет стоять перед выбором — меньшая эффективность использования железа/ресурсов vs более длительное обслуживание запросов.
>> Представьте что до крайнего срока успешно загружены 80% налоговых деклараций по прибыли. Что будет с остальными 20%?
я не очень представляю последствия того, что декларации не загружены до крайнего срока. Напишите, плз,
— какой вообще срок дается на загрузку?
— если срок прошел, то что будет? штраф? какого размера?
Не могу же я придумывать примеры для китайцев под каждый возможный временной дедлайн в самом деле )))
скорее всего просто нужно под соотвествующий дедлайн оценить экспериментально/аналитически нужный объем железа, чтобы обслужить прогнозируемый поток запросов.
В любом случае, владелец системы будет стоять перед выбором — меньшая эффективность использования железа/ресурсов vs более длительное обслуживание запросов.
>> Представьте что до крайнего срока успешно загружены 80% налоговых деклараций по прибыли. Что будет с остальными 20%?
я не очень представляю последствия того, что декларации не загружены до крайнего срока. Напишите, плз,
— какой вообще срок дается на загрузку?
— если срок прошел, то что будет? штраф? какого размера?
НЛО прилетело и опубликовало эту надпись здесь
А если пользоваться облачными ресурсами и просто запускать новые и новые кассы, как только длина очереди превысила Х или время ожидания превысило Y (и гасить обратно после), то не придется гадать, придут ли сегодня все 150млн китайцев или только половина.
НЛО прилетело и опубликовало эту надпись здесь
Увы, нет, полно примеров такого поведения: вышел новый фильм, анонсирован новый продукт, кто-то дал скандальное интервью и на сайт пришло 10 млн человек разом (посмотреть фотки Скарлетт Йохансон в душе), маркетинг запустил рекламу, которая «выстрелила», кто-то из знаменитостей посрался в твиттере. Вот там только малая часть примеров, которая запросто приведет к такой непредсказуемой нагрузке.
Теоретически может быть. С точки зрения денег, тоже должно быть тоже самое, если не лучше.
Знаете ли вы к-н облака, подходящие для размещения ГИС -систем? и еще чтобы там были бы как бы неограниченные ресурсы? те реально можно было рассчитывать на то, что можно онлайн выделить ресурсы под 150 млн китайцев?
Правда, иметь ресурсы — это еще пол дела. Надо чтобы еще система умела масштабироваться, а это штука не очень линейная.
Знаете ли вы к-н облака, подходящие для размещения ГИС -систем? и еще чтобы там были бы как бы неограниченные ресурсы? те реально можно было рассчитывать на то, что можно онлайн выделить ресурсы под 150 млн китайцев?
Правда, иметь ресурсы — это еще пол дела. Надо чтобы еще система умела масштабироваться, а это штука не очень линейная.
Я не очень знаком с российскими предложениями, а так это базовый функционал облачных сервисов — object storage, очереди, load balancing, autoscaling (примерно также, как вы и описали — динамически масштабируемый пул воркеров вычерпывают очередь). В качестве воркеров часто используются всякие serverless решения (типа aws lambda) и контейнеры. Насчет ограниченности ресурсов провайдера — в случае большой тройки они скорее ограничены кошельком клиента :)
serverless решения — это сейчас очень популярное направление, безусловно это круто. К сожалению, сейчас по крайней мере их применение ограничивается ИМХО системами, когда у вас в основном простая stateless логика, оркеструющая 3-d party сервисы… что-то более сложное и к тому же чувствительное по ИБ (пересданные, конфданные и тд) уже не получится сделать (в смысле сделать можно что угодно, но за разумные деньги и чтобы это можно было потом развивать — там ограниченный инструментарий, куча разных телодвижений нужно сделать, чтобы ч-н закодить).
Интересно у вас есть опыт создания serverless? поделитесь… так как у меня только теоретический
Ну те ИМХО пока ГИС вы не сделаете даже на продвинутых Амазонах и гуглах… увы ((( поэтому эти все радости нам пока недоступны ((
Интересно у вас есть опыт создания serverless? поделитесь… так как у меня только теоретический
Ну те ИМХО пока ГИС вы не сделаете даже на продвинутых Амазонах и гуглах… увы ((( поэтому эти все радости нам пока недоступны ((
Вообще в облаках сейчас работают: правительственные органы США (для них в aws есть специальный физически изолированный регион GovCloud), банки (может не прямо основные системы, но много аналитики, расчеты моделей и ETL), конторы по обработке персональных данных и данных пациентов (а в США и Европе это просто адски зарегулировано).
Кажется, вы сейчас смешали AWS и Serverless. Это абсолютно не тождественные понятия. AWS Lambda — Serverless. AWS EC2 — полноценные сервера, на которые вы можете поставить ваш ГИС и скэлить их количество автоматически, в зависимости от количества заявок.
НЛО прилетело и опубликовало эту надпись здесь
Да, только вас-то это уже не волнует — у вас кончились заявки в очереди, вы погасили 1000 инстансов и оставили 1 на выходные (для шальных блудных заявок) и уменьшили свой счет в 1000 раз на это время. А провайдер найдет кому продать освободившиеся ресурсы, за него не будем волноваться. В случае serverless еще веселее — «нет заявок — не платим».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Массовая загрузка данных, или Как накормить китайскую деревню