По хорошему, приложения должны скейлиться операционной системой автоматом. Да, при этом картинки и некоторые элементы могут выглядеть размыто. Но это нормальное поведение по умолчанию. На современных дисплеях такую размытость можно и не заметить, а вот масштабирование шрифта без размытости вполне под силу сделать оконному менеджеру.
При этом, безусловно, надо дать приложению возможность корректно отмасштабировать картинки.
Проблема, однако, в том, что масштабирование полностью положено на плечи разработчика. А автоматическое масштабирование настолько вырвиглазное, что порой проще оставить маленькие буковки.
Весь вопрос в удобстве написания приложений. А удобства — во дворе.
The network is partially synchronous. Обычно сеть себя ведет как асинхронная, тут могут быть проблемы в реальной системе.
Не сказано про network split и борьбу с ошибками. В алгоритме это мало отражено.
Алгоритм формально не верифицирован. Есть вопросы с тем, как он протестирован. По крайней мере я не нашел соответствующей информации.
При этом утверждается, что "The same assumptions are used in PBFT (the most well-known BFT consensus) and its successors." А в статье http://pmg.csail.mit.edu/papers/osdi99.pdf написано про "2 System Model. We assume an asynchronous distributed system where nodes are connected by a network." Это противоречит утверждению об "The same assumptions" и "The network is partially synchronous", что намекает.
Модель хорошая, но боюсь, что из вашей статьи могут сделать неверные выводы
Не надо бояться. Цифра получена исходя из предположений о величинах констант скоростей процессов. Для других величин может получиться другая цифра.
Особенно режет глаза цифра в 100'000'000 лет для кластера в 1000 нод.
Аргументация в стиле: "мне цифра не нравится", конечно, имеет право на существование, но полезность этого крайне сомнительна. Гораздо конструктивнее, если вы найдете, например, изъян в модели и обоснуете его.
Люди могут прочитать, и пойти деплоить кластеры Hadoop на 1000 нод с r=3 и думать, что они могут спать спокойно. Но, например, при выпадении ToR свича вы потеряете сразу всю стойку.
Для этого есть rack awareness, который присутствует во всех уважающих себя крупных системах.
Вообще, мне не очень нравится рассуждать в категориях "а вдруг кто-то что-то подумает".
Плюс заметим, что в используемой у вас LRC-8-2-2 нужно еще и контрольные чанки пересчитать
Очень рад, что вы знаете, что я использую. Может еще расскажете, сколько чанков мы теряем? Думаю, всем было бы интересно.
Поэтому я склонен считать что ваши рассуждения, к сожалению, тоже не верны.
К сожалению, не могу разделить вашу склонность.
Вы учитываете динамику, но не учитываете другие возможные причины отказа — проблемы сетевого оборудования, проблемы питания, возвращение нодами некорректных данных, ошибки памяти, человеческий фактор и т.д.
Давайте я процитирую свою статью. Оказывается, не все в состоянии прочитать написанное.
Конечно, данная модель является лишь первым приближением к тому, что реально происходит на кластере. Здесь мы лишь учитывали наиболее значимые процессы для получения качественного результата…
Ноды кластера могут выходить из строя из-за различных сбоев оборудования. Поломка конкретного узла как правило имеет различную вероятность. Более того, поломка, например, процессора, не теряет данные, а лишь дает временную недоступность ноды…
Добавление в модель нод различных типов: с частично поврежденными дисками, забаненные и др. Например, можно детально проанализировать влияние выключения целой стойки и выяснения характерных скоростей перехода кластера в стационарный режим.
Каждый диск имеет несколько отличающиеся характеристики чтения/записи, включая латентность и пропускную способность. Тем не менее, можно более точно оценивать константы скоростей процессов, интегрируя по соответствующим функциям распределения характеристик дисков...
Если добавить все это в модель, она была бы еще более сложной. Задача стояла в демонстрации нового подхода на вполне понятном и простом примере. Это первый подход к снаряду, который можно и нужно развивать и дополнять.
Скорость репликации задается параметром 50МБ/с. Обычные крутящиеся диски дают производительность на уровне 100МБ/с, а твердотельные еще выше. Таким образом, пропускная способность репликации задает константу скорости репликации k_r. Можно возразить, что пропускная способность репликации не учитывает время, необходимое на первый seek диска, установку соединения и т.п. Эти факторы можно учесть в константе планирования репликации k_s, просто просуммировав соответствующие времена. При этом k_s — это не константа скорости обнаружения, а константа скорости планирования процесса репликации, включая обнаружение, постановку в пул задач, обработку, получение метаинформации и т.п.
Тут есть другой интересный момент: а что будет, если кластер будет настолько большим, что весь объем не сможет равномерно распределиться по всем нодам из-за дискретного характера чанков. Простой расчет показывает, что количество чанков при размере одного чанка 1 МБ в рассматриваемом случае с размером 5 ТБ на ноду будет равно 5 000 000, что с большим запасом покрывает существующие размеры кластеров. Если же окажется, что это не так (очень большие чанки, мало места на дисках и т.п.), то эффективно такое также можно учесть, просто добавив некоторую константу к времени планирования репликации.
В предложенном подходе я хотел продемонстрировать качественный анализ системы без привязки к конкретному железу. Если хочется посчитать для конкретных параметров — то сделать это можно легко, просто подставив соответствующие цифры.
в зависимости от нагрузки на кластере это время может быть довольно значительным, полчаса-час
А может быть и другим. Не суть. Просто получатся другие числа. Модель при этом не поменяется.
Плюс диск не всегда отказывает и исчезает, иногда он начинает просто отдавать битые данные. Диск в наличии, а данные на нем неправильные, на диагностику такой проблемы тоже нужно время.
Да, это действительно проблема. И такое поведение можно включить в модель без проблем.
Вы работаете с реальными кластерами подобных размеров, и сами используете LRC-8-2-2 (то есть можно потерять до 2 реплик из группы без потери данных)
Мы используем разные подходы. Конкретные цифры я бы не хотел называть по понятным причинам. В данной статье используются некоторые цифры, приближенные к какой-то реальности.
В любом случае, я хотел продемонстрировать моделирование и подход, позволяющий делать выводы о поведении системы. Простые подходы и рассуждения, подобные этому, к сожалению, неверны. Думаю, по цифрам и количеству учитываемых факторов становится понятно, почему.
Вы делаете ровно ту же ошибку, что и Клеппман в оригинальной статье. А именно: не учитывается динамика.
Это проявляется в том, что вы неявно предполагаете, что время жизни диска и время жизни чанка — одинаковое. Понятно, что выпадание диска — это выпадание чанков этого диска. Однако характерное время восстановления чанка не совпадает со временем замены дисков и является сильно меньшей величиной. Поэтому даже если во время поломки диска сломается другой с этим же чанком, то это может быть не фатально, т.к. чанк с этого диска уже мог отреплицироваться на третий за существенно меньшее время.
Таким образом, расчет сломанных дисков без учета механизма репликации — странная затея, которая дает фундаментально неверные результаты.
Прямое утверждение, что под A не подразумевается тотальная доступность, а вместо этого имеется ввиду высокая доступность с каким-то там количеством девяток:
Изначальный ваш тезис был "«effectively CA» не использует термины CAP-теоремы". Мне не очень понятно, как он в конце концов свелся к изменению определения для A. Т.е. я не вижу утверждения о том, что буква C используется в другом контексте. Или С использует термин из CAP теоремы? Хочется тут большей определенности, т.е. все ли буквы в контексте «effectively CA» не используют термины CAP-теоремы или только некоторые?
Теперь про цитату про определение «effectively CA», как я уже упоминал выше — это не определение, автор не вводит новых понятий.
Для меня «effectively CA» — это новый термин, т.к. до этого я слышал CA в рамках CAP теоремы. Если мне теперь вводят нечто типа «effectively CA», то я хочу понимания, что означает C и A. Сюда по вашим цитатам, вы так и не смогли найти явного объяснения этих букв и привести соответствующую цитату, объясняющую, что означает буква C из «effectively CA».
Нет, не правильно. Нет, не нахожу. Прямым текстом в статье говорится, что P есть точка.
У вас проблемы с удержанием контекста. Речь про "effective AC", в этой фразе нет P, хотя она должна быть, согласно определениям.
Для конструктивного общения было бы полезно, если бы вы указали, какие тезисы выглядят спорно, чтобы я мог их защищать.
Это работает в другую сторону. Тот, кто приводит аргументацию, её и подкрепляет. Например, я в своей статье сначала привожу дословную цитату, а затем начинаю её разбирать.
Если же приписывать статье всякое без ссылок — то это очень странный способ вести дискуссию.
Более того, касательно исчезнувшей P. В статье этому посвящен целый раздел. Где говорится, что на самом деле, строго формально, P никуда не исчезла, и более того эта самая P реально происходила на практике. НО благодаря их героическим усилиям и куче вложенных в инфраструктуру бабок, вероятность этого P настолько низкая, что на фоне всех других ошибок она не выделяется. Подчеркну, в статье сначала прямым текстом говорится, что P есть, а потом уже автор идет в пространные обсуждения о влиянии этого самого P.
Если я правильно истолковал ваши слова, то она вроде как есть, но вроде как и нет. Т.е. она должна быть, но ее нет. Не находите это несколько странным? Это вопрос к вам.
Вы оспариваете, то что оценка количества девяток для практического использования имеет смысл?
Нет. Я оспариваю качество определений, вводимые в статье. И как следствие, качество самой статьи.
Для конструктивного общения было бы неплохо, чтобы каждое высказывание типа "Автор статьи рассказывает, что ...", "Автор говорит, что" и т.д. были бы приведены прямые цитаты, доказывающие эти тезисы. Так как большинство таких тезисов спорно.
Я задаю эти вопросы в надежде, что вы увидите в рассуждениях автора статьи изъян. Но, судя по всему, вы его видеть в упор не хотите. Ваше право.
Вот давайте разберем ваши комментарии в качестве примера уровня дискуссии.
Я вот прочитал статью, и не увидел, чтобы там вводили такое понятие.
А я вот прочитал и увидел. Сразу вспоминается фраза: "как это — "жопа" есть а слова нет?".
Там используется фраза «effectively CA»
Т.е. для вас, судя по всему, крайне принципиально, что это не понятие, а именно фраза. Это, безусловно, все в корне меняет, т.е. описывать, что означает фраза — не нужно. Ведь это не понятие, верно? А значит можно просто ее использовать, если очень хочется. Такая логика, да?
А разве каждое использование букв C и A обязательно должно иметь отношение к CAP теореме?
А разве нет? Ведь статья называется: "Spanner, TrueTime & The CAP Theorem". Все, кто использует просто отдельные буквы, используют её в контексте CAP теоремы. С этого и начинается статья. И если начать использовать по-другому назначению, то стоит явно указать, что мы эти буквы хотим переопределить, и стоит указать как именно. Ну это если ты хочешь, чтобы тебя поняли. А если не хочешь — то тогда можно писать как попало, все равно схавают. Тем более, прецедент имеется.
В статьте объясняется, что в effectively CA означают C и A: C — означает консистентность как в CAP теореме, а A означает высокую доступность с 5-ю 9-ами, а не ту доступность, о которой идет речь в CAP теореме. И в статье это прямым текстом написано.
И тут хочется спросить: а вы читали мою статью? Ну это где я обсуждал про то, сколько же девяток надо, чтобы называться A "по новому"? Или это не надо специфицировать, и так сойдет?
Для меня тут видится крайне очевидная штука: в рамках CAP теоремы система получается CP. Но тогда сразу возникает вопрос у обывателя: а как же высокая доступность? Чтобы утихомирить обывателя, ему объясняется, что на самом деле доступность — это доступность в рамках девяток. И 5 девяток — это та самая доступность, когда можно сказать "effectively CA".
Разумный человек сразу спросит:
а почему 5 девяток достаточно, а не 6 или 10?
а куда делать буква P?
Меня, например, эти вопросы крайне волнуют. А еще волнует вопрос: а с какого перепугу надо переопределять понятия в CAP теореме? Ведь она сформулирована только для определенных понятий, для других понятий нет смысла говорить о CAP теореме. Надо что-то выбрать одно: либо про теорему, либо про другое. Если же совмещать все вместе, то сразу возникает вопрос: а зачем? И это тот вопрос, который меня мучал на протяжении всей статьи? Ведь если убрать ссылку на CAP теорему и связанное с ней обсуждение, то ничего в статье не поменяется.
И я еще не сказал, что автор просто привел неправильные определения, даже в рамках CAP теоремы.
Если вам нравятся такие статьи — на здоровье. Я хочу сказать лишь следующее. В контексте обсуждений CAP теоремы ходят множество мифов. Как правило, все они связаны с неверным толкованием определений. Добавлять в обсуждение новые толкования без нормального объяснения старых — занятие крайне странное и недальновидное, которое может неподготовленного читателя ввести в заблуждение.
Я лишь попытался обнажить некоторые аспекты, связанные с этой теоремой, на основе современных представлений. И к своему прискорбию могу сообщить, что ни один комментарий не был конструктивен, за исключением этого. Т.е. была приведена правильная ссылка и цитата, из которой был сделан вывод. Все остальное — это толчение в ступе собственных мыслей без понимания простого факта: утверждение должно иметь основу.
Я это писал еще в 2015 году. Тогда еще не наступил с++17. К тому же, не все до сих пор перешли на с++17.
Но так можно сделать, да.
Спасибо, поправил в тексте. В оригинальном коде все ок:
https://github.com/gridem/GodAdapter/blob/master/include/god_adapter/shared.h#L32
Там выше есть определение:
Действительно, так лучше. Поправил.
Очень интересно, буду ждать с++20.
Только возник вопрос с сопрограммами. Разве не должна функция
start_acceptиметь такое определение:По хорошему, приложения должны скейлиться операционной системой автоматом. Да, при этом картинки и некоторые элементы могут выглядеть размыто. Но это нормальное поведение по умолчанию. На современных дисплеях такую размытость можно и не заметить, а вот масштабирование шрифта без размытости вполне под силу сделать оконному менеджеру.
При этом, безусловно, надо дать приложению возможность корректно отмасштабировать картинки.
Проблема, однако, в том, что масштабирование полностью положено на плечи разработчика. А автоматическое масштабирование настолько вырвиглазное, что порой проще оставить маленькие буковки.
Весь вопрос в удобстве написания приложений. А удобства — во дворе.
Я нашел описание на сайте: https://exonum.com/doc/architecture/consensus/#assumptions
На что стоит обратить внимание:
При этом утверждается, что "The same assumptions are used in PBFT (the most well-known BFT consensus) and its successors." А в статье http://pmg.csail.mit.edu/papers/osdi99.pdf написано про "2 System Model. We assume an asynchronous distributed system where nodes are connected by a network." Это противоречит утверждению об "The same assumptions" и "The network is partially synchronous", что намекает.
Ни о какой «увеличении массы» речи не идет.
Очень сильно зависит от параметров кластера. Без конкретных цифр и обстоятельств тут невозможно что-то утверждать более аргументированно.
Не надо бояться. Цифра получена исходя из предположений о величинах констант скоростей процессов. Для других величин может получиться другая цифра.
Аргументация в стиле: "мне цифра не нравится", конечно, имеет право на существование, но полезность этого крайне сомнительна. Гораздо конструктивнее, если вы найдете, например, изъян в модели и обоснуете его.
Для этого есть rack awareness, который присутствует во всех уважающих себя крупных системах.
Вообще, мне не очень нравится рассуждать в категориях "а вдруг кто-то что-то подумает".
Очень рад, что вы знаете, что я использую. Может еще расскажете, сколько чанков мы теряем? Думаю, всем было бы интересно.
К сожалению, не могу разделить вашу склонность.
Давайте я процитирую свою статью. Оказывается, не все в состоянии прочитать написанное.
Если добавить все это в модель, она была бы еще более сложной. Задача стояла в демонстрации нового подхода на вполне понятном и простом примере. Это первый подход к снаряду, который можно и нужно развивать и дополнять.
Скорость репликации задается параметром 50МБ/с. Обычные крутящиеся диски дают производительность на уровне 100МБ/с, а твердотельные еще выше. Таким образом, пропускная способность репликации задает константу скорости репликации k_r. Можно возразить, что пропускная способность репликации не учитывает время, необходимое на первый seek диска, установку соединения и т.п. Эти факторы можно учесть в константе планирования репликации k_s, просто просуммировав соответствующие времена. При этом k_s — это не константа скорости обнаружения, а константа скорости планирования процесса репликации, включая обнаружение, постановку в пул задач, обработку, получение метаинформации и т.п.
Тут есть другой интересный момент: а что будет, если кластер будет настолько большим, что весь объем не сможет равномерно распределиться по всем нодам из-за дискретного характера чанков. Простой расчет показывает, что количество чанков при размере одного чанка 1 МБ в рассматриваемом случае с размером 5 ТБ на ноду будет равно 5 000 000, что с большим запасом покрывает существующие размеры кластеров. Если же окажется, что это не так (очень большие чанки, мало места на дисках и т.п.), то эффективно такое также можно учесть, просто добавив некоторую константу к времени планирования репликации.
В предложенном подходе я хотел продемонстрировать качественный анализ системы без привязки к конкретному железу. Если хочется посчитать для конкретных параметров — то сделать это можно легко, просто подставив соответствующие цифры.
А может быть и другим. Не суть. Просто получатся другие числа. Модель при этом не поменяется.
Да, это действительно проблема. И такое поведение можно включить в модель без проблем.
Мы используем разные подходы. Конкретные цифры я бы не хотел называть по понятным причинам. В данной статье используются некоторые цифры, приближенные к какой-то реальности.
В любом случае, я хотел продемонстрировать моделирование и подход, позволяющий делать выводы о поведении системы. Простые подходы и рассуждения, подобные этому, к сожалению, неверны. Думаю, по цифрам и количеству учитываемых факторов становится понятно, почему.
Вы делаете ровно ту же ошибку, что и Клеппман в оригинальной статье. А именно: не учитывается динамика.
Это проявляется в том, что вы неявно предполагаете, что время жизни диска и время жизни чанка — одинаковое. Понятно, что выпадание диска — это выпадание чанков этого диска. Однако характерное время восстановления чанка не совпадает со временем замены дисков и является сильно меньшей величиной. Поэтому даже если во время поломки диска сломается другой с этим же чанком, то это может быть не фатально, т.к. чанк с этого диска уже мог отреплицироваться на третий за существенно меньшее время.
Таким образом, расчет сломанных дисков без учета механизма репликации — странная затея, которая дает фундаментально неверные результаты.
Очень аргументированно и конструктивно, спасибо.
Изначальный ваш тезис был "«effectively CA» не использует термины CAP-теоремы". Мне не очень понятно, как он в конце концов свелся к изменению определения для A. Т.е. я не вижу утверждения о том, что буква C используется в другом контексте. Или С использует термин из CAP теоремы? Хочется тут большей определенности, т.е. все ли буквы в контексте «effectively CA» не используют термины CAP-теоремы или только некоторые?
Для меня «effectively CA» — это новый термин, т.к. до этого я слышал CA в рамках CAP теоремы. Если мне теперь вводят нечто типа «effectively CA», то я хочу понимания, что означает C и A. Сюда по вашим цитатам, вы так и не смогли найти явного объяснения этих букв и привести соответствующую цитату, объясняющую, что означает буква C из «effectively CA».
Допустим. Не могли бы вы привести тогда:
У вас проблемы с удержанием контекста. Речь про "effective AC", в этой фразе нет P, хотя она должна быть, согласно определениям.
Это работает в другую сторону. Тот, кто приводит аргументацию, её и подкрепляет. Например, я в своей статье сначала привожу дословную цитату, а затем начинаю её разбирать.
Если же приписывать статье всякое без ссылок — то это очень странный способ вести дискуссию.
Если я правильно истолковал ваши слова, то она вроде как есть, но вроде как и нет. Т.е. она должна быть, но ее нет. Не находите это несколько странным? Это вопрос к вам.
Нет. Я оспариваю качество определений, вводимые в статье. И как следствие, качество самой статьи.
Для конструктивного общения было бы неплохо, чтобы каждое высказывание типа "Автор статьи рассказывает, что ...", "Автор говорит, что" и т.д. были бы приведены прямые цитаты, доказывающие эти тезисы. Так как большинство таких тезисов спорно.
Я задаю эти вопросы в надежде, что вы увидите в рассуждениях автора статьи изъян. Но, судя по всему, вы его видеть в упор не хотите. Ваше право.
Вот давайте разберем ваши комментарии в качестве примера уровня дискуссии.
А я вот прочитал и увидел. Сразу вспоминается фраза: "как это — "жопа" есть а слова нет?".
Т.е. для вас, судя по всему, крайне принципиально, что это не понятие, а именно фраза. Это, безусловно, все в корне меняет, т.е. описывать, что означает фраза — не нужно. Ведь это не понятие, верно? А значит можно просто ее использовать, если очень хочется. Такая логика, да?
А разве нет? Ведь статья называется: "Spanner, TrueTime & The CAP Theorem". Все, кто использует просто отдельные буквы, используют её в контексте CAP теоремы. С этого и начинается статья. И если начать использовать по-другому назначению, то стоит явно указать, что мы эти буквы хотим переопределить, и стоит указать как именно. Ну это если ты хочешь, чтобы тебя поняли. А если не хочешь — то тогда можно писать как попало, все равно схавают. Тем более, прецедент имеется.
И тут хочется спросить: а вы читали мою статью? Ну это где я обсуждал про то, сколько же девяток надо, чтобы называться A "по новому"? Или это не надо специфицировать, и так сойдет?
Для меня тут видится крайне очевидная штука: в рамках CAP теоремы система получается CP. Но тогда сразу возникает вопрос у обывателя: а как же высокая доступность? Чтобы утихомирить обывателя, ему объясняется, что на самом деле доступность — это доступность в рамках девяток. И 5 девяток — это та самая доступность, когда можно сказать "effectively CA".
Разумный человек сразу спросит:
Меня, например, эти вопросы крайне волнуют. А еще волнует вопрос: а с какого перепугу надо переопределять понятия в CAP теореме? Ведь она сформулирована только для определенных понятий, для других понятий нет смысла говорить о CAP теореме. Надо что-то выбрать одно: либо про теорему, либо про другое. Если же совмещать все вместе, то сразу возникает вопрос: а зачем? И это тот вопрос, который меня мучал на протяжении всей статьи? Ведь если убрать ссылку на CAP теорему и связанное с ней обсуждение, то ничего в статье не поменяется.
И я еще не сказал, что автор просто привел неправильные определения, даже в рамках CAP теоремы.
Если вам нравятся такие статьи — на здоровье. Я хочу сказать лишь следующее. В контексте обсуждений CAP теоремы ходят множество мифов. Как правило, все они связаны с неверным толкованием определений. Добавлять в обсуждение новые толкования без нормального объяснения старых — занятие крайне странное и недальновидное, которое может неподготовленного читателя ввести в заблуждение.
Я лишь попытался обнажить некоторые аспекты, связанные с этой теоремой, на основе современных представлений. И к своему прискорбию могу сообщить, что ни один комментарий не был конструктивен, за исключением этого. Т.е. была приведена правильная ссылка и цитата, из которой был сделан вывод. Все остальное — это толчение в ступе собственных мыслей без понимания простого факта: утверждение должно иметь основу.
Ответил ниже.