Вот мало ли что там Ауди/БМВ/Порш напридумывали. А что мы, наши, отечественные гении, импортозамещенные - что придумали?
Что там в Москвиче, Ладе, КАМАЗе, УАЗе, е-мобиле - их как проектировали? Над чем думали их инженеры? Что из свеженького придумали? Автомобиль без GPS и мобильного интернета?
Не знал, что макеты из пластилина делают - почему не на 3-d принтере печатать?
Неужели и законы и даже Конституцию РФ надо?... Кто бы мог подумать... Или это только иностранным вендорам надо соблюдать? Было бы интересно ознакомиться со списком законов, которые они нарушили.
Erasure Coding, где избыточность снижается с ×3 до ×2
Избыточность RS(6,3) всего 1,5 а не 2. Т.е. классическая репликация блока х3 - у вас 1 блок с данными и 2 блока реплик, vs 6 блоков с данными + 3 блока контроля (9 суммарно). Google для "холодных данных" (партиций в BigQuery) которые не менялись более 90 дней применяет RS(6,9) на уровне файловой системы (Colossus) - и предлагает "скидку" - 50% на storage )) Никакая это конечно не скидка, просто клиенты платят именно за то, сколько места занимают фактически данные. Процесс фоновый и "бесплатный" для клиентов, но сразу разложить в RS(6,3) нельзя, как и поменять период. Любое изменение - и все возвращается обратно к репликации х3, потому как даже если изменение в 1 блоке, переписать нужно все 9, а оно надо? Но storage очень дёшев.
RS(6,3) в 2 раза эффективнее репликации х3 - это так, но не "избыточность".
Согласен с предыдущим комментарием, что не раскрыта тема борьбы за мс + я понимаю, что хабр не научное издание и пруфов не требует, но... графики бы, логи, что-то помимо текста + цифр, в которых и ошибки могут быть.
Согласен. Можно в статье спокойно менять "OLAP" на что-то другое, типа DWH и будет ещё одна статья )) Эффективная обработка данных, надёжность, бла-бла-бла... Сейчас стал чаще chatGPT использовать, чтобы какую-то тему поглубже прокопать на первом этапе и уже потом по ссылкам на документацию вендора. Habr, CodeProject будут нужны только для не технических статей, техники останется 0.
Первый: любое решение в архитектуре - это компромисс.
С плюсами всегда в наборе получаешь минусы. Нужно понять, какие архитектурно-значимые функциональные требования критичны и какие нефункциональные требования порождают. Далее - ранжирование по критичности (требования могут быть диаметрально противоположными: хочу чтобы система выдерживала 1млн запросов/сек - high throughput и задержка ответа составляла не более 10мс - low latency) и подбор паттерна, который лучше подходит для выполнения критичных требований.
Фиксация минусов и проработка, чем их нивелировать или какие риски нужно принять (иногда достаточно просто о них знать, так как они могут проявляться в каком-то изменившемся контексте или новых требованиях).
Вот мало ли что там Ауди/БМВ/Порш напридумывали. А что мы, наши, отечественные гении, импортозамещенные - что придумали?
Что там в Москвиче, Ладе, КАМАЗе, УАЗе, е-мобиле - их как проектировали? Над чем думали их инженеры? Что из свеженького придумали? Автомобиль без GPS и мобильного интернета?
Не знал, что макеты из пластилина делают - почему не на 3-d принтере печатать?
Статья хорошая, автомобили то будут? ))
Неужели и законы и даже Конституцию РФ надо?... Кто бы мог подумать... Или это только иностранным вендорам надо соблюдать? Было бы интересно ознакомиться со списком законов, которые они нарушили.
Есть несколько вопросов:
1) Какой у вас дневной инкремент в hdfs (порядок - гигабайты/терабайты)?
2) Что вы товарищу майору покажете, когда с локальной файловой системы файл не удастся прочитать после записи, чтобы его в hdfs отправить?
3) Что если завтра товарищ майор попросит достать и показать историю тех сообщений, которые не были помечены специальным флагом?
4) Как часто схема сообщений мутирует и что с этим делаете?
5) Почему в hdfs репликация X3 а не RS(6,3) с X1,5?
6) Что если не надёжна не только сеть, но и Data Center tier III?
Спасибо за статью, пара моментов:
Избыточность RS(6,3) всего 1,5 а не 2. Т.е. классическая репликация блока х3 - у вас 1 блок с данными и 2 блока реплик, vs 6 блоков с данными + 3 блока контроля (9 суммарно). Google для "холодных данных" (партиций в BigQuery) которые не менялись более 90 дней применяет RS(6,9) на уровне файловой системы (Colossus) - и предлагает "скидку" - 50% на storage )) Никакая это конечно не скидка, просто клиенты платят именно за то, сколько места занимают фактически данные. Процесс фоновый и "бесплатный" для клиентов, но сразу разложить в RS(6,3) нельзя, как и поменять период. Любое изменение - и все возвращается обратно к репликации х3, потому как даже если изменение в 1 блоке, переписать нужно все 9, а оно надо? Но storage очень дёшев.
RS(6,3) в 2 раза эффективнее репликации х3 - это так, но не "избыточность".
Согласен с предыдущим комментарием, что не раскрыта тема борьбы за мс + я понимаю, что хабр не научное издание и пруфов не требует, но... графики бы, логи, что-то помимо текста + цифр, в которых и ошибки могут быть.
Согласен. Можно в статье спокойно менять "OLAP" на что-то другое, типа DWH и будет ещё одна статья )) Эффективная обработка данных, надёжность, бла-бла-бла... Сейчас стал чаще chatGPT использовать, чтобы какую-то тему поглубже прокопать на первом этапе и уже потом по ссылкам на документацию вендора. Habr, CodeProject будут нужны только для не технических статей, техники останется 0.
Первый: любое решение в архитектуре - это компромисс.
С плюсами всегда в наборе получаешь минусы. Нужно понять, какие архитектурно-значимые функциональные требования критичны и какие нефункциональные требования порождают. Далее - ранжирование по критичности (требования могут быть диаметрально противоположными: хочу чтобы система выдерживала 1млн запросов/сек - high throughput и задержка ответа составляла не более 10мс - low latency) и подбор паттерна, который лучше подходит для выполнения критичных требований.
Фиксация минусов и проработка, чем их нивелировать или какие риски нужно принять (иногда достаточно просто о них знать, так как они могут проявляться в каком-то изменившемся контексте или новых требованиях).