Если для лабы то сойдет. Если для жизни и учесть все нюансы то вы сейчас изобретете недоTCP, который кстати и изобретался для надежной доставки в ненадежных сетях с высоким латенси и потерями, за счет пенальти по скорости и оверхедам по пакетам.
Понимаете, не всегда безопасность кода является определющей характеристикой. Есть еще такая вешь как производительность.
И пока падение производительности на обеспечение безопасности будет не нулевым — будут жить низкоуровневые языки типа С/С++.
У меня сейчас задержка в пару миллисекунд на алокацию памяти — критична, если я еще все эти гигабайты буду занулять где ни надо.
А есть еще всякие технологии ZeroCopy разные DPDK.
Вам критична безопасность? ОК берем и пишем на Расте… А да, напомните компилятoр Rust на каком языке написан? Вы уверены что там «уязвимостей» нет? а то вон OpenSSL тоже использовали.
Нет. Нет и нет.
У вас тут считанные наносекунды, там считанные наносекунды, здесь еще немного, здесь «на всякий случай» и вот уже Опера кушает гигабайты ОЗУ и рендерит страничку несколько секунд.
«Весь интернет» это не весь мир софта. И оттого что ктото лажанул при написании очень популярного софта тащить лишние вещи…
Вот поэтому сейчас куча софта работает как бог на душу положит и какой нибудь тупенький браузер расходует тьму ресурсов: «сейчас у процессоров много ядер».
С++ достаточно низкоуровневый язык, а уж С и подавно. Ненадо в язык тащить какие то дополнительные действия, только потому, что какой то программер в критичном месте забыл чтото обнулить.
Непонятно при чем тут язык программирования как таковой? Языки создаются для разных средств и задач. А так на Бейсике нет работы с памятью и запускается в песочнице интерпретаторе. Давайте все кодить на бейсике!
Да язык С/С++ сложный и становится все сложнее. А значит шансов выстрелить себе в ногу больше чем у других языков. И? Это всего лишь один из языков. Не нравится / не подходит — выбирайте другой… А так с/с++ уж с восьмидесятых годов как умирает да все не помрет никак. Не дождетесь!!!
Здесь под термином «сложная задача» подразумевается некое исследование? Или это просто задача, срок выполнения которой сложно спрогнозировать, например, из-за отсутствия опыта решения таких задач?
Дак это одно и тоже в реальном мире: — эту задачу непонятно как решать и в какие сроки, а уж причина может быть любая — либо эту задачу никто не решал, или решил, но нам про это ничего не известно. Поэтому у нас нет известных хотябы примерно путей решения и оценок.
Какая то статья не о чем. Кратко: оказалось, что наши программисты запутались в собственном коде.
Какой-то манифест Make it simple stupid получился.
А на деле надо было разобраться почему неправильно использовались инструменты языка. А то "пренебрежение типобезопасностью" и проблемы с синхронизацией потоков наводят на мысли о кривой архитектуре. Ну и как вишенка — детские болезни с переопределением операторов. А auto и полиморфизм где не надо уже моло что мог испортить
А зачем? все эти «метрики» «бизнес-процессы» они для получения прибыли. Бизнесу не нужен «довольный программист» бизнесу нужны деньги. Если довольный программист приносит денег на Х больше, чем недовольный, причем Х должен быть больше чем надо потратить чтобы сделать довольного программиста из недовольного — это хорошо и бизнес будет строить красивые офисы, приносить печеньки и прочая «нематериальная мотивация».
Бизнесмены они не меценаты — поэтому мы, программеры — ресурс который надо доить.
Вот и появляется больше различных методик как поменьше кормить и побольше доить. Только программеры больно умные: на лапшу про «командный игрок» не сильно ведутся, да творческие: не понимая как создают что-то из воздуха. Поэтому обычные не подходят — придумывают необычные.
Но справедливости ради, в РФ авторские права не отчуждаемы, а вот право распоряжаться результатами и получать с этого доход отчуждается за «авторское вознаграждение». Т.е сделать так чтобы вы стали «неавтором» — нельзя.
Подойдет любая SAN (FC или iSCSI) обеспечивающая достаточный объем при приемлимой для оператора плотности с достаточной пропускной способностью и гарантированным временем отклика. Причем даже IOPS много не надо.
Вот только надо чтобы оно получало данные и отвечало на запросы по регламентированным протоколам.
Вы как минимум не в теме про пакет Яровой, от слова совсем, а как максимум не сотрудник.
В приказе по пакету Яровой хранение трафика передачи данных сроком от 30 дней, а голосовой трафика полугода с увеличением объема на 15 % год.
Однако строго оговорено, что хранение контента не более полугода.
Так что для ваших 100 гигабит на 30 дней вполне достаточно 32,4 ПБ хранения. Это всего 6-9 стоек. О каких датацентрах идет речь?
Поверьте, на вашу приватность — всем плевать. Особенно плевать разработчикам мессенджеров. Если вы будете анонмны то как продавать вашу персональную информацию, информацию о ваших предпочтениях, рекламу наконец? Как на вас деньги зарабатывать?
Вот как раз возможностей лоббировать у аж целых всех трех операторов хоть отбавляй.
И не важно сколько и чего хранить надо бы. Важно вам тариф задрать под эту лавочку, сказав «не виноватая я». И ни какого картельного сговора тут нет.
Поддержу. Закон крайне выгоден операторам — давить звонки через мессенджеры, смс-ки через месенджеры. Трафик шейпить и прогнозировать. Рекламу рассылать вам и вашим контактам. Да чего только не придумать.
На самом деле если говорить про FTS индексаторы, то сейчас де факто стандарт это:
Библиотека Apache lucene и построенные на ней Elastic и Solr. Причем если вам не нужно горизонтальное масштабирование — я бы советовал Solr — там версии lucene посвежей, а elastic получше с кластерностью.
Sphinx: отечественный, не очень кластерный, но шустрее за счет с++ и кучи оптимизаций.
Но в принципе под капотом одинаково: токенайзер => стемминг/словарь => инвертированный индекс
5 млн… записей это не большие данные.
На сервере класса HP gen9 elastic переваривает индексацию Bulk потоком 5-10 мегабайт/секунду практически из коробки. Если у вас запись под килобайт то пережует он эти 5 млн записей по килобайту за 7-15 минут.
Но никто не отменял апдейты и партиционирование.
Любой процес он не про скорость, любой процесс он про предсказуемость. И чем выше требуется предсказуемость (особенно с учетом, что могли ошибиться в вводных данных) тем выше ответственность на каждом участке — тем более забюрократизирован будет процесс, и тем выше стоимость.
А в IT эта проблема всплывает, так как ошибка из-за незрелого процесса не вносит диких затрат на этапе внедрения. Потому что можно «тяп-ляп и в продакшен» а если чего то DevOps поможет быстренько доставить фикс до заказчика.
И вот бизнес сидит и управляет рисками… толи по-быстрому выкатится и начать грести бабло лопатой пока конкуренты не очухались. Толи waterfall-ить по-черному чтобы снизить потери если что-то пойдет не так.
И да в эпоху облаков и тонких клиентов это таки работает впрочем не везде и DevOps тут ни разу нипричем.
Как пример: компания разрабатывающая прошивки для автомобильных «головных устройств» у которых если что прошивку по воздуху не обновить — и обновление это отзывная компания по всему миру. Там как раз и надо «capacity, event, etc mngt.»
Если для лабы то сойдет. Если для жизни и учесть все нюансы то вы сейчас изобретете недоTCP, который кстати и изобретался для надежной доставки в ненадежных сетях с высоким латенси и потерями, за счет пенальти по скорости и оверхедам по пакетам.
Да появятся ремесленники от программирования, потом их заменят автогенераторами, но «художники» которые смогут реализовать идею «изящно» всегда будут.
На самом деле чтобы не говорили — я знаю кучу ОС написаных на плюсах, но ниодной написаной на Расте. Да и браузер только один… вроде.
И пока падение производительности на обеспечение безопасности будет не нулевым — будут жить низкоуровневые языки типа С/С++.
У меня сейчас задержка в пару миллисекунд на алокацию памяти — критична, если я еще все эти гигабайты буду занулять где ни надо.
А есть еще всякие технологии ZeroCopy разные DPDK.
Вам критична безопасность? ОК берем и пишем на Расте… А да, напомните компилятoр Rust на каком языке написан? Вы уверены что там «уязвимостей» нет? а то вон OpenSSL тоже использовали.
У вас тут считанные наносекунды, там считанные наносекунды, здесь еще немного, здесь «на всякий случай» и вот уже Опера кушает гигабайты ОЗУ и рендерит страничку несколько секунд.
«Весь интернет» это не весь мир софта. И оттого что ктото лажанул при написании очень популярного софта тащить лишние вещи…
Виноват не «Си», а кривые руки програмиста.
С++ достаточно низкоуровневый язык, а уж С и подавно. Ненадо в язык тащить какие то дополнительные действия, только потому, что какой то программер в критичном месте забыл чтото обнулить.
Да язык С/С++ сложный и становится все сложнее. А значит шансов выстрелить себе в ногу больше чем у других языков. И? Это всего лишь один из языков. Не нравится / не подходит — выбирайте другой… А так с/с++ уж с восьмидесятых годов как умирает да все не помрет никак. Не дождетесь!!!
Дак это одно и тоже в реальном мире: — эту задачу непонятно как решать и в какие сроки, а уж причина может быть любая — либо эту задачу никто не решал, или решил, но нам про это ничего не известно. Поэтому у нас нет известных хотябы примерно путей решения и оценок.
Какая то статья не о чем. Кратко: оказалось, что наши программисты запутались в собственном коде.
Какой-то манифест Make it simple stupid получился.
А на деле надо было разобраться почему неправильно использовались инструменты языка. А то "пренебрежение типобезопасностью" и проблемы с синхронизацией потоков наводят на мысли о кривой архитектуре. Ну и как вишенка — детские болезни с переопределением операторов. А auto и полиморфизм где не надо уже моло что мог испортить
Бизнесмены они не меценаты — поэтому мы, программеры — ресурс который надо доить.
Вот и появляется больше различных методик как поменьше кормить и побольше доить. Только программеры больно умные: на лапшу про «командный игрок» не сильно ведутся, да творческие: не понимая как создают что-то из воздуха. Поэтому обычные не подходят — придумывают необычные.
Вот только надо чтобы оно получало данные и отвечало на запросы по регламентированным протоколам.
В приказе по пакету Яровой хранение трафика передачи данных сроком от 30 дней, а голосовой трафика полугода с увеличением объема на 15 % год.
Однако строго оговорено, что хранение контента не более полугода.
Так что для ваших 100 гигабит на 30 дней вполне достаточно 32,4 ПБ хранения. Это всего 6-9 стоек. О каких датацентрах идет речь?
И не важно сколько и чего хранить надо бы. Важно вам тариф задрать под эту лавочку, сказав «не виноватая я». И ни какого картельного сговора тут нет.
Но в принципе под капотом одинаково: токенайзер => стемминг/словарь => инвертированный индекс
На сервере класса HP gen9 elastic переваривает индексацию Bulk потоком 5-10 мегабайт/секунду практически из коробки. Если у вас запись под килобайт то пережует он эти 5 млн записей по килобайту за 7-15 минут.
Но никто не отменял апдейты и партиционирование.
Любой процес он не про скорость, любой процесс он про предсказуемость. И чем выше требуется предсказуемость (особенно с учетом, что могли ошибиться в вводных данных) тем выше ответственность на каждом участке — тем более забюрократизирован будет процесс, и тем выше стоимость.
А в IT эта проблема всплывает, так как ошибка из-за незрелого процесса не вносит диких затрат на этапе внедрения. Потому что можно «тяп-ляп и в продакшен» а если чего то DevOps поможет быстренько доставить фикс до заказчика.
И вот бизнес сидит и управляет рисками… толи по-быстрому выкатится и начать грести бабло лопатой пока конкуренты не очухались. Толи waterfall-ить по-черному чтобы снизить потери если что-то пойдет не так.
И да в эпоху облаков и тонких клиентов это таки работает впрочем не везде и DevOps тут ни разу нипричем.
Как пример: компания разрабатывающая прошивки для автомобильных «головных устройств» у которых если что прошивку по воздуху не обновить — и обновление это отзывная компания по всему миру. Там как раз и надо «capacity, event, etc mngt.»