Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не столько для пользы проекта, а чтобы получить опыт для будущих решений, так как с RDBMS уже много чего накушались.
Обзорно читал про NoSQL, но никогда вплотную не использовал. Потратил ещё пару дней на ознакомление, но каждый раз, когда начинаю читать про конкретное решение, возникает ощущение что это не то что нужно.
Ткните, пальцем в алгоритм выбора.
Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке.
Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит.
Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота.
Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями? То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
Что вообще почитать обзорного?
А какие RDBMS использовали?
Сколько данных планируется (1e6, 1e9, 1e12)?
Какой общий объем будет — гигабайты, терабайты?
Какие требования к запросам — только по ключу или сложнее?
Какие требования к скорости чтения/записи?
Какие требования к надежности (можно потерять хоть все, можно потерять операции за несколько секунд и т п.)
Какие требования к HA — какой простой допустим для технических операций, какой в случае проблем с железом?
Ну вот от этого и нужно отталкиваться )
B>Привет,
B> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не столько для пользы проекта, а чтобы получить опыт для будущих решений, так как с RDBMS уже много чего накушались.
B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит.
Обычное key-value — это монга. Вроде бы последний год уже не теряет данные просто так. Или postgresql с колонками типа json (надёжнее, быстрее, сложнее настраивать).
Здравствуйте, Blazkowicz, Вы писали:
B> так как с RDBMS уже много чего накушались. B> ... B> Поэтому пихать много всего в MySQL не охота.
Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
B> ... каждый раз, когда начинаю читать про конкретное решение, возникает ощущение что это не то что нужно.
Это нормально. Если вовремя не остановиться, то (по опыту "успешных" экспериментаторов) есть риск накушаться NoSQL так, что MySQL будет вспоминаться с теплотой.
Здравствуйте, Иль, Вы писали:
Иль>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
А так же с Oracle, SQL Server и, особенно, Firebird.
Иль>Это нормально. Если вовремя не остановиться, то (по опыту "успешных" экспериментаторов) есть риск накушаться NoSQL так, что MySQL будет вспоминаться с теплотой.
Это и моя позиция тоже. Но начальник хочет. А я не против набраться опыта на этом поприще.
Здравствуйте, Alex.Che, Вы писали:
>> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. AC>научная организация?
Нет. Небольшой, относительно успешный стартап.
Здравствуйте, Blazkowicz, Вы писали:
B>Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке. B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. B>Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота. B>Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
MongoDB + GridFS
B>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Аналитика
B>Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями? То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
Все NoSQL решения нет смысла использовать на одной машине
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>А какие RDBMS использовали?
Oracle, MySQL, SQL Server, Firebird. Сейчас есть тенденция к PostgreSQL для новых проектов.
ДФ>Сколько данных планируется (1e6, 1e9, 1e12)?
В штуках?
ДФ>Какой общий объем будет — гигабайты, терабайты?
Грубая и немного оптимистичная оценка говорит, что терабайты.
ДФ>Какие требования к запросам — только по ключу или сложнее?
Пользовательские по ключу. Возможно, будет некоторая внутренняя статистика, которая потребует сканировать все объекты с некоторой периодичностью, чтобы собрать данные. Но если она займет день, то это вполне приемлемо.
ДФ>Какие требования к скорости чтения/записи?
Строгих нет.
ДФ>Какие требования к надежности (можно потерять хоть все, можно потерять операции за несколько секунд и т п.)
Немного строже чем "можно потерять хоть все". Сервис включает платную подписку, такие данные терять можно, но в разумных пределах.
ДФ>Какие требования к HA — какой простой допустим для технических операций, какой в случае проблем с железом?
День, полагаю, допустим.
ДФ>Ну вот от этого и нужно отталкиваться )
Ты меня ещё больше запутал.
B>>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. ДФ>Обычное key-value — это монга. Вроде бы последний год уже не теряет данные просто так. Или postgresql с колонками типа json (надёжнее, быстрее, сложнее настраивать).
MongoDB смущает своим JSON-ом. Если у меня сериализованный бинарник 10Мб, то в JSON он станет только больше.
On 11.05.2016 11:33, Blazkowicz wrote:
> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не > столько для пользы проекта, а чтобы получить опыт для будущих решений, > так как с RDBMS уже много чего накушались.
C NoSQL выбор блюд для кушанья не меньше )
> Обзорно читал про NoSQL, но никогда вплотную не использовал. Потратил > ещё пару дней на ознакомление, но каждый раз, когда начинаю читать про > конкретное решение, возникает ощущение что это не то что нужно. > Ткните, пальцем в алгоритм выбора.
Key-value store: Redis
Document-oriented: MongoDB
Column-oriented: Cassandra
> Проект уже в каком-то виде использует свой примитивный NoSQL. > Пользователи загружают свои данные в систему. Система строит отчет и > хранить его в виде сериализованного объекта в файле в облаке. > Новая задача требует собирать некоторые данные пользователей и хранить > их другим объектом. Вроде как обычное Key-Value выходит. > Сервис публичный. Есть риск что данных станет очень много. Поэтому > пихать много всего в MySQL не охота.
На последнем JPoint Сбертех много чего рассказывал про свой выбор, как я
понял из их слов — это допиливаемая под их нужды версия Apache Ignite.
Вот тут можно посмотреть подробнее: https://www.youtube.com/watch?v=3xJZ9_LOEhw
> Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до > 10Мб, а в будущем может и больше.
Хранение массивных блобов — это не вполне конечно типичное применение
KV. А почему их просто в файлах не хранить в какой-нибудь GlusterFS?
> Для каких задач можно получить преимущества от Graph или Column oriented > хранилищ?
От Graph — для хранения всяких там графов связей и т.п. Где выгоды от
использования Column — я честно сказать сам так и не понял, может кто
прояснит. Знаю что его активно используют в "Одноклассниках" и они
реально контрибутят в неё.
> Правильно ли я понимаю, что такие решения как HBase являются полностью > in-memory решениями? То есть, их вообще нет смысла использовать при > отсутствии кластера в десяток серверов?
HBase — это, если я ничего не путаю, какая-то запчасть от хадупа,
который вообще вряд ли пригоден для вышеизложенной задачи.
Здравствуйте, hrensgory, Вы писали:
H>Хранение массивных блобов — это не вполне конечно типичное применение H>KV. А почему их просто в файлах не хранить в какой-нибудь GlusterFS?
Ну, я о том же. Сейчас примерно такая реализация и существует.
Смысл перехода на другое хранилище в том, что это не тупо блобы. Это вполне себе конкретные одинаковые структуры данных.
Иногда возникает желание что-то типовое из них всех вытащить и посчитать. Можно долго.
H>HBase — это, если я ничего не путаю, какая-то запчасть от хадупа, H>который вообще вряд ли пригоден для вышеизложенной задачи.
Мне просто шеф мозги проел BigTable. HBase — ближайший аналог. Но, судя по всему, вообще не под эту задачу.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Иль, Вы писали:
Иль>>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос. B>А так же с Oracle, SQL Server и, особенно, Firebird.
Firebird — это, пожалуй, по личному опыту ещё печальнее чем MySQL. Вспоминается что там для изменения структуры данных надо переходить в однопользовательский режим. Хотя может быть уже и изменилось что-то...
Плохо, что в списке нет PostgreSQL. Он тоже не без внезапностей, конечно, но в последнее время стремительно развивается. В частности уже две версии работающее сочетание JSON + GIST вполне себе напоминает NoSQL.
On 11.05.2016 12:43, Blazkowicz wrote: > H>Хранение массивных блобов — это не вполне конечно типичное применение > H>KV. А почему их просто в файлах не хранить в какой-нибудь GlusterFS? > Ну, я о том же. Сейчас примерно такая реализация и существует. > Смысл перехода на другое хранилище в том, что это не тупо блобы. Это > вполне себе конкретные одинаковые структуры данных. > Иногда возникает желание что-то типовое из них всех вытащить и > посчитать. Можно долго.
Здравствуйте, Alex.Che, Вы писали:
AC>монопольный режим используют только неучи, которые не умеют правильно выставить уровень изоляции транзакции для модификации метаданных.
Это всё уже без меня. При работе с Постгресом умения "правильно выставить уровень изоляции транзакции для модификации метаданных" не требуется
Здравствуйте, Blazkowicz, Вы писали:
B> Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями?
Нет. HBase — это для обработки данных с петабайтными объемами, для которых никакой памяти не хватит.
B> То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
Да. Практически все NoSQL решения не имеют смысла в рамках одного сервера. Для HBase/Mongo тебе их нужно будет минимум 3.
B> Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п.
Бэкапы в традиционном понимании обычно уже не делаются в силу огромных объемов данных, устойчивость к аппаратным сбоям достигается избыточной репликацией (т.е. не нужны RAID-массивы, достаточно рабочих реплик, физические ноды резервируются их количеством). Расширение пространства в большинстве случаев или автоматическое (добавление новых нод) или с минимальным ручным вмешательством (перешардирование).
P.S. Вот только для хранения блобов NoSQL наверное лишен смысла.
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не столько для пользы проекта, а чтобы получить опыт для будущих решений, так как с RDBMS уже много чего накушались. B>Обзорно читал про NoSQL, но никогда вплотную не использовал. Потратил ещё пару дней на ознакомление, но каждый раз, когда начинаю читать про конкретное решение, возникает ощущение что это не то что нужно. B>Ткните, пальцем в алгоритм выбора.
Так ты опиши что нужно.
Иначе алгоритм выбора простой — используй нормальную РСУБД (Postgres, MS SQL, остальное не рекоменду ибо дорого для стартапа).
NoSQL помогают только в частных случаях, в общем случае их лучше не использовать.
B>Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке. B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. B>Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота. B>Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
Это все оценочные суждения, при приведи конкретику. Начни с объема данных в количестве строк\объектов, нарисуй связи в логической структуре данных, расскажи какие запросы будут идти в базу.
B>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Графовые базы кроме получения объекта по ключу умеют делать обход графа на уровне движка. И говорят это быстрее чем CTE\connect by в РСУБД.
Column oriented нужны для быстрого получения агрегатов на большом объеме. Это нечто среднее между OLAP и OLTP. Подробнее можешь почитать как работает clustered columnstore в MS SQL, принципы в column-oriented те же.
B>Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями? То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
По сути да.
B>Что вообще почитать обзорного? http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
Здравствуйте, Blazkowicz, Вы писали:
B>Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п.
Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса.
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B>...
B>Спасибо
Обзорного не порекомендую, но скажу что например в яндексе кассандра используется как хранилище для конфигураций датацентов, там стоят чудовищной мощности серверы, сцепленные в кольцо по 10 штук, все это работает устойчиво. То есть, по зрелости кассандра вполне подходит.
Здравствуйте, Anton Batenev, Вы писали:
AB>P.S. Вот только для хранения блобов NoSQL наверное лишен смысла.
Это не блобы. На самом деле всю структуру можно разложить в реляционную. Блобы, тут как попытка примитивного NoSQL — держать данные одного юзера единым целым.
B>Ну, я о том же. Сейчас примерно такая реализация и существует. B>Смысл перехода на другое хранилище в том, что это не тупо блобы. Это вполне себе конкретные одинаковые структуры данных. B>Иногда возникает желание что-то типовое из них всех вытащить и посчитать. Можно долго.
В порядке бреда: одинаковые структуры можно хранить как микро бд, например, SQLite, а сами файлы sqlite в РСУБД (в полях типа bfile) с некоторыми метаданными для поиска.
Ну опять же от задачи зависит, это может быть удобно, когда требуется получить эту структуру, с ней атомарно поработать и положить обратно.
Это, конечно, не NoSQL, но как решение может и сработать.
Здравствуйте, Alex.Che, Вы писали:
>> При работе с Постгресом умения "правильно выставить уровень изоляции транзакции для модификации метаданных" не требуется
AC>а многие пользователи MS SQL вообще уверены, что "не используют транзакции"
По-моему это наблюдение в пользу MS SQL. Не нужны тебе транзакции — ты о них и не задумываешься. Хотя в СУБД они есть, ждут своего часа.
А вот если тебе транзакции в каком-то конкретном (начальном) случае не нужны, но ты, несмотря на это, не можешь ничего даже элементарного сделать пока не разберёшься с уровнями изоляции, то место такой базе, на мой скромный взгляд — ...
Здравствуйте, Blazkowicz, Вы писали:
B> AB>P.S. Вот только для хранения блобов NoSQL наверное лишен смысла. B> Это не блобы. На самом деле всю структуру можно разложить в реляционную. Блобы, тут как попытка примитивного NoSQL — держать данные одного юзера единым целым.
Тогда, если данные так легко раскладываются, я бы посоветовал взять MongoDB и просто попробовать. Она элементарно устанавливается и почти не требует никакой настройки / обслуживания, работа с ней проста и незатейлива. К тому моменту, когда ты столкнешься с ее особенностями, у тебя уже будет представление о том что это такое и с чем это едят — как раз тот самый случай, когда "фигак-фигак и в production" имеет позитивную составляющую.
В мире есть только одна очень серъезная бесплатная NoSQL база данных, называется Cassandra. Она настолько серъезная что Riak и прочие даже рядом не стояли, она написана на java и используется также компанией Microsoft.
Здравствуйте, gandjustas, Вы писали:
B>>Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п. G>Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса.
ЩИТО?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
B>>>Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п. G>>Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса. C>ЩИТО?
Напомни какая NoSQL база может делать дифференциальный бекап и Point In Time restore на базе в минимум в 200гб?
Сколько монге надо времени на сбор индексов после рестора 100 гб базы?
Здравствуйте, Alex.Che, Вы писали:
>> По-моему это наблюдение в пользу MS SQL. Не нужны тебе транзакции — ты о них и не задумываешься. Хотя в СУБД они есть, ждут своего часа.
AC>очень интересный взгляд на вещи. AC>особенно про то, что "они ждут своего часа". AC>умилительно.
Нет, ну на Firebird-Delphi это, конечно, не распространяется. Там ждать нечего и неоткуда.
On 11.05.2016 19:29, "Иль" wrote: > Не нужны тебе транзакции — ты о > них и не задумываешься. Хотя в СУБД они есть, ждут своего часа.
Зато уж когда час их настанет, как выскачут из-за угла, да как врежут со
всей дури ничего не подозревавшему о connection.setAutoCommit(false)
программисту по йайцам. И возопит он весьма громко.
Здравствуйте, gandjustas, Вы писали:
G>>>Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса. C>>ЩИТО? G>Напомни какая NoSQL база может делать дифференциальный бекап и Point In Time restore на базе в минимум в 200гб?
Cassandra ( https://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_backup_incremental_t.html ), Riak (стандартной репликацией) — точно.
G>Сколько монге надо времени на сбор индексов после рестора 100 гб базы?
Секунды?
Здравствуйте, Alex.Che, Вы писали:
B>>> Для каких задач можно получить преимущества от Graph или Column oriented хранилищ? >> Аналитика
AC>Аналитика чего именно?
Агрегированные запросы (суммировать все строки, у которых такие-то значения) на поколоночных базах работает быстро. Они для этого и существуют, в OLTP системах их не используют
> Агрегированные запросы (суммировать все строки, у которых такие-то значения) на поколоночных базах работает быстро. > Они для этого и существуют, в OLTP системах их не используют
для подобного рода аналитики обычно используют OLAP-серверы/сервисы.
Здравствуйте, Alex.Che, Вы писали:
>> Агрегированные запросы (суммировать все строки, у которых такие-то значения) на поколоночных базах работает быстро. >> Они для этого и существуют, в OLTP системах их не используют
AC>для подобного рода аналитики обычно используют OLAP-серверы/сервисы.
ОЛАП — это построитель сводных таблиц с данными из хранилища данных. В сводных таблицах часто лежат агрегированные данные, например сумма по уровням измерений. Некоторые хранилища данных как раз и используют механизм поколоночного хранения, чтобы быстро выполнялись агрегированные запросы, необходимые ОЛАПу.
Это я вам говорю как заслуженный разработчик олапов и хранилищ данных
Разверни свою мысль, "не совсем" что именно? А то по ссылке описывается обычное разгильдяйство и пренебрежение базовыми принципами обеспечения безопасности, которые к монге не имеют никакого отношения.
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
> Сколько-то лет назад, когда я пересекался с ИнтерСистемс, > влезть в базу Cashe можно было только их собственным инструментом. Онли. > Это по сю пору так?
Здравствуйте, gandjustas, Вы писали:
B>>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ? G>Графовые базы кроме получения объекта по ключу умеют делать обход графа на уровне движка. И говорят это быстрее чем CTE\connect by в РСУБД.
Я проводил эксперименты с графовыми базами данных. В частности на Neo4j — самой популярной графовой бд. В итоге там очень выразительный язык запросов — cypher. Оч. понравился, по скорости далеко не все так радужно, залил часть боевой базы — в сравнении с SQL сервером до 10 раз медленнее запросы выполняются, как я не пытался ускорить. Плюс средства диагностики плохо развиты, не понятно что происходит под капотом. Говорил с командой, которая ее использует в своем проекте — аналогичное мнение.
>> Сколько-то лет назад, когда я пересекался с ИнтерСистемс, >> влезть в базу Cashe можно было только их собственным инструментом. Онли. >> Это по сю пору так? AC>есть odbc и jdbc
да толку то...
у них теперь даже SQL поддерживается, в какой-то мере.
примерно как у BDE(IDAPI)
по уверениям продавцов каши, всё даже аж "летает".
только низенько-низенько.
в хорошую погоду.
если пнуть с горы...
Здравствуйте, Иль, Вы писали:
Иль>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
Здравствуйте, teoreteg, Вы писали:
T>Здравствуйте, Иль, Вы писали:
Иль>>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
T>Правильные это какие? И чем так уж плох мускуль?
Правильная работа.
Плох тем, что не подходит для нагруженных систем. Например нет поддерживает индексы по условию, оконные функции, CTE, гораздо хуже ситуация с обслуживанием (по сути не приспособлен для работы 24x7 в сколь бы то ни было серьёзных проектах) и т. д. и т. п.
Но вообще если вы никогда не задумывались о перечисленном, то значит ещё не время. Просто считайте это моей субъективной оценкой.
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B>Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке. B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. B>Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота. B>Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
Все будет зависеть в том числе от того, на каком языке вы пишете.
Возможно подойдет Cassandra + Spark.
B>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Графы для анализа связей и вообще для игр с теорией графов.
Госпади, ну почему при каждом упоминании NoSQL вспоминают CAP?
Во-первых она ни о чем, во-вторых у автора нет и никогда не будет распределенных баз. Как и у 99% пишущих про CAP.
Здравствуйте, hrensgory, Вы писали:
H>всей дури ничего не подозревавшему о connection.setAutoCommit(false) H>программисту по йайцам. И возопит он весьма громко.
Угу. Вопил. Но виновника нашел.
G>Госпади, ну почему при каждом упоминании NoSQL вспоминают CAP?
Потому что могут.
G>Во-первых она ни о чем, во-вторых у автора нет и никогда не будет распределенных баз. Как и у 99% пишущих про CAP.
Звучит, как приговор.
Бедные, бедные 99%.
Здравствуйте, Иль, Вы писали:
Иль>Плох тем, что не подходит для нагруженных систем. Например нет поддерживает индексы по условию, оконные функции, CTE, гораздо хуже ситуация с обслуживанием (по сути не приспособлен для работы 24x7 в сколь бы то ни было серьёзных проектах) и т. д. и т. п.
Здравствуйте, Mihas, Вы писали:
M>А что скажете про амазоновский DynamoDB?
Отзывы смешанные. Работает только в облаке за деньги. Ну, и главное, что оно ближе к Mongo (Document/Key-value). А для моей задачи, похоже что "wide column store" (BigTable, Cassandra) подходит больше.
Здравствуйте, teoreteg, Вы писали:
T>Правильные это какие? И чем так уж плох мускуль?
Никогда супер плотно с ним не работал. Но даже поверхностно напрягает, что простые вещи надо делать с подвыподвертом. Самый простой пример — изменение типа колонки в таблице с данными. Если в любой серьезной БД, достаточно просто поменять тип. То, MySQL нужно самому делать новую колонку, копировать и потом удалять старую. Сам он в фоне это сделать не может. Недавно натыкался и на другой аналогичный пример, когда, казалось бы, банальная операция, в MySQL требует ручного и особого SQL.
Здравствуйте, gandjustas, Вы писали:
G>Во-первых она ни о чем, во-вторых у автора нет и никогда не будет распределенных баз.
Никогда не говори никогда. У нас коробочный продукт. У клиентов базы в сотни гигабайт. Клиентов сотни, это ещё минимум два порядка, а то и три в перспективе. И есть большое желание предоставлять продукт в виде сервиса, а не коробкой.
Здравствуйте, teoreteg, Вы писали:
T>Почему тогда им все пользуются?
Ну наверное всё-таки не все... Тем более в последние годы. По крайней мере по последней конференции, на которой были доклады и по MySQL и по PostgreSQL, было хорошо заметно что интерес к MySQL падает, а вот к постгресу — напротив растёт.
Но, конечно, MySQL в абсолютных цифрах распространён больше.
Я думаю что так получилось во первых потому что LAMP. MySQL идеально сочетается с PHP. И там и там типизация довольно условна. И тот и другой выстроены стихийно — как было удобнее в текущий момент. И тот и другой делают что придётся в тех случаях когда давно уже надо бы написать сообщение об ошибке... Это последнее обстоятельство, кстати, обеспечивает крутую learning curve и тем самым приток новых кадров в эти технологии до сих пор.
Во вторых потому что MySQL по ряду причин удобней для хостингов (LAMP же!). Например, выставить права доступа к БД можно простыми SQL-командами в отличие от того же PostgreSQL, с которым всё не так просто.
В третьих мускуль когда-то был сильно быстрее (по крайней мере на чтение) и опережал тот же постгрес по возможностям. Сейчас ситуация прямо противоположная, но "интерес" запаздывает. Накопилось много специалистов со знанием мускуля, которые не хотят переучиваться ни на что кроме, быть может, NoSQL — и это поддерживает массовость мускулю несмотря на то, что он безнадёжно устарел...
G>Напомни какая NoSQL база может делать дифференциальный бекап и Point In Time restore на базе в минимум в 200гб? G>Сколько монге надо времени на сбор индексов после рестора 100 гб базы?
100GB это слезы
Попробую рассказать, почему это странный вопрос. У нас есть Hadoop кластер на 100 с гаком машин, там крутится HDFS, в которой непосредственно лежат данные (в том числе файлы данных HBase, но не только). Данные хранятся с replication factor = 5 (в нашем случае), поэтому бэкапы делать не нужно, да и смысла в них нет, так как такой объем данных нереально ни забэкапить нормально, ни восстановить, это слишком долго и дорого и не нужно.
Я расскажу зачем нужно делать бэкап, для начала. Есть такое явление, как bit rot из-за которого, любой файл на жестком диске может со временем измениться. Если это файл данных РСУБД, то контрольная сумма поврежденной страницы не сойдется и данные будут потеряны. Эта проблема решается периодическим бэкапом. В той же HDFS это не проблема, так как там поврежденные блоки удаляются (специальный фоновый процесс все время читает блоки и сверяет контрольные суммы), после чего replication factor блока восстанавливается до нужного уровня. Поэтому там бэкап тупо не нужен.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Поэтому там бэкап тупо не нужен.
Кроме физической целостности есть и другой аспект. Из-за ошибки в программе или из-за кривых рук данные в базе могут быть удалены вполне законным способом и без бекапа никуда.
Все админы делятся на две категории — те кто делают бекапы и те, кто их будут делать.
Желаю вам побыстрее перейти во вторую категорию.
ЗЫ. HDFS всетаки не основное хранилище данных, поэтому потеря может не иметь негативных последствий. Тем не менее утверждать, что бекап не нужен, может только очень смелый или очень глупый человек.
ЗЗЫ. MS даже в облачном SQL Server сделал бекап именно по этой причине.
G>Кроме физической целостности есть и другой аспект. Из-за ошибки в программе или из-за кривых рук данные в базе могут быть удалены вполне законным способом и без бекапа никуда.
Для этого есть снепшоты и trash сервер. Все это можно откатить взад. Снепшоты это не бэкап, так как реальные данные они не копируют. Это снепшоты метаданных, по сути.
Но вообще, частой практикуется вообще не удалять данные никогда. Мы примерно так и делаем. Единственное, что удаляется из системы — это некоторые агрегаты в HBase, которые по логике являются эфемерными и вычисляются на основе других данных. Но они удаляются по TTL а не вручную. Перезаписать что-нибудь программно в HDFS невозможно, а в HBase это не проблема, так как есть версионирование и старая версия данных сохранится (ну и, опять же, снепшоты). В общем, все просрать можно, только если будет физически разрушен датацентр, в котором все это живет. Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup.
G>Все админы делятся на две категории — те кто делают бекапы и те, кто их будут делать. G>Желаю вам побыстрее перейти во вторую категорию. G>ЗЫ. HDFS всетаки не основное хранилище данных, поэтому потеря может не иметь негативных последствий. Тем не менее утверждать, что бекап не нужен, может только очень смелый или очень глупый человек.
Почему HDFS не основное хранилище данных?
Очень глупый человек будет утверждать что бэкап нужен, до того как посчитает во сколько он обойдется. Экономически это не оправдано (в случае HDFS+HBase и хоть сколько нибудь крупной инфраструктуры), да и перерыв в обслуживании будет такой, что уж лучше часть данных потерять и восстановить из других источников, нежели на несколько суток все останавливать, вайпать каждую ноду и накатывать (уж даже не знаю каким способом) бэкап взад. В HDFS и HBase данные хранятся уже в сжатом виде, поэтому бэкапы сжать не получится. Они будут занимать столько же места, сколько и основное хранилище данных (которое постоянно растет).
G>ЗЗЫ. MS даже в облачном SQL Server сделал бекап именно по этой причине.
Потому что пользователи MSSQL — ретрограды, очевидно же.
Здравствуйте, chaotic-kotik, Вы писали:
G>>Кроме физической целостности есть и другой аспект. Из-за ошибки в программе или из-за кривых рук данные в базе могут быть удалены вполне законным способом и без бекапа никуда.
CK>Для этого есть снепшоты и trash сервер. Все это можно откатить взад. Снепшоты это не бэкап, так как реальные данные они не копируют. Это снепшоты метаданных, по сути.
Как снепшоты помогут если кто-то пойдет и выполнит команду аналогичную
drop table main_data
?
CK>Но вообще, частой практикуется вообще не удалять данные никогда. Мы примерно так и делаем.
Это не гарантирует что данные будут в сохранности.
CK>Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup.
Это тот самый бекап, только дороже.
CK>Почему HDFS не основное хранилище данных?
Если данные нестрашно потерять, то скорее всего так и есть.
CK>Очень глупый человек будет утверждать что бэкап нужен, до того как посчитает во сколько он обойдется. Экономически это не оправдано (в случае HDFS+HBase и хоть сколько нибудь крупной инфраструктуры)
Держать 5 реплик + копию в другом ДЦ оправдано?
На практике бекап — самый дешевый способ делать disaster recovery, по сравнению со всеми остальными. Дешевле на порядки. Мало того, что бекапить можно на ленты, которые имеют стоимость хранения ГБ на два порядка меньше жестких дисков, так еще это не требует дорогих серверов и бекапы могут быть хорошо пожаты.
CK>да и перерыв в обслуживании будет такой, что уж лучше часть данных потерять и восстановить из других источников, нежели на несколько суток все останавливать, вайпать каждую ноду и накатывать (уж даже не знаю каким способом) бэкап взад.
Это проблема исключительно NoSQL движков, о чем я намекал в том сообщении, которое ты прокомментировал.
Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов.
То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.
G>>ЗЗЫ. MS даже в облачном SQL Server сделал бекап именно по этой причине. CK>Потому что пользователи MSSQL — ретрограды, очевидно же.
G>Как снепшоты помогут если кто-то пойдет и выполнит команду аналогичную G>
G>drop table main_data
G>
G>?
Ну так можно восстановить все из снепшота, что в этом непонятного?
G>Это не гарантирует что данные будут в сохранности.
Так и бэкап твой тоже ничего не гарантирует.
CK>>Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup. G>Это тот самый бекап, только дороже.
Почему дороже? Начнем с того, что MSSQL не может в несколько датацентров вообще. Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?
G>Если данные нестрашно потерять, то скорее всего так и есть.
Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.
G>Держать 5 реплик + копию в другом ДЦ оправдано?
Ну мы не держим копию в другом ДЦ пока. Но мы прикидывали во сколько раз дороже обойдется держать данные из HBase в постгресе. HBase — column oriented и для каждой column family можно настроить сжатие по разному, например, если в колонке лежат метки времени или увеличивающиеся id-шники, можно использовать delta-кодинг с последующим сжатием, что увеличивает эффективность, плюс однородность сжимаемых данных играет на руку очень сильно. Данные очень хорошо жмутся и занимают в HBase в разы меньше места, чем в постгресе. Ну и 5 реплик нужны не только для сохранности, но и для locality, чтобы MapReduce задачи выполнялись быстрее и не копировали данные туда-сюда.
G>На практике бекап — самый дешевый способ делать disaster recovery, по сравнению со всеми остальными. Дешевле на порядки. Мало того, что бекапить можно на ленты, которые имеют стоимость хранения ГБ на два порядка меньше жестких дисков, так еще это не требует дорогих серверов и бекапы могут быть хорошо пожаты.
Ну это все голословные утверждения, практика у всех разная.
CK>>да и перерыв в обслуживании будет такой, что уж лучше часть данных потерять и восстановить из других источников, нежели на несколько суток все останавливать, вайпать каждую ноду и накатывать (уж даже не знаю каким способом) бэкап взад. G>Это проблема исключительно NoSQL движков, о чем я намекал в том сообщении, которое ты прокомментировал.
Это не проблема, потому что так не делают.
G>Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов. G>То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.
Это разумное время по твоему? А скажи пожалуйста, зачем нужно было делать рестор той БД и как зависит время рестора от размера базы?
Здравствуйте, gandjustas, Вы писали:
g> Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов. g> То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.
Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц.
P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно.
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Здравствуйте, chaotic-kotik, Вы писали:
G>>Как снепшоты помогут если кто-то пойдет и выполнит команду аналогичную G>>
G>>drop table main_data
G>>
G>>? CK>Ну так можно восстановить все из снепшота, что в этом непонятного?
Ты вроде писал, что снепшот не хранит данные? Или таки хранит?
G>>Это не гарантирует что данные будут в сохранности. CK>Так и бэкап твой тоже ничего не гарантирует.
В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.
CK>>>Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup. G>>Это тот самый бекап, только дороже. CK>Почему дороже?
Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.
CK>Начнем с того, что MSSQL не может в несколько датацентров вообще.
Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.
CK>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?
Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.
G>>Если данные нестрашно потерять, то скорее всего так и есть. CK>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.
Ты написал что данные можно восстановить из других источников. Значит не так страшно.
G>>Держать 5 реплик + копию в другом ДЦ оправдано? CK>Ну мы не держим копию в другом ДЦ пока.
То есть катастрофоустойчивости у вас нет? Я вот запоследний год помню три падения разных хостеров с невозможностью воссановления.
Желаю тебе как можно быстрее перейти в категорию тех кто уже делает бекапы.
G>>На практике бекап — самый дешевый способ делать disaster recovery, по сравнению со всеми остальными. Дешевле на порядки. Мало того, что бекапить можно на ленты, которые имеют стоимость хранения ГБ на два порядка меньше жестких дисков, так еще это не требует дорогих серверов и бекапы могут быть хорошо пожаты. CK>Ну это все голословные утверждения, практика у всех разная. http://www.overlandstorage.com/blog/?p=323
CK>>>да и перерыв в обслуживании будет такой, что уж лучше часть данных потерять и восстановить из других источников, нежели на несколько суток все останавливать, вайпать каждую ноду и накатывать (уж даже не знаю каким способом) бэкап взад. G>>Это проблема исключительно NoSQL движков, о чем я намекал в том сообщении, которое ты прокомментировал. CK>Это не проблема, потому что так не делают.
G>>Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов. G>>То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание. CK>Это разумное время по твоему?
Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.
CK>А скажи пожалуйста, зачем нужно было делать рестор той БД и как зависит время рестора от размера базы?
Есть полезная практика тестировать рестор. Вот протестировали.
Время рестора от размера зависит линейно, потому что скорость записи на диск — ограничивающий фактор.
В твоем случае ограничивающим фактором станет канал между ДЦ, скорее всего он окажется меньше, чем скорость записи на диск.
В прикладных случаях ресторить всю базу вообще нет смысла, есть дифференциальные бекапы, бекапы логов. Поэтому откат базы в предыдущее состояние на пару дней обычно не проблема.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов. g>> То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.
AB>Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц.
Тем не менее вопрос остается открытым. Если случилась катастрофа, то как восстановить работу?
Да и петабайты на HBase мало интересуют. Больше интересуют системы, которые позиционируются как замена РСУБД.
AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно.
Это был тестовый рестор на машинку с обычными дисками.
Здравствуйте, Blazkowicz, Вы писали:
Иль>>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос. B>А так же с Oracle, SQL Server и, особенно, Firebird.
Здравствуйте, gandjustas, Вы писали:
g> AB>Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц. g> Тем не менее вопрос остается открытым. Если случилась катастрофа, то как восстановить работу?
Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера.
g> Да и петабайты на HBase мало интересуют. Больше интересуют системы, которые позиционируются как замена РСУБД.
Так вроде NoSQL и не позиционируется как замена РСУБД — они решают свой класс задач, где использование "классических" БД становится затратным/неудобным.
g> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g> Это был тестовый рестор на машинку с обычными дисками.
Т.е. бэкап не тянулся с хранилища по сети, а лежал локально?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> AB>Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц. g>> Тем не менее вопрос остается открытым. Если случилась катастрофа, то как восстановить работу? AB>Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера.
А что делать в случае прикладной ошибки и кто-то порушил данные?
g>> Да и петабайты на HBase мало интересуют. Больше интересуют системы, которые позиционируются как замена РСУБД. AB>Так вроде NoSQL и не позиционируется как замена РСУБД — они решают свой класс задач, где использование "классических" БД становится затратным/неудобным.
Cassandra, Mongo и несколькодругих позиционируют себя именно как замена.
g>> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g>> Это был тестовый рестор на машинку с обычными дисками. AB>Т.е. бэкап не тянулся с хранилища по сети, а лежал локально?
Конечно с хранилища по сети. Но в локалке скорость сильно выше, чем скорость дисков.
Здравствуйте, gandjustas, Вы писали:
g> AB>Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера. g> А что делать в случае прикладной ошибки и кто-то порушил данные?
То же самое. Кластер сконфигурирован таким образом, чтобы можно было пережить полный отказ одного дата-центра без прекращения работы сервиса. Плюс потенциально деструктивные изменения сначала тестируются на тестовом стенде, а потом какое-то время на prestable с боевой нагрузкой и данными. Дополнительно данные никогда сразу не удаляются (или просто никогда не удаляются в зависимости от).
g> g>> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g> g>> Это был тестовый рестор на машинку с обычными дисками. g> AB>Т.е. бэкап не тянулся с хранилища по сети, а лежал локально? g> Конечно с хранилища по сети. Но в локалке скорость сильно выше, чем скорость дисков.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> AB>Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера. g>> А что делать в случае прикладной ошибки и кто-то порушил данные?
AB>То же самое. Кластер сконфигурирован таким образом, чтобы можно было пережить полный отказ одного дата-центра без прекращения работы сервиса. Плюс потенциально деструктивные изменения сначала тестируются на тестовом стенде, а потом какое-то время на prestable с боевой нагрузкой и данными. Дополнительно данные никогда сразу не удаляются (или просто никогда не удаляются в зависимости от).
То есть репликация не автоматическая? Или есть еще отдельный тестовый стенд?
g>> g>> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g>> g>> Это был тестовый рестор на машинку с обычными дисками. g>> AB>Т.е. бэкап не тянулся с хранилища по сети, а лежал локально? g>> Конечно с хранилища по сети. Но в локалке скорость сильно выше, чем скорость дисков. AB>Локалка с 10 гигабитным линком?
Да
Здравствуйте, gandjustas, Вы писали:
g> То есть репликация не автоматическая? Или есть еще отдельный тестовый стенд?
Есть отдельный тестовый стенд для каждого компонента. Репликация автоматическая в рамках одного ДЦ (cross-dc очень дорого гонять большой трафик, по этому они получаются изолированными).
g> AB>Локалка с 10 гигабитным линком? g> Да
CK>>Ну так можно восстановить все из снепшота, что в этом непонятного? G>Ты вроде писал, что снепшот не хранит данные? Или таки хранит?
Данные в HDFS хранятся в блоках (128Мб по умолчанию), каждый файл это набор блоков, файлы — append only (блоки не изменяются) и каждый блок живет ровно до тех пор, пока на него ссылается хоть один снепшот. Снепшотятся метаданные, т.е. маппинг обектов файловой системы на блоки HDFS (содержимое name серверов). Соответственно, все что угодно можно восстановить из снепшота, ведь данные не удаляются пока жив снепшот. Снепшоты в HBase построены на основе снепшотов HDFS
CK>>Так и бэкап твой тоже ничего не гарантирует. G>В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.
Сервер на котором хранятся бэкапы тоже не абсолютно надежен. Вот представь, хранишь ты бэкапы в дисковой полке, но когда полку только купили, какой-нибудь идиот-админ взял и объединил все дисковое пространство в одну файловую систему, а незадолго до того как тебе потребовалось восстановить базу из бэкапа произошел переезд в другой ДЦ, полка была перезапущена неаккуратно и начала выполнять fcheck. Я не знаю сколько точно длится fcheck файловой системы размером в 360ТБ, но готов поспорить что дольше недели. Я такой факап видел, в полке хранились в том числе и бэкапы БД, хорошо что они не потребовались.
Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL. Мне кажется, хорошим выходом из этой ситуации будет хранение бэкапов MSSQL в HDFS. HDFS считает и хранит контрольные суммы
G>Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.
Я уже писал что данные в HBase жмутся лучше чем в большинстве РСУБД. И реплик больше трех нужно для того, чтобы данные не копировать туда сюда, если нужно запустить развесистый MapReduce Job!
G>Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.
Я совершенно искренне заблуждался на этот счет!
CK>>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже? G>Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.
Ну что значит обычно? У какого-нибудь Redis-a может и плохо, я не эксплуатировал его, не знаю. Но вот у HBase/Cassandra и много чего еще — все очень хорошо. В HBase снепшоты накатываются без даунтайма практически.
CK>>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое. G>Ты написал что данные можно восстановить из других источников. Значит не так страшно.
Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
CK>>Это разумное время по твоему? G>Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.
CK>Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL.
NTFS не хранит, т.к. CRC и ECC по факту уже реализованы внутри самого диска. Bit rot детектится хард драйвом ещё до того, как данные попадут на уровень файловой системы. Более того, благодаря ECC, они сначала корректируются, блок релокируется, и только когда запасных блоков для релокации перестаёт хватать или объём повреждений сектора превышает возможности ECC, мы получаем сбой чтения, заметный на уровне ФС.
Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
CK>Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
Это кстати вообще, на мой взгляд, общее место какое-то. Т.е. к примеру крайне популярна тема сравнения надёжности (fault tolerance) и доступности (availability) разных решений — SQL там, NoSQL, и т.п. — при этом, что характерно, никаких разговоров о времени восстановления из бэкапа не ведётся в принципе. На мой взгляд, это профанация — потому, что двухмашинный active-passive кластер при смерти активной ноды превращается в одномашинный кластер. Если восстановление второй ноды занимает неделю, то у нас есть все шансы нарваться на второй фолт и получить полную потерю данных.
В SQL Azure, насколько я знаю, по этой причине используется три реплики базы, и коммит требует кворума "2 из 3х". Благодаря этому при единичном сбое мы всё ещё имеем избыточность, и можно продолжать работать. Если у нас осталась единственная реплика данных, то по идее надо всё тихонечко выключать и молиться, что за время подготовки второй реплики в первую не шарахнет метеорит
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>NTFS не хранит, т.к. CRC и ECC по факту уже реализованы внутри самого диска. Bit rot детектится хард драйвом ещё до того, как данные попадут на уровень файловой системы. Более того, благодаря ECC, они сначала корректируются, блок релокируется, и только когда запасных блоков для релокации перестаёт хватать или объём повреждений сектора превышает возможности ECC, мы получаем сбой чтения, заметный на уровне ФС.
А ZFS видимо просто так придумали?
Это опасное заблуждение. Данные портятся и могут быть восстановлены контроллером используя CRC и ECC только в том случае, если их кто-нибудь читает! Вот именно для этого и придумали data scrubbing, если что. Если ты не читаешь испорченный сектор годами, то ошибки в нем накапливаются и его уже нельзя восстановить, при попытке чтения ты получишь URE или, что еще хуже, прочитаешь битый сектор.
S>Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
Даже из RAID-5 массива их можно прочитать.
S>Это кстати вообще, на мой взгляд, общее место какое-то. Т.е. к примеру крайне популярна тема сравнения надёжности (fault tolerance) и доступности (availability) разных решений — SQL там, NoSQL, и т.п. — при этом, что характерно, никаких разговоров о времени восстановления из бэкапа не ведётся в принципе. На мой взгляд, это профанация — потому, что двухмашинный active-passive кластер при смерти активной ноды превращается в одномашинный кластер. Если восстановление второй ноды занимает неделю, то у нас есть все шансы нарваться на второй фолт и получить полную потерю данных. S>В SQL Azure, насколько я знаю, по этой причине используется три реплики базы, и коммит требует кворума "2 из 3х". Благодаря этому при единичном сбое мы всё ещё имеем избыточность, и можно продолжать работать. Если у нас осталась единственная реплика данных, то по идее надо всё тихонечко выключать и молиться, что за время подготовки второй реплики в первую не шарахнет метеорит
Термин "high-availability" подразумевает что твой кластер может пережить потерю до трети машин без перерывов в обслуживании. С двухмашинным "кластером" ни о каком HA говорить, само собой, нельзя. Если под "репликами" подразумеваются разные кластеры в двух разных ДЦ, то да, после того как в первый ДЦ шарахнул метеорит, второй будет работать без реплики. Но мы тут исходим из того, что событие "метеорит шарахнул в ДЦ" — очень маловероятно.
Здравствуйте, chaotic-kotik, Вы писали: CK>Это опасное заблуждение. Данные портятся и могут быть восстановлены контроллером используя CRC и ECC только в том случае, если их кто-нибудь читает! Вот именно для этого и придумали data scrubbing, если что. Если ты не читаешь испорченный сектор годами, то ошибки в нем накапливаются и его уже нельзя восстановить, при попытке чтения ты получишь URE или, что еще хуже, прочитаешь битый сектор.
А можно пояснить, каким именно образом мне удастся прочитать битый сектор? С учётом CRC на уровне контроллера.
CK>Даже из RAID-5 массива их можно прочитать.
Пруфлинк в студию.
CK>Термин "high-availability" подразумевает что твой кластер может пережить потерю до трети машин без перерывов в обслуживании.
Откуда такое определение? Сами придумали? Термин availability означает процент времени работы, в течение которого система остаётся доступной. High availability — термин неформальный, означает просто "высокий процент доступности". Каким способом он досигается — вопрос вторичный. Можно брать более качественные компоненты, можно закладывать избыточность прямо внутрь отдельной машины (например, дублируют блок питания), можно увеличивать количество машин в кластере.
CK>С двухмашинным "кластером" ни о каком HA говорить, само собой, нельзя. Если под "репликами" подразумеваются разные кластеры в двух разных ДЦ, то да, после того как в первый ДЦ шарахнул метеорит, второй будет работать без реплики. Но мы тут исходим из того, что событие "метеорит шарахнул в ДЦ" — очень маловероятно.
Ок, попробую на пальцах вам объяснить сложную для вас вещь: даже в вашем надуманном определении, кластер из трех машин считается HA. Но как только одна из них навернулась, кластер тут же перестал быть HA, так как в нём осталось только две машины. Этот момент понятен, или нужно дальше объяснять?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>А можно пояснить, каким именно образом мне удастся прочитать битый сектор? С учётом CRC на уровне контроллера.
Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE.
CK>>Даже из RAID-5 массива их можно прочитать. S>Пруфлинк в студию.
google -> "RAID5 URE"
CK>>Термин "high-availability" подразумевает что твой кластер может пережить потерю до трети машин без перерывов в обслуживании. S>Откуда такое определение? Сами придумали? Термин availability означает процент времени работы, в течение которого система остаётся доступной. High availability — термин неформальный, означает просто "высокий процент доступности". Каким способом он досигается — вопрос вторичный. Можно брать более качественные компоненты, можно закладывать избыточность прямо внутрь отдельной машины (например, дублируют блок питания), можно увеличивать количество машин в кластере.
Из CAP. HA система, это практически всегда AP система, которой, для того чтобы пережить F fail-stop отказов нужно 2F + 1 машин. Про "треть" машин я написал подразумевая трехмашинную конфигурацию (о которой шла речь). Высокая доступность тут достигается за счет кворума и избыточности. За счет одних только железок достижение высокой доступности едва ли возможно. Поэтому люди и обсуждают availability и fault-tolerance в одном контексте, так как первое достигается за счет второго даже на ширпотребном железе. Доступность на разных уровнях означает разное, дополнительный блок питания это хорошо, RAID массив тоже хорошо, но если я пытаюсь записать данные в БД и запрос отваливается по таймауту, считается что система недоступна в данный момент, это даунтайм. А это может быть даже если все железо работает хорошо, никаких железных отказов не было даже близко. Ну например CP система словила split-brain из-за GC-паузы. Split-brain длился пять секунд но в течении этих пяти секунд система была недоступна на запись.
S>Ок, попробую на пальцах вам объяснить сложную для вас вещь: даже в вашем надуманном определении, кластер из трех машин считается HA. Но как только одна из них навернулась, кластер тут же перестал быть HA, так как в нём осталось только две машины. Этот момент понятен, или нужно дальше объяснять?
Про hot standby слышал, или троллинг в интернете все свободное время занимает?
Здравствуйте, chaotic-kotik, Вы писали:
CK>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE. CK>google -> "RAID5 URE"
Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.
CK>Из CAP.
CAP — вообще булшит, простите за прямоту. "Научные" работы, которые оперируют термином Availability в смысле "она есть либо нету", нужно сразу скармливать в шредер.
Нормальные инженеры оперируют процентом аптайма. Реальные системы никогда не смогут получить 100% аптайм. Для понимания этого не надо защищать докторские диссертации или доказывать теоремы.
Инженерам формальное доказательство тезиса "железу свойственно ломаться" неинтересно. Инженерам интересно, как получить систему с availability = 99.99% из компонентов с availability = 99%.
Именно поэтому все рассуждения про построение HA без обсуждения time to recover — булшит и профанация.
В частности, в CAP про это нету ничего, кроме упоминания во введении. В стиле "но, поскольку это слишком сложно, то в данной работе заниматься этим мы не будем".
CK>Про hot standby слышал, или троллинг в интернете все свободное время занимает?
Конечно слышал. Делать вид, что standby оборудование не является частью вашей HA-конфигурации — опять профанация.
То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby.
Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Приятно почитать мнения людей знающих специфику NoSQL и RDBMS.
Простите за оффтоп, я с шароварного форума, и возможно вам будет интересно мое приложение http://www.mongodbmanager.com/
С меня бесплатные ключи, от вас пожелания и замечания.
CK>>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE. CK>>google -> "RAID5 URE" S>Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.
2.3 Corruption Classes
This study focuses on disk block corruptions caused by both hardware and
software errors. Hardware bugs include bugs in the disk drive or the disk
shelf firmware, bad memory, and adapter failures. Software bugs could also
cause some corruption. In many cases, the cause of corruption cannot be
identified. We detect different forms of corruption using the different data
protection mechanisms in place. As mentioned earlier, we distinguish be-
tween these forms in our study. Table I gives a summary of these corruption
classes.
—
Checksum Mismatches (CMs). This corruption class refers to cases where the
corruption is detected from mismatched data and checksum. The cause could
be: (i) data content corrupted by components within the data path; (ii) a torn
write, wherein only a portion of the data block is written successfully; or (iii)
a misdirected write, wherein the data is written to either the wrong disk or
the wrong location on disk, thus overwriting and corrupting data [Bartlett
and Spainhower 2004; Prabhakaran et al. 2005]. Checksum mismatches can
be detected anytime a disk block is read (file system reads, data scrubs, RAID
reconstruction, and so on).
—
Identity Discrepancies (IDs). This corruption class refers to a mismatch de-
tected when a disk block identity check is performed during a file system
read. The cause could be: (i) a lost write, which typically occurs because a
write destined for disk is not written but thought of as written; or (ii) a mis-
directed write, where the original disk location is not updated. We are aware
of actual cases when the disk firmware replied successfully to a write that
ACM Transactions on Storage, Vol. 4, No. 3, Article 8, Publication date: November 2008.
An Analysis of Data Corruption in the Storage Stack was never written to stable media.
Identity discrepancies can be detected only during file system reads.
—
Parity Inconsistencies (PIs): This corruption class refers to a mismatch be-
tween the parity computed from data blocks and the parity stored on disk
despite the individual checksums being valid. This error could be caused
by lost or misdirected writes, in-memory corruptions, processor miscalcula-
tions, and software bugs. Parity inconsistencies are detected only during data
scrub
S>CAP — вообще булшит, простите за прямоту. "Научные" работы, которые оперируют термином Availability в смысле "она есть либо нету", нужно сразу скармливать в шредер. S>Нормальные инженеры оперируют процентом аптайма. Реальные системы никогда не смогут получить 100% аптайм. Для понимания этого не надо защищать докторские диссертации или доказывать теоремы.
Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд.
S>Инженерам формальное доказательство тезиса "железу свойственно ломаться" неинтересно. Инженерам интересно, как получить систему с availability = 99.99% из компонентов с availability = 99%. S>Именно поэтому все рассуждения про построение HA без обсуждения time to recover — булшит и профанация. S>В частности, в CAP про это нету ничего, кроме упоминания во введении. В стиле "но, поскольку это слишком сложно, то в данной работе заниматься этим мы не будем".
Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости. Какое отношение к этому имеют твои 99.99% аптайма — тайна покрытая мраком. Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. А CAP как раз про гарантию возможности сделать что-либо. Если система не линеаризуема, то никакой аптайм не даст тебе возможность получить целостную картину данных в любой момент времени. Как-то так.
S>Конечно слышал. Делать вид, что standby оборудование не является частью вашей HA-конфигурации — опять профанация. S>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby.
Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так
S>Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.
В "ЕС2-стиле" это когда spot инстансы автоматически provision-ятся самим приложением на основе текущей нагрузки, прогноза и текущих цен? Ну да, действительно не очень актуально
Здравствуйте, chaotic-kotik, Вы писали:
CK>>>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE. CK>>>google -> "RAID5 URE" S>>Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.
Не надо цитировать простыни. Надо просто понять, что для детектирования невалидности бэкапа контрольные суммы на уровне ФС не нужны. Достаточно контрольных сумм на уровне контроллера диска.
Точно так же, как нет смысла впихивать контрольные суммы в сетевой протокол, работающий поверх TCP.
CK>Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд.
Вот и я об этом. Я, собственно, про CAP читал в первоисточнике. CK>Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости.
Тогда зачем вы тащите её в рассуждения об availability?
CK>Какое отношение к этому имеют твои 99.99% аптайма — тайна покрытая мраком.
Аптайм == availability. Сходите в википедию, что ли. Рассуждать о HA и не рассматривать аптайм — самообман и профанация.
CK>Можно иметь 100% аптайм, но не иметь возможности получить или записать данные.
Нет, нельзя. По определению. CK> А CAP как раз про гарантию возможности сделать что-либо. Если система не линеаризуема, то никакой аптайм не даст тебе возможность получить целостную картину данных в любой момент времени. Как-то так.
Нам достаточно сериализуемости.
S>>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby. CK>Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так
При чём тут абсолютная надёжность? Мы говорим ровно про ненадёжное железо и способы борьбы с этой ненадёжностью. В мире абсолютно надёжных жёстких дисков даже одна нода будет highly available.
S>>Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.
CK>В "ЕС2-стиле" это когда spot инстансы автоматически provision-ятся самим приложением на основе текущей нагрузки, прогноза и текущих цен?
Нет, это когда монитор, замечающий выход ноды из строя, автоматически поднимает новую с аналогичной конфигурацией. Для приложения это полностью прозрачно и ничем не отличается от выезда админа с запасным юнитом на место хостинга.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не надо цитировать простыни. Надо просто понять, что для детектирования невалидности бэкапа контрольные суммы на уровне ФС не нужны. Достаточно контрольных сумм на уровне контроллера диска. S>Точно так же, как нет смысла впихивать контрольные суммы в сетевой протокол, работающий поверх TCP.
Объясни тогда, зачем ZFS, Btrfs, Postgres (начиная с 9.3 кажется), тот же Hadoop, да что угодно вообще — считают чексуммы для страниц/блоков? Вот я тут привел ссылку на исследование подтверждающее мои слова, на что ты ответил — "не надо цитировать простыни" "надо просто понять"! Это просто потрясающе, аплодирую стоя! Сам же до этого просил ссылку привести
CK>>Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд. S>Вот и я об этом. Я, собственно, про CAP читал в первоисточнике.
Да нет, ты не об этом писал, ты писал про то что CAP — булшит. Хотя очевидно, что человек, который читал и понимает, осознает ее применимость.
CK>>Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости. S>Тогда зачем вы тащите её в рассуждения об availability?
Потому что тема называется "Выбор NoSQL".
CK>>Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. S>Нет, нельзя. По определению.
Надо просто понять ((c) Sinclair), что запрос на запись может отвалиться по таймауту даже если с железом все ОК, нет ошибок конфигурации и всего такого.
S>>>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby. CK>>Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так S>При чём тут абсолютная надёжность? Мы говорим ровно про ненадёжное железо и способы борьбы с этой ненадёжностью. В мире абсолютно надёжных жёстких дисков даже одна нода будет highly available.
Ну это шутка была. Ну просто я не знаю как можно это всерьез обсуждать. Можно наверное было поговорить о том, что машина у меня на самом деле — пяти колесная, ведь я всегда вожу запаску в багажнике! А при единичном сбое машина превращается в 4х колесную, она уже не HA, пока запаску обратно не положишь. Это я к тому, что все это — пустое словоблудство. Я тут вообще про кластер из ~100 машин рассказывал, с которым доводилось работать, откуда вообще взялась эта трех машинная конфигурация в обсуждении?
Здравствуйте, chaotic-kotik, Вы писали: CK>Объясни тогда, зачем ZFS, Btrfs, Postgres (начиная с 9.3 кажется), тот же Hadoop, да что угодно вообще — считают чексуммы для страниц/блоков?
Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
CK>Вот я тут привел ссылку на исследование подтверждающее мои слова
Я не вижу никакого подтверждения. К полному исследованию доступа у меня нет, в процитированной части нет ничего про то, что контроллер может "не заметить" сбой CRC при чтении данных. CK>Да нет, ты не об этом писал, ты писал про то что CAP — булшит. Хотя очевидно, что человек, который читал и понимает, осознает ее применимость.
Пока что я не видел применения CAP ни к чему, кроме рассуждений уровня "мы применяем NoSQL потому, что CAP".
CK>Потому что тема называется "Выбор NoSQL".
О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
А я вам пишу, что HA — это аптайм выше некоторого порога, например 99.99%. И потеря трети или четверти машин сама по себе ничего не значит, т.к. реальный процент аптайма будет зависеть от времени возврата их в строй.
CK>>>Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. S>>Нет, нельзя. По определению. CK>Надо просто понять ((c) Sinclair), что запрос на запись может отвалиться по таймауту даже если с железом все ОК, нет ошибок конфигурации и всего такого.
У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
CK>Ну это шутка была. Ну просто я не знаю как можно это всерьез обсуждать. Можно наверное было поговорить о том, что машина у меня на самом деле — пяти колесная, ведь я всегда вожу запаску в багажнике!
Запаска — плохой пример. Точнее, хороший пример плохой HA. Хороший пример — БТР. У него нет никаких запасок. Тем не менее, ему не страшны повреждения до трёх колёс (если с разных бортов) или 2х с одного.
Вот если бы мы обсуждали дизайн БТР, и вы бы мне впаривали шестиколёсную конфигурацию с двумя запасками (тот самый hot standby), то я бы парировал восьмиколёсной конфигурацией, т.к. она позволяет снизить нагрузку на каждую из шин и сделать их дешевле, при сохранении того же фактора избыточности.
CK>А при единичном сбое машина превращается в 4х колесную, она уже не HA, пока запаску обратно не положишь.
Конечно. А вы не знали? Или вы думали, что наличие запаски обеспечит вам 100% аптайм, независимо от времени ремонта пробитого колеса? Ну так вот нет, не обеспечит. Поэтому опытные собаководы берут с собой две запаски когда едут в такие места, где шиномонтаж занимает слишком много времени.
CK>Это я к тому, что все это — пустое словоблудство. Я тут вообще про кластер из ~100 машин рассказывал, с которым доводилось работать, откуда вообще взялась эта трех машинная конфигурация в обсуждении?
Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA.
Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени?
Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>NTFS не хранит, т.к. CRC и ECC по факту уже реализованы внутри самого диска.
Ког Зачем тогда ReFS? Плюс, CRC совершенно не спасает при "логических" ошибках, когда, например, данные уже обновились, а метаданные -- ещё нет.
S>Bit rot детектится хард драйвом ещё до того, как данные попадут на уровень файловой системы. Более того, благодаря ECC, они сначала корректируются, блок релокируется, и только когда запасных блоков для релокации перестаёт хватать или объём повреждений сектора превышает возможности ECC, мы получаем сбой чтения, заметный на уровне ФС.
Это если безгранично верить в безошибочность Firmware жестких дисков.
S>Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
...As another example, a real-life study performed by NetApp on more than 1.5 million HDDs over 41 months found more than 400,000 silent data corruptions, out of which more than 30,000 were not detected by the hardware RAID controller. Another study, performed by CERN over six months and involving about 97 petabytes of data, found that about 128 megabytes of data became permanently corrupted.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали: Н>Ког Зачем тогда ReFS? Плюс, CRC совершенно не спасает при "логических" ошибках, когда, например, данные уже обновились, а метаданные -- ещё нет.
Я думаю, что ReFS отрабатывает более широкий класс сценариев, чем "обнаружить повреждение блока данных на диске". Как я понял, там хотят устранить нужду в chkdsk, а не отловить ситуации, которые chkdsk отловить неспособен.
Н>Это если безгранично верить в безошибочность Firmware жестких дисков.
Это да. Помнится, ещё в 90х встречались китайские чипы памяти, у которых parity bit вычислялся на ходу .
S>>Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
Н>Однако же:
Там речь идёт об ошибках, которые не были вовремя замечены.
То есть опять не о том, что из контроллера приехал мусор, а о том, что диск протух три месяца назад, а узнали мы об этом только сегодня.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alex.Che, Вы писали:
>> Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров. AC>вот. этим всё и объясняется. AC>"всё чего у нас нету, вам и не нужно..." (с)
Судя по https://docs.oracle.com/cd/B28359_01/server.111/b28318/logical.htm#CIHEIFJC, у Оракла тоже нет чексумм.
Что не мешает и ему входить в тройку лидеров. Ну что, про DB2 будем смотреть, или нуевонах?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В тройку лидеров чего?
S>В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
S>О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
Нет, я не утверждаю что это возможность потерять до трети машин. Я говорил про availability в другом контексте.
S>У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
При этом одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
S>Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA. S>Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени? S>Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно. Это же среднее значение, т.е. ни о чем вообще. Вот например эксплуатируем кластер из 3х машин. У нас было два сбоя, первый сбой вылечился простой перезагрузкой за одну минуту, второй сбой — аппаратный, пришлось ждать новый сервер неделю. Какой будет MTTR и будет ли он иметь хоть какой-то практический смысл?
CK>Вот самое распространенное определение того, что есть availability (из CAP)
Самое распространенное и "из CAP" это разные вещи
CK> "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны.
То есть односерверная машина у нас априори available?
То есть пофиг что внутри происходит, главное ОК вернуть?
То есть пофиг сколько ждать перед тем как ОК вернуть?
Формальные ответы на эти вопросы — ДА, иного в CAP не указано, а на тему времени ответа даже ремарка есть.
И какой смысл в этом определении?
CK>Если система является доступной, в нее можно записывать всегда.
Но это не означает, что потом можно будет прочитать. То есть в грубом приближении AP система это /dev/null.
CK>Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
Availability это не свойство железа, а свойство системы (железа, каналов связи, логики серверов, логики клиентов). Определяется как процент времени когда система способна отвечать на запросы за разумное (заранее определённое) время и сохранять работоспособность. Для этого нужно в первую очередь поддерживать аптайм железа, чтобы серваки не падали и поддерживать логику работы.
При этом вовсе не требуется, чтобы на каждый запрос возвращался ОК, вполне возможно повторение запроса на клиенте, если сервер недоступен или отвечает "обратитесь позже". Так устроены многие протоколы от REST до TCP\IP.
Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
Здравствуйте, chaotic-kotik, Вы писали: CK>В тройку лидеров чего?
RDBMS.
CK>Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются
Воот. Это мы разобрались с вопросом "можно ли вообще определить, что backup нечитаем". Или вы имели в виду "не пытаясь его восстановить"? Нет, без специальных усилий определить, жив ли ещё backup, невозможно.
CK>и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
ECC и CRC — это разные вещи. Обнаружить ошибку гораздо легче, чем исправить. Про прозрачное восстановление данных никто и не намекал — это было бы слишком хорошо, чтобы быть правдой.
На практике я пока не видел вменяемых SMART — инструментов (по крайней мере для локального использования). Т.е. в теории у нас есть методика предсказания скорой смерти диска, которая может нам помочь выбрать момент для замены до того, как произойдёт необратимая потеря. Скажем, тулзы от Леново продолжают говорить что SMART Test is Ok даже после того, как на диске перестало читаться 10% секторов.
CK>Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Это бесполезное определение, потому что под него либо не попадают вообще никакие системы, либо попадают сразу все — в зависимости от того, что мы считаем за failing node.
Например, вы вспотеете писать веб-сервис, который никогда-никогда-никогда не вернёт 50x ошибку (а must и every — это именно никогда-никогда).
CK>Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
Конечно. Вот та availability, которая принята в CAP — она не может быть high либо low. Она либо есть (что в жизни вы никогда не достигнете), либо её нет (как на самом деле и бывает, жертвуешь ли ты consistency или partition tolerance или не жертвуешь).
CK>При этом одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
Нет. Если у нас 50% запросов получают 50х, то availability будет 50%. Причём неважно, связано это с тем, что у нас каждый вечер ложится блок питания, и запуск его делает Вася, приезжая к 8:00 в датацентр, или с тем, что каждый второй запрос переполняет request queue.
Если у нас запланирован апгрейд нашего единственного сервера раз в квартал, и в течение 24 часов он каждый раз недоступен, то несмотря на 100% надёжное железо Availability никак не сможет быть выше двух девяток.
Чтобы поднять её до трёх девяток, потребуется как минимум две машины, чтобы можно было обслуживать их по очереди. Это как раз самая частая конфигурация для слабонагруженных высокодоступных приложений.
В том-то и коварство CAP, что она применяет категоричные термины там, где нужна некоторая мягкость. В том смысле, что в реальных системах всегда выбирают компромисс — например, жертвуют некоторой долей consistency ради увеличения availability. А в CAP всё тупо — "ой, раз вы требуете availability, то давайте откажемся от consistency, заменив её на eventual consistency".
При этом eventual consistency — тоже оксюморон. Её не имеет смысла обсуждать, не имея количественных метрик. Вот, допустим, если баланс вашего счёта у сотового оператора отстаёт на пять минут от реального времени, то вам, скорее всего, на это наплевать. А вот если окажется, что оператор собирается вам выставлять "потерянные" счета в течение ещё пяти лет после разрыва контракта, то скорее всего это не устроит ни его, ни вас.
Поэтому реализуются компромиссные системы, в которых и availability неполная, и consistency неидеальная.
CK>Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно.
Не для доказательства, а для иллюстрации. Для того, чтобы по честному рассчитать Availability, нужно иметь и модель сбоев, и модель восстановления. MTBF и MTTR подразумевают стохастический характер сбоев, и удобны только тем, что ими легко манипулировать в формулах, и наглядно видеть, как строить надёжные системы из ненадёжных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
>>> Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров. AC>>вот. этим всё и объясняется. AC>>"всё чего у нас нету, вам и не нужно..." (с) S>нуевонах? PAGE_VERIFY
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, gandjustas, Вы писали:
G>То есть односерверная машина у нас априори available?
Да, но CAP не применяют для анализа односерверных систем. Ну ты можешь попробовать, конечно, но это странно.
G>То есть пофиг что внутри происходит, главное ОК вернуть?
Формально — да.
G>То есть пофиг сколько ждать перед тем как ОК вернуть?
Конечно, тем не менее это не опровергает корректность CAP (это было показано в статье Нэнси Линч и еще какого-то чувака, которую ты в своей статье для хабра цитируешь).
G>И какой смысл в этом определении?
CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
На практике это означает, что CP система может обрабатывать запрос на запись или чтение произвольное время, так как на каждый запросу будет запущен раунд консенсуса (raft, zab, paxos), положительный результат при этом не гарантирован, т.е. на свой запрос ты можешь получить ответ, означающий что кворум не получен и запись(или чтение) не прошла. AP система не будет гонять консенсус на каждый запрос чтения/записи, она может, например, в ответ на запрос на запись, записать данные в локальное хранилище, вернуть положительный ответ, а потом, асинхронно (например через gossip протокол) распространить твое изменение по кластеру (или его части).
G>Но это не означает, что потом можно будет прочитать. То есть в грубом приближении AP система это /dev/null.
Можно представить AP систему, работающую как /dev/null, но это не значит, что нельзя создать AP систему, имеющую полезные свойства.
G>Availability это не свойство железа, а свойство системы (железа, каналов связи, логики серверов, логики клиентов). Определяется как процент времени когда система способна отвечать на запросы за разумное (заранее определённое) время и сохранять работоспособность. Для этого нужно в первую очередь поддерживать аптайм железа, чтобы серваки не падали и поддерживать логику работы. G>При этом вовсе не требуется, чтобы на каждый запрос возвращался ОК, вполне возможно повторение запроса на клиенте, если сервер недоступен или отвечает "обратитесь позже". Так устроены многие протоколы от REST до TCP\IP.
Еще раз, мы обсуждаем NoSQL, можно себе представить (легко) систему, которая полностью работоспособна, никаких ошибок нет и в помине, при этом система может быть недоступной в терминах CAP и запрос на запись у тебя будет отваливаться по таймауту иногда. При этом даунтайма нет, каждый хост пингуется, каждый endpoint принимает входящие подключения и отвечает на запросы.
Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего. G>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
Wat?
G>Писал об этом на хабре https://habrahabr.ru/post/231703/
Статья очень спорная.
Вот это понравилось:
Разделение сети — крайне редкое явление в наше время. Гилберт и Линч прямо заявляют, что системы, работающие в локальной сети, можно считать не подверженными разделению.
Статья написана академиками (а не практикующими инженерами) в 2002-м году. В 2014-м году никто в академическом сообществе так больше никто не считал. Рекомендую ознакомиться со статьей Network Is Reliable. Пара цитат:
Stop-the-world garbage collection and blocking for disk I/O can cause runtime latencies on the order of seconds to minutes. As Searchbox IO and several other production users (https://github.com/elasticsearch/elasticsearch/issues/2488) have found, GC (garbage collection) pressure in an ElasticSearch cluster can cause secondary nodes to declare a primary dead and to attempt a new election. Because of nonmajority quorum configuration, ElasticSearch elected two different primaries, leading to inconsistency and downtime. Surprisingly, even with majority quorums, due to protocol design, ElasticSearch does not currently prevent simultaneous master election; GC pauses and high IO_WAIT times due to I/O can cause split-brain behavior, write loss, and index corruption.
On July 18, 2013, Twilio's billing system, which stores account credits in Redis, failed.19 A network partition isolated the Redis primary from all secondaries. Because Twilio did not promote a new secondary, writes to the primary remained consistent. When the primary became visible to the secondaries again, however, all secondaries simultaneously initiated a full resynchronization with the primary, overloading it and causing Redis-dependent services to fail.
The ops team restarted the Redis primary to address the high load. Upon restart, however, the Redis primary reloaded an incorrect configuration file, which caused it to enter read-only mode. With all account balances at zero, and in read-only mode, every Twilio API call caused the billing system to recharge customer credit cards automatically, resulting in 1.1 percent of customers being overbilled over a period of 40 minutes. For example, Appointment Reminder reported that every SMS message and phone call it issued resulted in a $500 charge to its credit card, which stopped accepting charges after $3,500.
Здравствуйте, Sinclair, Вы писали:
CK>>Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда. S>Это бесполезное определение, потому что под него либо не попадают вообще никакие системы, либо попадают сразу все — в зависимости от того, что мы считаем за failing node. S>Например, вы вспотеете писать веб-сервис, который никогда-никогда-никогда не вернёт 50x ошибку (а must и every — это именно никогда-никогда).
Ну тут имеется ввиду не это, а гарантия liveness. Процесс должен завершиться за ограниченное время и он не может отвалиться только потому что что-то плохое произошло с другой машиной, а не той, к которой мы обращаемся. СР система может отдуплить запрос по причине того что где-то что-то пошло не так и кворума нет. АР система запишет в любом случае. Ес-но определение относится к идеализированным машинам из CAP, реальная АР система может вернуть ошибку более низкого уровня, если, например, клиент БД неправильно сконфигурирован, соединение с узлом БД разорвалось и тд. Но это ошибка более низкого уровня, а не ошибка уровня приложения "повтори запрос еще раз чуть позже".
S>Конечно. Вот та availability, которая принята в CAP — она не может быть high либо low. Она либо есть (что в жизни вы никогда не достигнете), либо её нет (как на самом деле и бывает, жертвуешь ли ты consistency или partition tolerance или не жертвуешь).
Думаю что это верно. Но на практике, под HA все имеют ввиду разное, но чаще всего не одну только доступность в оригинальном смысле. В общем, когда на сайте rabbit mq описывают HA-кластер rabbit-mq это может означать сильно не то, о чем ты говоришь.
S>В том-то и коварство CAP, что она применяет категоричные термины там, где нужна некоторая мягкость. В том смысле, что в реальных системах всегда выбирают компромисс — например, жертвуют некоторой долей consistency ради увеличения availability. А в CAP всё тупо — "ой, раз вы требуете availability, то давайте откажемся от consistency, заменив её на eventual consistency".
Про это же 100500 статей уже написано. На практике же чистых AP|CP систем практически не бывает. Тот же zookeeper это СР система, но ты можешь легко прочитать stale данные, если захочешь, т.е. запросы на запись работают как СР а на чтение как АР (или как СР, если читать по другому). САР это просто способ описывать все эти компромиссы и особенности.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Ну тут имеется ввиду не это, а гарантия liveness. Процесс должен завершиться за ограниченное время и он не может отвалиться только потому что что-то плохое произошло с другой машиной, а не той, к которой мы обращаемся. СР система может отдуплить запрос по причине того что где-то что-то пошло не так и кворума нет. АР система запишет в любом случае. Ес-но определение относится к идеализированным машинам из CAP, реальная АР система может вернуть ошибку более низкого уровня, если, например, клиент БД неправильно сконфигурирован, соединение с узлом БД разорвалось и тд. Но это ошибка более низкого уровня, а не ошибка уровня приложения "повтори запрос еще раз чуть позже".
Опять какие-то высосанные из пальца термины.
1. "Ограниченное время" — это что? Ограниченное чем? Если мы ограничим его, скажем, миллионом секунд, то даже ручная установка нового сервера в датацентр уложится в норматив.
2. Какое дело клиенту до того, из-за чего отвалился "процесс" — оттого, что другая машина сломалась/оказалась недоступной, или оттого, что внутри этой машины отказал HDD или сетевая карточка?
Вообще, проблемы с коммуникациями в принципе не позволяют отличить ситуацию неработоспособности моей машины от неработоспособности удалённой машины.
CK>Думаю что это верно. Но на практике, под HA все имеют ввиду разное, но чаще всего не одну только доступность в оригинальном смысле.
На практике, можно просто сходить в wikipedia. Там написано самое общепринятое из всех общепринятых определений. CK>В общем, когда на сайте rabbit mq описывают HA-кластер rabbit-mq это может означать сильно не то, о чем ты говоришь.
Ещё раз: термин HA обязан обозначать количественную меру availability. Просто потому, что иначе невозможно говорить о high либо low.
Rabbit-mq описывает, как увеличить availability очередей ровно в том смысле, который туда вкладываю я — потому, что он решает вопрос availability очереди при штатном либо нештатном выключении ноды.
Таким образом, если у вас есть процедуры для достаточно быстрой замены упавших нод, то вы можете обеспечить, в принципе, любые количества девяток после запятой.
Ещё раз повторю очевидную истину, доступную немногим: если у вас таких процедур нет, то никакой HA у вас тоже нету. Если вы запустите кластер из 10 машин с периодом полураспада в полгода, настроите репликацию очереди по 10 экземплярам, и забьёте на обслуживаение, то система нагнётся примерно
S>>В том-то и коварство CAP, что она применяет категоричные термины там, где нужна некоторая мягкость. В том смысле, что в реальных системах всегда выбирают компромисс — например, жертвуют некоторой долей consistency ради увеличения availability. А в CAP всё тупо — "ой, раз вы требуете availability, то давайте откажемся от consistency, заменив её на eventual consistency".
CK>САР это просто способ описывать все эти компромиссы и особенности.
Очень странно приводить бескомпромиссную модель как способ описания компромиссов. Тем более, когда мы сравниваем качественно эквивалентные вещи — к примеру, живую репликацию с бэкапом.
Они отличаются исключительно количественно — по стоимости владения и обеспечиваемому MTTR. А он, в свою очередь, непосредственно влияет на ту самую Availability, которая общепринято эквивалента проценту аптайма.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, chaotic-kotik, Вы писали:
CK>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
G>>То есть в грубом приближении AP система это /dev/null. CK>Можно представить AP систему, работающую как /dev/null, но это не значит, что нельзя создать AP систему, имеющую полезные свойства.
Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
CK>Еще раз, мы обсуждаем NoSQL, можно себе представить (легко) систему, которая полностью работоспособна, никаких ошибок нет и в помине, при этом система может быть недоступной в терминах CAP и запрос на запись у тебя будет отваливаться по таймауту иногда. При этом даунтайма нет, каждый хост пингуется, каждый endpoint принимает входящие подключения и отвечает на запросы.
И? С точки зрения клиента клиента все равно недоступна система или не может выполнить запрос. С точки зрения cap это разные явления
CK>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
Но тогда появляется гораздо интереснее сценарий.
Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
Ты же сам привел аналогичный пример ниже.
Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего. G>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время. CK>Wat?
Твои примеры ниже прекрасно иллюстрируют что я говорю.
CK>Статья написана академиками (а не практикующими инженерами) в 2002-м году. В 2014-м году никто в академическом сообществе так больше никто не считал. Рекомендую ознакомиться со статьей Network Is Reliable. Пара цитат:
По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
Здравствуйте, 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 же.
Здравствуйте, chaotic-kotik, Вы писали:
G>>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA? CK>Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже. CK>Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
Так всетаки про какой availability идет речь в контексте NoSQL? Который CAP или который общечеловечский?
G>>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких. CK>На практике, это важно тогда, когда возможность сохранить данные важнее целостности.
В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки.
Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null.
CK>Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения.
Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться?
Если бы клиент мог управлять свойствами системы при записи или можно было бы поделить систему на CA\CP\AP куски заранее, то проблема бы решалась. Но на практике мы этого не видим.
CK>Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
и?
G>>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой. CK>Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
Прости, но CAP рассматривает свойства бинарно, либо есть, либо нет. Нельзя быть немного беременным.
На практике это означает, что большинство систем только притворяются partition tolerant или имеют это свойство в readonly режиме. А при записи теряют сразу все свойства
CK>>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success. G>>Но тогда появляется гораздо интереснее сценарий. G>>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги. G>>Ты же сам привел аналогичный пример ниже.
CK>Биллинг можно сделать на чем-нибудь другом.
Тогда и все остальное можно сделать на другом.
На этом предлагаю закончить.
CK>Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
Потому что записи, пришедшие в разные ноды вызовут конфликт и не факт что его вообще можно решить. Eventual consistency реально работает, когда нет записей на протяжении интервала достижения согласованности. Это у Гилберт и Линч написано черным по английскому.
Я на хабре приводил пример с продажей билетов.
G>>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы. CK>Вывод из этого следует такой — нельзя делать системы без partition tolerance.
Все указанные в примерах системы были AP
Получается нельзя строить системы без consistency. Ровно о том, что я говорю.
G>>Единственный живой вариант — делать CA системы, то есть кворумы с node majority. CK>Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится.
За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают.
G>>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency. CK>Tradeoff же.
Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД.
Здравствуйте, gandjustas, Вы писали:
G>Так всетаки про какой availability идет речь в контексте NoSQL? Который CAP или который общечеловечский?
Я уже запутался. Я топил за NoSQL и availability в этом контексте, Sinclair за все хорошее и против всего плохого.
G>В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки. G>Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null.
Костыль же жуткий. Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь. Помимо этого нужно будет как-то прозрачно дать доступ к тому что ты хранишь в памяти. Намного проще писать в эластик, например, и не думать об этом вообще. А если запись отвалилась — то выбрать следующую ноду по round robin и продолжать писать в нее. К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.
G>Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться?
Так никто ведь не заставляет в такой БД хранить такие данные, для которых ты не можешь разрулить конфликт.
G>Если бы клиент мог управлять свойствами системы при записи или можно было бы поделить систему на CA\CP\AP куски заранее, то проблема бы решалась. Но на практике мы этого не видим.
Обычно так и есть. В той же монге, у клиента есть возможноть тупо записать данные в хранилище, как в АР систему, безусловно. А можно сделать CAS update и получить CP систему на уровне одного документа. Или вот zookeeper — по дефолту запись туда — СР, а чтение — АР. На запись запускается консенсус, а на чтение нет, поэтому даже если запись невозможна(отсутствует связь с большинством машин), можно все равно читать старые данные. Но можно читать данные через sync и в этом случае консенсус будет гоняться на чтение и оно будет уже не АР а СР.
CK>>Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе. G>и?
И латентность будет ниже, а пропускная способность выше.
G>Прости, но CAP рассматривает свойства бинарно, либо есть, либо нет. Нельзя быть немного беременным. G>На практике это означает, что большинство систем только притворяются partition tolerant или имеют это свойство в readonly режиме. А при записи теряют сразу все свойства
Не понял ход мысли. Смотри, можно как zookeeper или etcd гонять консенсус для всех транзакций и обеспечивать с его помощью полную линеаризуемость, можно не гонять его для операций чтения, только для записи и получить сериализуемость. Можно разделить данные на части и гонять консенсус только для тех данных, которые должны быть согласованными, а для тех что не должны, можно гонять консенсус параллельно (например можно иметь транзакции, работающие в рамках одной таблицы или одной записи/документа, получится что если мы пишем в два документа, то две параллельные транзакции запустят два независимых инстанса алгоритма консенсуса, это работает быстрее и лучше масштабируется, но нельзя согласовать данные в двух документах).
CK>>Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время? G>Потому что записи, пришедшие в разные ноды вызовут конфликт и не факт что его вообще можно решить. Eventual consistency реально работает, когда нет записей на протяжении интервала достижения согласованности. Это у Гилберт и Линч написано черным по английскому. G>Я на хабре приводил пример с продажей билетов.
И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.
CK>>Вывод из этого следует такой — нельзя делать системы без partition tolerance. G>Все указанные в примерах системы были AP
В статье есть примеры и с VoltDB и с монгой.
G>Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится.
Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками. Ну это работает, я согласен, так можно жить. Но это не CA система. В зависимости от того как ты выбираешь мастера — система может быть СР, так как если поляжет больше половины машин, ты просто не выберешь нового мастера. Я конечно не знаю как там все работает, но подозреваю, что если нет автоскейлинга и failure детектора, то кластер не поймет что для консенсуса нужно меньше машин, а если он есть и алгоритм выбора лидера не partition tolerant, то две независимые части могут выбрать себе по мастеру.
G>За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают.
А как данные реплицируются и откуда клиенты читают данные? Просто если стойки друг друга не видят, то где гарантия что ты не прочитаешь устаревшие данные? Данные на slave-е могут быть непротиворечивыми с точки зрения ACID гарантий, но при этом отличаться от мастера.
G>Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД.
Я бы сказал что не существует дефолтного решения. РСУБД это клево и очень широко применимо (а многим адептам NoSQL нужно просто выучить SQL наконец и выкинуть монгу на помойку), но не универсально, как и NoSQL решения. Я не могу представить РСУБД кластер, который будет в состоянии заменить наш сетап
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки. G>>Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null. CK>Костыль же жуткий.
Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь.
CK>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь.
Тогда и распределенной базы будет та же проблема.
CK>Помимо этого нужно будет как-то прозрачно дать доступ к тому что ты хранишь в памяти. Намного проще писать в эластик, например, и не думать об этом вообще. А если запись отвалилась — то выбрать следующую ноду по round robin и продолжать писать в нее.
Да, всего-то пару серверов нужно еще, со всеми вытекающими проблемами
CK>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.
Ты точно делал веб-сервисы? По процессу на запрос это сильно.
G>>Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться? CK>Так никто ведь не заставляет в такой БД хранить такие данные, для которых ты не можешь разрулить конфликт.
Я бы больше сказал, я даже не хочу разруливать конфликты, хочу чтобы конкурентный доступ база на себя взяла, она для этого создана. Внезапно NoSQL при такой постановке вопроса начинают сосать. И сразу вспоминают про CAP.
CK> На запись запускается консенсус, а на чтение нет, поэтому даже если запись невозможна(отсутствует связь с большинством машин), можно все равно читать старые данные. Но можно читать данные через sync и в этом случае консенсус будет гоняться на чтение и оно будет уже не АР а СР.
Когда кто-нить запилит продажу билетов на такой системе я поверю, что она жизнеспособна, пока только голословные заверения.
CK>И латентность будет ниже, а пропускная способность выше.
Про быстродействие еще ни слова не было.
CK>Смотри, можно как zookeeper или etcd гонять консенсус для всех транзакций и обеспечивать с его помощью полную линеаризуемость, можно не гонять его для операций чтения, только для записи и получить сериализуемость. Можно разделить данные на части и гонять консенсус только для тех данных, которые должны быть согласованными, а для тех что не должны, можно гонять консенсус параллельно (например можно иметь транзакции, работающие в рамках одной таблицы или одной записи/документа, получится что если мы пишем в два документа, то две параллельные транзакции запустят два независимых инстанса алгоритма консенсуса, это работает быстрее и лучше масштабируется, но нельзя согласовать данные в двух документах).
Обязательно посмотрю на zookeeper.
CK>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.
Давай подробный сценаий кто к кому и вкакой момент обращается.
CK>>>Вывод из этого следует такой — нельзя делать системы без partition tolerance. G>>Все указанные в примерах системы были AP CK>В статье есть примеры и с VoltDB и с монгой.
Про VoltDB не в курсе, а монго — AP при чтении (возвращает мусор), а при записи вообще гарантий не дает.
G>>Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится. CK>Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками.
Автоскейлинг мешает знать состав кластера?
CK>Ну это работает, я согласен, так можно жить. Но это не CA система. В зависимости от того как ты выбираешь мастера — система может быть СР, так как если поляжет больше половины машин, ты просто не выберешь нового мастера. Я конечно не знаю как там все работает, но подозреваю, что если нет автоскейлинга и failure детектора, то кластер не поймет что для консенсуса нужно меньше машин, а если он есть и алгоритм выбора лидера не partition tolerant, то две независимые части могут выбрать себе по мастеру.
В реальности вероятность полегания двух машин из трех в кластере мала, менее 0,01%, то есть 4 девятки на них спокойно живут.
G>>За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают. CK>А как данные реплицируются и откуда клиенты читают данные? Просто если стойки друг друга не видят, то где гарантия что ты не прочитаешь устаревшие данные? Данные на slave-е могут быть непротиворечивыми с точки зрения ACID гарантий, но при этом отличаться от мастера.
Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две.
G>>Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД. CK>Я бы сказал что не существует дефолтного решения. РСУБД это клево и очень широко применимо (а многим адептам NoSQL нужно просто выучить SQL наконец и выкинуть монгу на помойку), но не универсально, как и NoSQL решения. Я не могу представить РСУБД кластер, который будет в состоянии заменить наш сетап
Я бы сказал что существует, пока нет серьезных оснований использовать что-то другое.
По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы.
Здравствуйте, gandjustas, Вы писали:
G>Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь.
И как это решает пролему latency? Throughput — да, согласен, можно батчингом на клиенте заниматься. Но это ломает crush recovery и латентность увеличивает.
CK>>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь. G>Тогда и распределенной базы будет та же проблема.
Может конечно. Но тут есть варианты всегда, в тот же HBase можно писать данные так, чтобы нагрузка равномерно распределялась по regionserver-ам. Для этого нужно правильную схему выбрать, вот и вся сложность.
CK>>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД. G>Ты точно делал веб-сервисы? По процессу на запрос это сильно.
Так работает apache с mod_php в prefork MPM режиме. На каждый http реквест запускается новый процесс. Соотв. весь стейт живет в БД и всяких мемкешах и прочих редисах. Я участвовал в разработке веб портала с милионной аудиторией в одной очень известной российской компании.
CK>>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе. G>Давай подробный сценаий кто к кому и вкакой момент обращается.
Ты делаешь чекаут и проводишь оплату внутренней валютой. Транзакция не уменьшает баланс, а добавляет операцию в список операций над твоим балансом, commit транзакции выполняется через консенсус (Paxos например). Такое можно нарулить на кассандре, например.
CK>>Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками. G>Автоскейлинг мешает знать состав кластера?
Не мешает, просто автоскейлинг означает не только то, что машины могут добавляться в кластер автоматически, но и то, что они оттуда могут точно также выбывать. Допустим у нас 3 машины. Моргнула сеть, машина (мастер), живущая в отдельной стойке, стала недоступна. Но так как этого "не может быть" (система построена из расчета что сеть абсолютно надежна и partition-ов не бывает) система должна решить что эта машина умерла, правильно? И что она в этом случае делает? Логично выбрать нового мастера из оставшихся двух живых и считать что старый мастер покинул кластер (кластер теперь состоит из двух машин). При этом временно изолированный на отдельной стойке мастер продолжает считать себя мастером, недоступные две оставшиеся машины он считает покинувшими кластер (автоскейлинг же).
G>Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две.
Ну т.е. обычный master-slave без шардинга.
G>По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы.
Ну монга это вообще булшит, понятно что постгрес лучше. Единственный плюс монги — простота развертывание и настройки, поэтому ее в основном используют для всяких мелких CRUD-ов.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь. CK>И как это решает пролему latency? Throughput — да, согласен, можно батчингом на клиенте заниматься. Но это ломает crush recovery и латентность увеличивает.
А есть эта проблема?
Вообще подходы такие:
1) Нужно часто читать и нечасто записывать (типичное приложение) — используем кэш
2) Нужно часто записывать и нечасто читать (ака логи, репортинг) — примитивный сторедж на запись (локальный диск) и асинхронная постобработка
3) Нужно часто читать и писать отдельные куски (соцсети) — разбиваем модель данных на маленькие несвязанные кусочки, кусочки держим и обновляем в кеше, при записи или изолируем IO кусочков (шардинг, разные диски) или применяем метод из 2
4) Нужно часто писать и читать агрегированные данные — stream processing, то есть держим в памяти данные для агрегации, пишем только агрегаты.
Я так понимаю, что мы про пункт №2 сейчас
CK>>>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь. G>>Тогда и распределенной базы будет та же проблема. CK>Может конечно. Но тут есть варианты всегда, в тот же HBase можно писать данные так, чтобы нагрузка равномерно распределялась по regionserver-ам. Для этого нужно правильную схему выбрать, вот и вся сложность.
Опять для простой задачи — "как бы сделать так, чтобы весь поток данных записывался за ограниченное время в случаях отказа\недоступности серверов бд" вы пытаетесь продать решение, которое требует еще несколько серверов. Это приведет или к замедлению за счет кворума или к потере согласованности, что хуже, чем иногда давать клиенту ответ "сейчас не могу, попробуй позже".
CK>>>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД. G>>Ты точно делал веб-сервисы? По процессу на запрос это сильно.
CK>Так работает apache с mod_php в prefork MPM режиме. На каждый http реквест запускается новый процесс. Соотв. весь стейт живет в БД и всяких мемкешах и прочих редисах. Я участвовал в разработке веб портала с милионной аудиторией в одной очень известной российской компании.
Вас никто не заставляет также делать. Пользуйтесь нормальными серверами. IIS например и нормальными базами — SQL Server, а не mysql.
Сразу количество проблем с РСУБД и вебом поубавится и всякие "леворезьбовые" технологии не понадобятся.
CK>>>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе. G>>Давай подробный сценаий кто к кому и вкакой момент обращается.
CK>Ты делаешь чекаут и проводишь оплату внутренней валютой. Транзакция не уменьшает баланс, а добавляет операцию в список операций над твоим балансом, commit транзакции выполняется через консенсус (Paxos например). Такое можно нарулить на кассандре, например.
Не так быстро:
1) У тебя есть две ноды, которые асинхронно реплицируют данные и в любой момент может потеряться любое количество пакетов между узлами и клиентами.
2) У тебя есть приложение, которое в момент чекаута добавляет проводку в базу
3) Ты хочешь чтобы транзакция проходила всегда
4) Ты пытаешься добавить проводку сразу в две ноды
5) Но вторая нода оказывается недоступна, там баланс не меняется.
6) В этот же момент с друого сервера приложений отправляется аналогичная команда на снятие внутренней валюты, но для нее теперь певая нода недоступно
7) Получается у тебя две ноды, на одной баланс -50, на второй -70
8) Но на счете всего было 100 до начала двух транзакций.
CAP в этом случае не обманешь. AP системы не подходят для хранения важных данных (которые нельзя исказить, потерять, нарушить инварианты) в принципе. Прикладные механизмы разрешения конфликтов не помогут, ты можешь конфликт обнаружить позже, чем будет принято решение на основании неверных данных.
CK>>>Это если нет автоскейлинга, заранее известен состав клас
тера и машины добавляются в него ручками. G>>Автоскейлинг мешает знать состав кластера? CK>Не мешает, просто автоскейлинг означает не только то, что машины могут добавляться в кластер автоматически, но и то, что они оттуда могут точно также выбывать. Допустим у нас 3 машины. Моргнула сеть, машина (мастер), живущая в отдельной стойке, стала недоступна. Но так как этого "не может быть" (система построена из расчета что сеть абсолютно надежна и partition-ов не бывает) система должна решить что эта машина умерла, правильно? И что она в этом случае делает? Логично выбрать нового мастера из оставшихся двух живых и считать что старый мастер покинул кластер (кластер теперь состоит из двух машин). При этом временно изолированный на отдельной стойке мастер продолжает считать себя мастером, недоступные две оставшиеся машины он считает покинувшими кластер (автоскейлинг же).
Нет, node majority не так работает. Было 9 машин, сеть разделилась на 5 и 4. Там где 4 — не будет кворума, кластер не поднимется.
G>>Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две. CK>Ну т.е. обычный master-slave без шардинга.
Да. По сути единственно рабочий вариант. Все multimnaster системы страдают от нарушения согласованности, чего в большинстве случаев допускать нельзя.
Шардинг это вообще не про доступность, а про деление нагрузки на разные физические узлы. В случае субд не нужно, они масштабируются путем добавления дисков, а не серверов.
G>>По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы. CK>Ну монга это вообще булшит, понятно что постгрес лучше. Единственный плюс монги — простота развертывание и настройки, поэтому ее в основном используют для всяких мелких CRUD-ов.
Тем не менее самая массовая NoSQL база.
