Сообщение Re[25]: Выбор NoSQL от 20.06.2016 13:37
Изменено 20.06.2016 13:39 chaotic-kotik
Здравствуйте, gandjustas, Вы писали:
CK>>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
G>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже.
Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
G>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
На практике, это важно тогда, когда возможность сохранить данные важнее целостности. Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения. Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
G>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
CK>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>Но тогда появляется гораздо интереснее сценарий.
G>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
G>Ты же сам привел аналогичный пример ниже.
Биллинг можно сделать на чем-нибудь другом. Но можно использовать другую модель данных просто, в которой транзакции не меняют запись в которой содержится текущий счет пользователя а дописывают транзакции пользователя в таблицу, а текущий счет по этой таблице всегда может быть пересчитан. Многие системы будучи АР и eventually consistent, предоставляют гарантию read you're own writes и serializability операций над одним документом/записью, так что это все довольно тривиально реализуется. Я знаю что в одном крупном банке (не скажу каком) биллинг построен на NoSQL решении а не РСУБД.
G>Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
G>>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
CK>>Wat?
G>Твои примеры ниже прекрасно иллюстрируют что я говорю.
Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
G>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Вывод из этого следует такой — нельзя делать системы без partition tolerance.
G>Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
G>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
Tradeoff же.
CK>>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
G>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже.
Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
G>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
На практике, это важно тогда, когда возможность сохранить данные важнее целостности. Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения. Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
G>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
CK>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>Но тогда появляется гораздо интереснее сценарий.
G>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
G>Ты же сам привел аналогичный пример ниже.
Биллинг можно сделать на чем-нибудь другом. Но можно использовать другую модель данных просто, в которой транзакции не меняют запись в которой содержится текущий счет пользователя а дописывают транзакции пользователя в таблицу, а текущий счет по этой таблице всегда может быть пересчитан. Многие системы будучи АР и eventually consistent, предоставляют гарантию read you're own writes и serializability операций над одним документом/записью, так что это все довольно тривиально реализуется. Я знаю что в одном крупном банке (не скажу каком) биллинг построен на NoSQL решении а не РСУБД.
G>Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
G>>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
CK>>Wat?
G>Твои примеры ниже прекрасно иллюстрируют что я говорю.
Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
G>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Вывод из этого следует такой — нельзя делать системы без partition tolerance.
G>Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
G>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
Tradeoff же.
Re[25]: Выбор NoSQL
Здравствуйте, gandjustas, Вы писали:
CK>>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
G>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже.
Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
G>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
На практике, это важно тогда, когда возможность сохранить данные важнее целостности. Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения. Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
G>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
CK>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>Но тогда появляется гораздо интереснее сценарий.
G>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
G>Ты же сам привел аналогичный пример ниже.
Биллинг можно сделать на чем-нибудь другом. Но можно использовать другую модель данных просто, в которой транзакции не меняют запись в которой содержится текущий счет пользователя а дописывают транзакции пользователя в документ, а текущий счет по этой таблице всегда может быть пересчитан. Многие системы будучи АР и eventually consistent, предоставляют гарантию read you're own writes и serializability операций над одним документом/записью, так что это все довольно тривиально реализуется. Я знаю что в одном крупном банке (не скажу каком) биллинг построен на NoSQL решении а не РСУБД.
G>Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
G>>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
CK>>Wat?
G>Твои примеры ниже прекрасно иллюстрируют что я говорю.
Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
G>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Вывод из этого следует такой — нельзя делать системы без partition tolerance.
G>Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
G>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
Tradeoff же.
CK>>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
G>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже.
Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
G>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
На практике, это важно тогда, когда возможность сохранить данные важнее целостности. Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения. Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
G>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
CK>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>Но тогда появляется гораздо интереснее сценарий.
G>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
G>Ты же сам привел аналогичный пример ниже.
Биллинг можно сделать на чем-нибудь другом. Но можно использовать другую модель данных просто, в которой транзакции не меняют запись в которой содержится текущий счет пользователя а дописывают транзакции пользователя в документ, а текущий счет по этой таблице всегда может быть пересчитан. Многие системы будучи АР и eventually consistent, предоставляют гарантию read you're own writes и serializability операций над одним документом/записью, так что это все довольно тривиально реализуется. Я знаю что в одном крупном банке (не скажу каком) биллинг построен на NoSQL решении а не РСУБД.
G>Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
G>>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
CK>>Wat?
G>Твои примеры ниже прекрасно иллюстрируют что я говорю.
Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
G>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Вывод из этого следует такой — нельзя делать системы без partition tolerance.
G>Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
G>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
Tradeoff же.