Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
ANS>Это уже "Рабонович" поёт. Первоисточник тут http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf . Там упор на линейный порядок между запросами. Что для меня вполне логично — мне нравится, когда я могу прочитать то, что записал. В отличии от
А при нелинейном порядке ты не сможешь прочитать что записал? Как оно вообще связано?
Ты как-то постоянно подменяешь понятия на желаемые.
G>>Берем такую штуку как SQL Azure. Известно что она Fault Tolerant и Available (это гарантирует Microsoft большим количеством девяток), ANS>Большое колличество это: a “Monthly Availability” of 99.9% during a calendar month.
Где ты такое прочитал?
The goal for Microsoft SQL Azure is to maintain 99.9 percent availability for the subscribers’ databases.
each subscriber’s data is actually stored multiple times, replicated across three SQL Server databases that are distributed across three physical servers in a single data center.
ANS>/.../
ANS>Each database hosted in the SQL Azure data center has three replicas: one primary replica and two secondary replicas. All reads and writes go through the primary replica, and any changes are replicated to the secondary replicas asynchronously.
ANS>/.../
ANS>the primary replica and at least one of the secondary replicas must confirm that the log records have been written before the transaction is considered to be committed.
ANS>/.../
ANS> Because it may take up to 30 seconds for the information about the new primary replica to propagate through all the gateway servers, the best practice is to try to reconnect several times with a smaller wait time after each failed attempt.
ANS>/.../
Нужно очень сильно постараться чтобы нарваться на такую ситуацию: падение primary replica + не успели еще все изменения на другие реплики записаться.
Если такое происходит не чаще раза в месяц и действительно не больше 30 секунд, то это примерно 5 девяток.
Это таки высокий класс доступности. Надо посмотреть сколько оно там реально получается.
G>>Или CAP работает когда к любому узлу системы могут "снаружи" обратиться клиенты? ANS>В роли клиента может рассматриваться не конечный пользователь/приложение, а лоад-балансер.
Не, меня как раз интересует с точки зрения внешнего клиента, а не внутренних механизмов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>NoSQL — хранилища, которые так себя позиционируют. G>>>>SQL — современные, как говорится mature, СУБД общего назначения. ANS>>>Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально. G>>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
ANS>Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.
Еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Здравствуйте, gandjustas, Вы писали:
G>>>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем. ANS>>Ну как знаешь. Если ты считаешь, что durability можно обеспечить сложив все яйца в одну корзину, то так и считай. Я вроде всё что мог, то и написал. G>Ты путаешь durability и восстановление после критического сбоя.
В определении "durability" нет разделения на критический и не критический сбой. Это делает это определение не практичным. Из-за чего от "durability" осталось "данные запишуться если винда глюконёт".
G>>>Причем реально вырождается это в CA-tradeoff. ANS>>Нет. G>Ок, у тебя есть приложение, оно читает из базы на той же машине и дает пользователю редактировать данные. Как ты согласованость данных и доступность для других пользователей обеспечишь одновременно?
Какие сложности?
G>Еще раз, C в CAP совершенно никак не относится к согласованности данных. G>А вот как раз согласованность данных никому не нужна. Я на своей практики не встретился со случаем где мне нужна согласованность данных межу "узлами" приложение — субд между на протяжении нескольких запросов.
Убил опять. Как писать программу если ты не можешь прочитать то, что записал?
Кстати о "никому не нужна":
Consistent Reads provide the ability to specify the consistency characteristic you require for each read call within your application, with an eventually consistent read optimized for lowest latency and highest throughput and a consistent read that provides “read my last write” capability.
G>Он именно каждым программистом по-отдельности по своему разумению делается, потому что задачи разные.
Задачи разные, а гарантии одни и те же. И обычно получается, что сделанное по своему разумению, это что-то гарантировать в большинстве случаев и иногда ничего не гарантировать вообще. Я предпочитаю гарантированные гарантии негарантированным гарантиям.
PS. Целый день в форуме потерял. Всё, больше ничего не пишу, только позже оформлю обещанное
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт.
S>>Это стёб, я надеюсь?
ANS>Это правда жизни. Реальность, данная нам в ощущениях А вся веселуха начинается, когда пользователь узнаёт, что у него бек-ап месячной давности и тот не поднимается. Durability это вам не хухры-мухры.
В таком случае, беседовать особо не о чем. Не обижайтесь, но незнание матчасти поправимо. А вот пользователи, которые должны терпеть результаты самодовольного "А нужно нам что попроще" — это уже верх непрофессионализма
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем. ANS>>>Ну как знаешь. Если ты считаешь, что durability можно обеспечить сложив все яйца в одну корзину, то так и считай. Я вроде всё что мог, то и написал. G>>Ты путаешь durability и восстановление после критического сбоя.
ANS>В определении "durability" нет разделения на критический и не критический сбой.
Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь.
Критический сбой это как раз такой который повреждает физическое хранилище.
Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.
G>>>>Причем реально вырождается это в CA-tradeoff. ANS>>>Нет. G>>Ок, у тебя есть приложение, оно читает из базы на той же машине и дает пользователю редактировать данные. Как ты согласованость данных и доступность для других пользователей обеспечишь одновременно? ANS>Какие сложности?
Покажи решение.
G>>Еще раз, C в CAP совершенно никак не относится к согласованности данных. G>>А вот как раз согласованность данных никому не нужна. Я на своей практики не встретился со случаем где мне нужна согласованность данных межу "узлами" приложение — субд между на протяжении нескольких запросов.
ANS>Убил опять. Как писать программу если ты не можешь прочитать то, что записал?
Да спокойно. Очень многие системы имеют время на propagation изменений.
Даже в этой теме пример пробегал.
G>>Он именно каждым программистом по-отдельности по своему разумению делается, потому что задачи разные. ANS>Задачи разные, а гарантии одни и те же. И обычно получается, что сделанное по своему разумению, это что-то гарантировать в большинстве случаев и иногда ничего не гарантировать вообще. Я предпочитаю гарантированные гарантии негарантированным гарантиям.
Есть всего два способа. Называемые "пессимистичные" и "оптимистичные" блокировки. Первые делаются автоматически при удержании транзакции, вторые оыбчно уже встроены в фреймворк работы с данными. Ты только принимаешь решение что использовать в зависимости от задачи.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php ANS>Ты путаешь "UNDO log" и лог транзакций.
Я вот тут примерно представляю кто чего путает... =)
лог транзакций может быть нескольких типов undo only/redo only/undo redo/... Что не мешает ему в любом случае оставаться логом транзакций.
Да, известны базы без логов (FB, кажется такая), но за это призодится платить долгим коммитом, откатом, временем восстановления.
Как устроен постгри не знаю, но большая часть там передрана с оракла, а у того undo only, если я правильно помню.
ANS>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно.
Это тебе не нужно, а вообще только оно и нужно.
ANS> Пользователь утрётся и введёт данные заново.
Не прокатит. В нагруженных системах, на основе его утерянных данных уже будут другие данные, которые сохранятся — и привет, база в несогласованном состоянии. Кто и когда это ловить будет?
Ты забываешь, что на один пользовательский ввод в реальных системах приходится 3-5 служебных транзакций и что без логов и прочих средств обеспечения durability и consistency нет никакой гарантии, что до диска они доползут ровно в том порядке в котором происходили. То есть никакой гарантии согласованности данных не может быть в принципе.
Если у тебя переупорядочились запросы чтения и записи, то очевидно, что можешь прочитать не то что записал. Собственно на примере с FTS я это демонстрировал. Но ты сказал, не читай оттуда и будет счастье
Здравствуйте, gandjustas, Вы писали:
G>>>Ты путаешь durability и восстановление после критического сбоя.
ANS>>В определении "durability" нет разделения на критический и не критический сбой. G>Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь. G>Критический сбой это как раз такой который повреждает физическое хранилище. G>Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.
Наконец-то. Я имеено это и имею ввиду. А что на счет:
Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software).
Здравствуйте, IB, Вы писали:
IB>Да, известны базы без логов (FB, кажется такая), но за это призодится платить долгим коммитом, откатом, временем восстановления.
блин, а я что говорил? Без лога можно жить (это не /единственно возможный/ способ обеспечения durability). Просто с логом быстрее. Пока что.
IB>Как устроен постгри не знаю, но большая часть там передрана с оракла, а у того undo only, если я правильно помню.
Я конечно не большой знаток. Но помню, что изначально postgre был исследовательским проектом и в нём данные не удалялись физически вообще (кроме как явной операцией VACUUM). Это давало возможность вычитывать старые данные (спецсинтаксис у запросов) и не делать никаких журналов. Если мне память не изменяет, то write-ahead-log появился в 6 версии и изначально его не было. В любом случае, сдирание делалось на "внешнем" интерфейсном уровне. Внутреннее устройство, я уверен, там самобытно.
ANS>>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. IB>Это тебе не нужно, а вообще только оно и нужно.
Ну, я конечно утрирую, однако возникает вопрос, если только оно и нужно, то почему за него не готовы платить широкие массы?
ANS>> Пользователь утрётся и введёт данные заново. IB>Не прокатит. В нагруженных системах, на основе его утерянных данных уже будут другие данные, которые сохранятся — и привет, база в несогласованном состоянии. Кто и когда это ловить будет?
Хе-хе. Так по треду постоянно апеллируют к тому, что нагруженые системы удел не многих, а у многих всё мол попроще. И им durability тоже нужно. Но как раз эти "многие" платить за обеспечение "D" не готовы. Парадокс?
Здравствуйте, gandjustas, Вы писали:
G>>>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
ANS>>Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.
G>Еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Странно, я вроде ясно написал, что если у тебя XML — данные, то добраться до них можно только через XPath. Даже если перед XPath ты напишешь слово SELECT это не превратит XPath в SQL. Но дам еще один намёк: реляционная теория рассматривает только отношения находящиеся как минимум в 1-й нормальной форме.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Ты путаешь durability и восстановление после критического сбоя.
ANS>>>В определении "durability" нет разделения на критический и не критический сбой. G>>Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь. G>>Критический сбой это как раз такой который повреждает физическое хранилище. G>>Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.
ANS>Наконец-то. Я имеено это и имею ввиду. А что на счет: ANS>
Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software).
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
ANS>>>Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.
G>>Еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
ANS>Странно, я вроде ясно написал, что если у тебя XML — данные, то добраться до них можно только через XPath. Даже если перед XPath ты напишешь слово SELECT это не превратит XPath в SQL. Но дам еще один намёк: реляционная теория рассматривает только отношения находящиеся как минимум в 1-й нормальной форме.
SQL != реляционная алгебра.
И еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
ANS>>>Это уже "Рабонович" поёт. Первоисточник тут http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf . Там упор на линейный порядок между запросами. Что для меня вполне логично — мне нравится, когда я могу прочитать то, что записал. В отличии от G>>А при нелинейном порядке ты не сможешь прочитать что записал? Как оно вообще связано?
ANS>Если у тебя переупорядочились запросы чтения и записи, то очевидно, что можешь прочитать не то что записал. Собственно на примере с FTS я это демонстрировал. Но ты сказал, не читай оттуда и будет счастье
Именно. Полнотекстовый поиск — далеко не основной инструмент работы с данными в реляционных СУБД. Можешь статистику посчитать: соотношение поисковых запросов к обычным select. Полученные доли процента умножь на вероятность того что надо будет с помощью FTS найти данные, которые только что были записаны.
Полученное число будет гораздо меньше вероятности аппаратного сбоя.
Здравствуйте, gandjustas, Вы писали:
ANS>>Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности. G>Конкретнее.
Самая большая проблема — DDL. Любое применение DDL это даунтайм. Именно отсюда растут ноги у всяких sсhema-less способностей. Т.е. хранение именно неструктурированных данных мало кому нужно, а вот возможность менять схему без трёхдневного даунтайма пригодилось бы многим.
Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц.
Из-за этой способности залочить на неопределённое время всю систему и неопределённости поведения при наличии сотен тысяч таблиц с тысячами колонок, людям вместо того, чтобы выполнить "CREATE TABLE/ALTER TABLE" приходится городить огород типа как у FriendFeed. Похожую схему применяет SalesForce. Только они вместо, хранения всего "документа" в одном блобе имеют таблицу на 500 строковых колонок для хранения данных. А для "индексов" создают таблицы как и FriendFeed, только SF пишет в них синхронно, а FF асинхронно. Сумрачный отечественный гений всё пытается породить какую-то ерунду из одной таблицы на каждый тип данных плюс вагон джойнов для построения отношения. Почему я не могу использовать для хранения отношений РБД, особенно если за неё уплочено? Вопрос риторический.
Что интересно, что метапрограммирование хотя и пролезло в майнстрим в последние 10лет, до этого активно использовалось и теоретиками и немайнстримовыми практиками. А создать таблицу в ран-тайм — почему считается зазорным. Если бы не легковесные pure java RBD (a-la "H2") вообще просвета бы не было.
Всё остальное уже обсосано: ACID требует слишком многого. Если c Isolation сразу просекли, что если её обеспечить, то пользователей у такой БД будет не много. И сразу сказали, что изоляция есть хорошо, но есть и уровни изоляции, а об остальном позаботьтесь сами. А с Durability получилось интереснее. Из формулировки "данные должны остаться не зависимо от сбоев нижележащих систем" появилась формулировка "данные должны остаться независимо от сбоев вышележащих систем". В результате если кому нужно то первое — настоящее — durability, у того большие проблемы.
Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу. Я тут намедни термин интересный узнал: "непредвиденная консистентность". Вот такие системы обычно консистентны по недоразумению. Если бы был сверху стандартный слой дающий гарантированные гарантии, то всем бы стало только лучше. Хороший пример — FlockDB с MySql и ACID внизу.
Здравствуйте, gandjustas, Вы писали:
ANS>>>>В определении "durability" нет разделения на критический и не критический сбой. G>>>Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь. G>>>Критический сбой это как раз такой который повреждает физическое хранилище. G>>>Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.
ANS>>Наконец-то. Я имеено это и имею ввиду. А что на счет: ANS>>
Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software).
А вся веселуха начинается, когда пользователь узнаёт, что у него бек-ап месячной давности и тот не поднимается. Durability это вам не хухры-мухры. 
Мы уже победили, просто это еще не так заметно...
Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности.