Здравствуйте, Cyberax, Вы писали:

C>Или тем, кому реально нужна availability.
Это смотря что понимать под availability. Проблема в том, что даже тем, кому availability нужна CAP не сильно помогает.

C> Например, в этом году хранилище данных для Amazon в тестах обрабатывало в пике 1 миллиард запросов в секунду. Реальная пиковая нагрузка была где-то треть от этого.
Кул! Не, реально круто. То есть, для Amazon понятие Availability означает пропускная способность в конкретных числовых характеристиках — миллиард запросов в секунду. Заметьте, даже не время отклика на один запрос, а общая пропускная способность системы.
Является ли это availability в терминах CAP? А х.з. так как там каждый понимает это по своему, а с формальным определением — печаль. Но скорее всего нет, так как CAP про пропускную способность вообще ничего не говорит, а оперирует только одним запросом. То есть она вообще про другое.

Здравствуйте, Denis Ivlev, Вы писали:

DI>И как это горизонтально масштабируется?
А при чем тут масштабирование и какое это все имеет отношение к обсуждаемому вопросу? Предлагаю не путать теплое с мягким и с фокусироваться на availability и consistency в терминах CAP. Масштабирование — это другой вопрос, к CAP отношения не имеющий.

DI>Никак что-ли? А зачем оно тогда надо?
А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение. В данном случае решение уже с масштабировано, но это масштабирование сделано не с целью увеличить пропускную способность, а с целью дать внятный ответ с большей гарантией.
Если достать голову из мира где в угоду быстрому ответу приносится в жертву вообще все, то failover кластера придумали вовсе не от скуки, а потому что такие решения тоже очень востребованы. И, что характерно, они как раз про доступность. С другой стороны, возвращаясь к теме топика, являются ли такие решения доступными в терминах CAP? Да фиг знает, но с точки зрения формального доказательства скорее нет. Являются ли такие решения доступными в практическом плане? Однозначно да, их доступности и одна машина позавидовать может, так как они отвечают не только при сетевом сбое, но и при любой другой проблеме с одним узлом. Более того ответ такой системы всегда консистентен, то есть в практическом смысле это CA система.
Утверждать что такие системы не нужны — смело, но глупо.

CAP дает возможность классифицировать распределенные системы (CA, CP, AP в http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP и пункты 3.2.1 — 3.2.3 в http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf). Но эти классы распределенных систем являются крайними случаями. Реальные системы или их части могут занимать промежуточное положение или быть гибридными. Так как:

Consistency — в теореме сформулировано требованием, того чтобы во всех вычислительных узлах в любой момент времени данные не противоречат друг другу. То есть устаревание кэша узла распределенной БД не допускается. На практике считается допустимым и даже необходимым, если конечные пользователи видят устаревшие данные. Если данные на мониторе будут меняться 20 раз в секунду, пользователю это не понравится. Но слишком устаревшие данные тоже плохо. Так что это требование на практике не формализуемо, завит от того какие именно данные имеются ввиду и кем они используются. Если из за использования устаревших данных была произведена некорректная транзакция, то такая транзакция откатывается. На практике это допустимо.

Availability — в теореме сформулировано требованием, того чтобы любой запрос к распределённой системе завершается корректным откликом. Это означает, что если удаленный ресурс не может выполнить запрос он должен сказать об этом, а не молчать. На практике на запросы к удаленным ресурсам ставятся таймауты. Если сработал таймаут пользователю либо предлагается сделать запрос позже, либо запрос ставится в очередь и с заданным интервалом времени делаются повторные попытки сделать запрос.

Partition tolerance — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций. Это значит, что если вы записали в одну из изолированных секций (секция — это множество узлов, между которым есть связь), а в другой секции потом читаете, Вам должны четко сказать что чтение в данный момент невозможно (жертвуем Consistency, класс AP) или задержать ответ пока связь между секциями не восстановится (жертвуем Availability, класс CP). На практике для одних данных допустим один вариант, для других другой.

Класс CA это когда в случае разделения системы на изолированные секции полностью блокируется запись во всех узлах всех секций, но чтение остаётся доступным.

Здравствуйте, IB, Вы писали:

IB>А при чем тут масштабирование и какое это все имеет отношение к обсуждаемому вопросу? Предлагаю не путать теплое с мягким и с фокусироваться на availability и consistency в терминах CAP. Масштабирование — это другой вопрос, к CAP отношения не имеющий.

Это какое-то лукавство, что значит буква P? Partition tolerance. А откуда оно взялось, ведь взять обсуждаемую архитектуру: все запросы идут в одну ноду, нода синхронно реплицируется (C), если мастер падает, то мастером становится реплика (А) и все запросы теперь идут через нее. Где тут Р? И откуда Р появилась? Ну видимо оттуда, что все запросы в одну ноду стали узким местом и пришлось пустить запросы по разным нодам. Утверждать что это не так — смело, но глупо.

Здравствуйте, IB, Вы писали:

IB>А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение.
Зависит от задачи. В общем случае failover это только часть availability.
Более точно будет
failover + scalability = availability
Т.е. когда стоит задача "обрабатывать 1млрд запросов в секунду" и чтобы было availability, то никакой failover не поможет.

Здравствуйте, IB, Вы писали:

C>> Например, в этом году хранилище данных для Amazon в тестах обрабатывало в пике 1 миллиард запросов в секунду. Реальная пиковая нагрузка была где-то треть от этого.
IB>Кул! Не, реально круто. То есть, для Amazon понятие Availability означает пропускная способность в конкретных числовых характеристиках — миллиард запросов в секунду. Заметьте, даже не время отклика на один запрос, а общая пропускная способность системы.

это не понятие availability, это thoughput

IB>Является ли это availability в терминах CAP? А х.з. так как там каждый понимает это по своему, а с формальным определением — печаль. Но скорее всего нет, так как CAP про пропускную способность вообще ничего не говорит, а оперирует только одним запросом. То есть она вообще про другое.

нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи

Здравствуйте, chaotic-kotik, Вы писали:

CK>это не понятие availability, это thoughput
Верно. Но не я тут эту характеристику в качестве критерия availability привел, а Амазон. Значит, для амазона это и есть availability.
Собственно, возвращаясь к моему поинту — в реальной жизни это вполне понятный критерий на основе которого можно сторить систему, в отличии от CAP, где даже внятного определения availability нет, и понимай как хочешь.

CK>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило. Таким образом, возвращаясь к предыдущему пункту, критерий "миллиард запросов в секунду", гораздо адекватнее чем CAP.
К слову, про запись CAP тоже ничего не говорит, она говорит, что если с партишеном проблемы, то система либо не гарантирует консистентность, либо не гарантирует ответ. Но ни каких критериев, помогающих понять, что считать проблемами партишена и какой должен быть ответ кап не оговаривает. В чем собственно и проблема.

Здравствуйте, IB, Вы писали:

IB>Собственно, возвращаясь к моему поинту — в реальной жизни это вполне понятный критерий на основе которого можно сторить систему, в отличии от CAP, где даже внятного определения availability нет, и понимай как хочешь.

сорян, но ты похоже действительно понимаешь availability как хочешь

CK>>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
IB>Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило.

Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.

Здравствуйте, chaotic-kotik, Вы писали:

CK>сорян, но ты похоже действительно понимаешь availability как хочешь
Как и все остальные, если речь идет о CAP, так как внятного определения не дано. Амазон, вот, throughput за availability считает, как мы выяснили, и по своему прав.
"In discussions of CAP there are several contradictory definitions of the term availability,
and the formalization as a theorem [30] does not match its usual meaning [40]." (c)
Теперь понятны притензии к CAP?


CK>>>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
IB>>Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило.

CK>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?

Здравствуйте, ·, Вы писали:

IB>>А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение.
·>Зависит от задачи.
Совершенно верно. Поэтому я и прошу дать термину определение, прежде чем им манипулировать.

·>В общем случае failover это только часть availability.
·>Более точно будет
·>failover + scalability = availability
О, вот еще одно определение availability, прямо скажем, довольно смелое. Не затруднит дать определение scalability, для начала? А то ведь это тоже довольно растяжимый термин.
Как я писал выше, failover системы о которых идет речь — уже отмасштабированы, только цель масштабирования другая — отказоустойчивость, а не пропускная способность. Таким образом, эта система уже отказоустойчива и отмасштабирована, то есть, согласно вашему же определению — доступна.

·>Т.е. когда стоит задача "обрабатывать 1млрд запросов в секунду" и чтобы было availability, то никакой failover не поможет.
А failover и не должен в этом помогать, он про другое. Собственно, мой поинт был про то, что если система не про бешенную пропускную способность, то это не значит, что она никому не нужна, если посмотреть шире, то есть масса других сценариев, не менее сложных и интересных.
И, собственно, возвращаясь к CAP (напоминаю, мы все еще разговариваем о CAP), то в этом правиле никакого требования про "миллиард запросов в секунду" — нет. Там вообще термин availablity описан довольно не внятно, в чем собственно и проблема.

Здравствуйте, Denis Ivlev, Вы писали:

IB>>А при чем тут масштабирование и какое это все имеет отношение к обсуждаемому вопросу? Предлагаю не путать теплое с мягким и с фокусироваться на availability и consistency в терминах CAP. Масштабирование — это другой вопрос, к CAP отношения не имеющий.

DI>Это какое-то лукавство, что значит буква P? Partition tolerance. А откуда оно взялось, ведь взять обсуждаемую архитектуру: все запросы идут в одну ноду, нода синхронно реплицируется (C), если мастер падает, то мастером становится реплика (А) и все запросы теперь идут через нее. Где тут Р? И откуда Р появилась? Ну видимо оттуда, что все запросы в одну ноду стали узким местом и пришлось пустить запросы по разным нодам. Утверждать что это не так — смело, но глупо.
Смело, но глупо, утверждать что это так =) Если я правильно расшифровал вашу логическую цепочку, то вы ставите знак равенства между Partition и Scalability и по вашему они означают одно и тоже. Допустим это так. Но тогда ваши претензии к failover системам не состоятельны, так как partition там уже присутствует, а значит они scalable согласно вашему же определению.

Здравствуйте, IB, Вы писали:

IB>Смело, но глупо, утверждать что это так =)

Вы снова что-то понаписали, но проигнорировали прямые вопросы, это уже даже не смело, а просто глупо — пытаться оставить последнее слово за собой.

IB>Если я правильно расшифровал вашу логическую цепочку, то вы ставите знак равенства между Partition и Scalability и по вашему они означают одно и тоже.

Я это не говорил, я говорил, что горизонтальное Scalability вытекает из Partition, никак по другому горизонтально масштабироваться не получится.

IB>Но тогда ваши претензии к failover системам не состоятельны

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

IB>так как partition там уже присутствует, а значит они scalable согласно вашему же определению.

Это вообще к чему?

Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?

Здравствуйте, IB, Вы писали:

IB>Как и все остальные, если речь идет о CAP, так как внятного определения не дано. Амазон, вот, throughput за availability считает, как мы выяснили, и по своему прав.
мы это не выяснили, это ты почему-то написал, что амазаон throughput за availability считает, в ответ на утверждение о том, что амазон сколько то там запросов в секунду умеет обрабатывать, что есть non sequuntur

IB>"In discussions of CAP there are several contradictory definitions of the term availability,
IB>and the formalization as a theorem [30] does not match its usual meaning [40]." (c)
IB>Теперь понятны притензии к CAP?

Совершенно согласен, дискуссии о САР действительно обычно содержать разные противоречящие определения availability, Клипман все правильно написал


CK>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
IB>То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?

Как это может быть ответом на мой комментарий? И нет, не согласен.

Здравствуйте, Denis Ivlev, Вы писали:

DI>Это вообще к чему?
DI>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?

А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.

Здравствуйте, IB, Вы писали:

IB>>>А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение.
IB>·>Зависит от задачи.
IB>Совершенно верно. Поэтому я и прошу дать термину определение, прежде чем им манипулировать.
А чем тебя не устраивает хотя бы то что в вики?
Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write

IB>·>В общем случае failover это только часть availability.
IB>·>Более точно будет
IB>·>failover + scalability = availability
IB>О, вот еще одно определение availability, прямо скажем, довольно смелое. Не затруднит дать определение scalability, для начала? А то ведь это тоже довольно растяжимый термин.
Прошу прощения, я не претендовал дать определение, а просто пояснял как понимать этот термин более правильно.
В данном случае сценарий довольно простой: посылаем системе 1млрд запросов за одну секунду и ожидаем получить non-error ответ на каждый запрос. Построить такую available систему без scalability не выйдет, как минимум по технологическим причинам, или даже по физическим.

IB>Как я писал выше, failover системы о которых идет речь — уже отмасштабированы, только цель масштабирования другая — отказоустойчивость, а не пропускная способность. Таким образом, эта система уже отказоустойчива и отмасштабирована, то есть, согласно вашему же определению — доступна.
Я не понимаю каким образом ты базируешь failover на scalability. Это тёплое на мягком. Масштабирование это именно про нагрузку:
Scalability is the property of a system to handle a growing amount of work by adding resources to the system.

IB>·>Т.е. когда стоит задача "обрабатывать 1млрд запросов в секунду" и чтобы было availability, то никакой failover не поможет.
IB>А failover и не должен в этом помогать, он про другое. Собственно, мой поинт был про то, что если система не про бешенную пропускную способность, то это не значит, что она никому не нужна, если посмотреть шире, то есть масса других сценариев, не менее сложных и интересных.
Эээ.. Ну да. Только какие сценарии ни бери, CAP нарушить не удастся.

IB>И, собственно, возвращаясь к CAP (напоминаю, мы все еще разговариваем о CAP), то в этом правиле никакого требования про "миллиард запросов в секунду" — нет. Там вообще термин availablity описан довольно не внятно, в чем собственно и проблема.
CAP теорема позволяет в такой ситуации сделать вывод — что невозможно построить CA-систему в таком сценарии, как бы тебе ни хотелось — только либо A, либо C.

Здравствуйте, Sharov, Вы писали:

DI>>Это вообще к чему?
DI>>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?
S>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
Напомню: Scalability is the property of a system to handle a growing amount of work by adding resources to the system
Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
failover тут вообще не в тему.

Здравствуйте, Sharov, Вы писали:

S>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.

У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

Здравствуйте, Denis Ivlev, Вы писали:

S>>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
DI>У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

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

Здравствуйте, ·, Вы писали:

S>>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
·>Напомню: Scalability is the property of a system to handle a growing amount of work by adding resources to the system
·>Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
·>failover тут вообще не в тему.

Благодарю, понял.

Здравствуйте, Sharov, Вы писали:

S>>>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
DI>>У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

S>Не понял, речь шла о масшабируемости в случае падения мастера...

Если не понял, можно спросить. Обсуждение началось с этого:

— В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

— И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

S>В сценарии выше иметь необходимое кол-ов серверов для обработки в избытке.

Еще раз. У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К. Как ты имея одну точку входа, которая физически не способна обработать поток запросов, эти самые запросы обработаешь?