Здравствуйте, gandjustas, Вы писали:
ANS>>Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL? G>Нет, в терминологический спор вступать не буду.
Хм. Странно о чем то спорить не дав дефиниции терминам.
G>Конкретнее.
Здравствуйте, adontz, Вы писали:
A>>>Примитивная, то есть упираемся в диски, а не в CPU. I>>Задачи вроде "коммивояжера", это примитивная обработка? A>Зависит от параметров.
На самом деле "коммивояжер" это сильно упрощенный пример. Реально алгоритмы много сложнее.
I>>Дискового пространства надо меньше. Процессорного времени — примерно столько же. Потому надо придумать, куда деть 600-кратную разницу в процессорном времени.
A>Зачем столько же процессорного времени для обработки меньшего количества данных?
Поменял пару параметров в модели, сколько байт изменилось ? Доли процента. А рассчет пойдет совершенно иначе.
A>>>Да нет, это ты рассказывал по 10000 рабочих станций на которых что-то параллельно считается, не я. Если тебе очевидно, то ветку закрываем за очевидностью. I>>"что-то параллельно считается" — где ты увидел такое ?
A>То есть они что, последовательно работают? Ну тогда заменяем одной рабочей станцией.
Инженеры работают каждый над своей задачей.
I>>Ты похоже придумал задачу, решил и на этой основе утверждаешь что реальные задачи будут решаться так же легко.
A>О да, вот ты лично видел 10000 активно что-то считающих компьютеров. Фотки не покажешь? Твой пример реальной задачей и не пахнет.
Я привел ажно два примера, из которых должно быть ясно что к чему.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести. G>>Бред. Как ты откатывать транзакцию будешь без лога?
ANS>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php ANS>Ты путаешь "UNDO log" и лог транзакций.
нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?
Как раз для postgresql этот undo log является оптимизацией, а transaction log является вполне стандартным средством обеспечения Атомарности и Долговечности транзакций.
G>>Ты неверно понимаешь слово Durability.
ANS>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно.
А если нет пользователя? Если это автоматическия система? Она то думает что все хорошо, а на деле все плохо.
ANS>>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично. G>>ACID вообще не коррелирует с CAP.
ANS>D в ACID == C в CAP.
Да ну? C в CAP — одинаковость данных на всех узлах.
Вообще CAP никоим образом не распространяется на один узел, а acid не говорит о множестве узлов.
Если че, даже сами разработчики СУБД говорят не делать распределенных транзакций.
ANS>Но не в этом дело. Дело в том, что с практической точки зрения люди всё равно заботятся о доступности.
Повторение не метод доказательства.
ANS>>>Или практика философов не интересует? G>>Практика это зачастую одна машина с БД, а CAP и мега-распределенные системы это теория.
ANS>Угу угу
. А потом ставят какой-нибудь memcached и работают с ним так: http://www.majordojo.com/2007/03/memcached-howto.php . То что всё иногда ломается — так сделаем круглые глаза, у нас же ACID и всё гарантировано. Почему ты запрещаешь сделать инструмент, который убережёт от таких ошибок?
Опять ты повторяшь недоказанные утверждения.
Для начала докажи что:
1)Durability не важен, даже если на одной машине хранилище работает.
2)Пользователей больше заботит Consistency между узлами. (хотя тут тебе контрпример
Практика показывает что надо иметь возможность выбирать между Consistency и Availability, большинтсво NoSQL хранилищ не дают такого выбора, а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL? G>>Нет, в терминологический спор вступать не буду.
ANS>Хм. Странно о чем то спорить не дав дефиниции терминам.
Я уже давал читай внимательнее.
NoSQL — хранилища, которые так себя позиционируют.
SQL — современные, как говорится mature, СУБД общего назначения.
Здравствуйте, gandjustas, Вы писали:
G>А причем тут NoSQL? Ты просто свел задачу к той, которую БД не умеет решать, и написал решение сам.
Собственно говоря, не я сводил задачу. Я старался изначально удержать все в рамках SQL. Требования поступали от руководства. Так что в итоге мне пришлось сказать: как на SQL это решить я не знаю. Но могу переписать все на C++. Мне сказали: пиши
G>Кстати полнотекстовый поиск не пробовал использовать?
Да, использовался sphinx. Вообще, проблема поиска стояла несколько месяцев. Было несколько попыток найти параллельные решение. В итоге победил C++.
Здравствуйте, gandjustas, Вы писали:
G>>>Бред. Как ты откатывать транзакцию будешь без лога? ANS>>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php ANS>>Ты путаешь "UNDO log" и лог транзакций. G>нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?
В Oracle есть, в MySql есть. Значит они видят какой-то смысл? Ты спросил как откатывать транзакции, я тебе показал — не нужно просто портить старые данные.
G>Как раз для postgresql этот undo log является оптимизацией, а transaction log является вполне стандартным средством обеспечения Атомарности и Долговечности транзакций.
Я не спорю с тем, что это стандартная техника. Просто это не единственная техника.
G>>>Ты неверно понимаешь слово Durability.
ANS>>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно. G>А если нет пользователя? Если это автоматическия система? Она то думает что все хорошо, а на деле все плохо.
Автоматическая система на единственном нерабочем компьютере думает, что всё хорошо? Или концепция поменялась и у нас уже не один компьютер?
ANS>>>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично. G>>>ACID вообще не коррелирует с CAP.
ANS>>D в ACID == C в CAP. G>Да ну?
Истинно глаголю.
G>C в CAP — одинаковость данных на всех узлах.
Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable".
G>Для начала докажи что: G>1)Durability не важен, даже если на одной машине хранилище работает.
Если никто не его не обеспечивает и все при этом довольны, то оно никому не нужно. Т.е. не важно.
G>Практика показывает что надо иметь возможность выбирать между Consistency и Availability,
Ну наконец-то ты признал, что ACID в пролёте.
G>большинтсво NoSQL хранилищ не дают такого выбора,
Большинство NoSql поддерживают либо ту или иную пару. А некоторые позволяют это поведение сконфигурировать.
G>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят?
Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего.
Здравствуйте, gandjustas, Вы писали:
ANS>>Хм. Странно о чем то спорить не дав дефиниции терминам. G>Я уже давал читай внимательнее. G>NoSQL — хранилища, которые так себя позиционируют. G>SQL — современные, как говорится mature, СУБД общего назначения.
Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Бред. Как ты откатывать транзакцию будешь без лога? ANS>>>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php ANS>>>Ты путаешь "UNDO log" и лог транзакций. G>>нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?
ANS>В Oracle есть, в MySql есть.
Доказательства?
ANS>Ты спросил как откатывать транзакции, я тебе показал — не нужно просто портить старые данные.
Снова бред говоришь. Если я поставлю Read Uncommited я увижу незакомиченные данные. Угадай почему я их увижу.
G>>Как раз для postgresql этот undo log является оптимизацией, а transaction log является вполне стандартным средством обеспечения Атомарности и Долговечности транзакций. ANS>Я не спорю с тем, что это стандартная техника.
Durability обеспечивается не логом транзакций...
Твои слова.
ANS>Просто это не единственная техника.
В СУБД эта техника называется "версионность" или SNAPSHOTS. Жопа в том что она не обеспечивает сериализуемости транзакций.
G>>>>Ты неверно понимаешь слово Durability.
ANS>>>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно. G>>А если нет пользователя? Если это автоматическия система? Она то думает что все хорошо, а на деле все плохо.
ANS>Автоматическая система на единственном нерабочем компьютере думает, что всё хорошо? Или концепция поменялась и у нас уже не один компьютер?
Причем тут "нерабочий компьютер"? Компьютер вполне рабочий. Но вот возникает ошибка записи на диск по не важно какой причине. Как приложение узнает что ошибка произошла? Ты предложишь перечитывать данные после каждой операции записи? Ты же понимаешь что это бредовая идея?
ANS>>>>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично. G>>>>ACID вообще не коррелирует с CAP.
ANS>>>D в ACID == C в CAP. G>>Да ну?
ANS>Истинно глаголю.
G>>C в CAP — одинаковость данных на всех узлах.
ANS>Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable".
Дай ссылку на сие откровение. Тут говорят что C в CAP это A в ACID. А википедия говорит что Consistency (all nodes see the same data at the same time).
Причем во втором определении явная дыра. Как только твое приложение (оно ведь тоже "узел") считало данные и не блокирует их то Consitency больше нет, а если блокируешь, то гарантированно Availability нет. Получается CAP-теорема редуцировалась до CA теоремы.
G>>Для начала докажи что: G>>1)Durability не важен, даже если на одной машине хранилище работает. ANS>Если никто не его не обеспечивает и все при этом довольны, то оно никому не нужно. Т.е. не важно.
Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем.
G>>Практика показывает что надо иметь возможность выбирать между Consistency и Availability, ANS>Ну наконец-то ты признал, что ACID в пролёте.
Еще раз, ACID не коррелирует с CAP. Свойства ACID по большей части независимы, а CAP — связанные.
Причем реально вырождается это в CA-tradeoff.
И как раз никто не старается выполнять Consistency.
G>>большинтсво NoSQL хранилищ не дают такого выбора, ANS>Большинство NoSql поддерживают либо ту или иную пару. А некоторые позволяют это поведение сконфигурировать.
Да нихрена они не поддерживают, только делают вид что поддерживают, причем настолько насколько понимают суть проблем (а на практике понимают плохо).
G>>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят? ANS>Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего.
Еще раз, если смотреть комплекс "приложение-субд", то всегда присутствует CA-tradeoff.
Кстати есть сомнение что понимание CAP у тебя правильное. То что понимание ACID у тебя неправильное я уже убедился.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Хм. Странно о чем то спорить не дав дефиниции терминам. G>>Я уже давал читай внимательнее. G>>NoSQL — хранилища, которые так себя позиционируют. G>>SQL — современные, как говорится mature, СУБД общего назначения.
ANS>Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально.
Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт.
Здравствуйте, gandjustas, Вы писали:
G>Кстати есть сомнение что понимание CAP у тебя правильное. То что понимание ACID у тебя неправильное я уже убедился.
Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
нашел прекрасное замечание: Consistency означает атомарность операций.
То есть суть теоремы сводится к тому что невозможно одновременно достигнуть:
1)атомарности (выполняется или полностью или не выполняется вообще)
2)доступности (всегда отвечает на запрос)
3)отказоустойчивости (нарушение работоспособности одного узла не приводит к нарушении работы системы и потере данных)
Атомарность имеется ввиду сразу на всех узлах, те для системы извне любая операция должна быть атомарной.
Берем такую штуку как SQL Azure. Известно что она Fault Tolerant и Available (это гарантирует Microsoft большим количеством девяток), наружу выставлен SQL интерфейс, который поддерживает ACID, а соотвественно атомарность изменений.
Все три свойства на месте, в чем прикол? Или CAP работает когда к любому узлу системы могут "снаружи" обратиться клиенты?
Здравствуйте, gandjustas, Вы писали:
G>>>нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?
ANS>>В Oracle есть, в MySql есть. G>Доказательства?
Откуда "Read Uncommited" в версионнике?
ANS>>Я не спорю с тем, что это стандартная техника. G>
G>Durability обеспечивается не логом транзакций...
G>Твои слова.
Ну да. В майнстриме это стандартная техника. Но ты утверждал, что по другому никак. Я тебе указал, что эта техника используется только потому, что она более экономна. Но это не единственный вариант. См., например, soft updates.
ANS>>Просто это не единственная техника. G>В СУБД эта техника называется "версионность" или SNAPSHOTS. Жопа в том что она не обеспечивает сериализуемости транзакций.
"версионность" к наличию или отсутствию лога никакого отношения не имеет.
G>Причем тут "нерабочий компьютер"? Компьютер вполне рабочий. Но вот возникает ошибка записи на диск по не важно какой причине. Как приложение узнает что ошибка произошла? Ты предложишь перечитывать данные после каждой операции записи? Ты же понимаешь что это бредовая идея?
С таким сценарием согласен. Если данные нельзя будет записать, то это отстой. Да, без минимум двух серверов и репликации или без синхронной записи (хоть через лог, хоть без) тут не обойтись.
ANS>>Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable". G>Дай ссылку на сие откровение.
Зачем ссылка, это ж логика.
G>Тут говорят что C в CAP это A в ACID.
Хм. Он ссылается на доказательство Gilbert and Lynch, а в этой работе написано:
Atomic or linearizable consistency ... there must exist a total order on all operations such that each operations looks like as if it were completed at a single instant.
Я не уверен, что это соответсвует A в ACID. Мне кажется, что гарантия прочитать записанное это "D". Более того, в ACID, вроде как, не оговаривается наличие линейного порядка между операциями с БД (и ты сказал, требования упорядоченности нет
). Хотя оно может неявно вытекать из какого-то требования. Я пока считаю, что это (неявно) вытекает из D. Но, х.з.
G>А википедия говорит что Consistency (all nodes see the same data at the same time). G>Причем во втором определении явная дыра. Как только твое приложение (оно ведь тоже "узел") считало данные и не блокирует их то Consitency больше нет, а если блокируешь, то гарантированно Availability нет. Получается CAP-теорема редуцировалась до CA теоремы.
Не получается. Просто ты плавно приходишь к пониманию того, почему ACID-транзакции не реализуют в таких системах.
G>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем.
Ну как знаешь. Если ты считаешь, что durability можно обеспечить сложив все яйца в одну корзину, то так и считай. Я вроде всё что мог, то и написал.
G>Причем реально вырождается это в CA-tradeoff.
Нет.
G>И как раз никто не старается выполнять Consistency.
Еще раз. Есть системы и CP и AP. Причем примеры есть даже в презентации Брюера.
G>>>большинтсво NoSQL хранилищ не дают такого выбора, ANS>>Большинство NoSql поддерживают либо ту или иную пару. А некоторые позволяют это поведение сконфигурировать. G>Да нихрена они не поддерживают, только делают вид что поддерживают, причем настолько насколько понимают суть проблем (а на практике понимают плохо).
— Дорогой, будь осторожнее. Там какой-то идиот по встречке едет.
— Один идиот? Да их тут тысячи.
G>>>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят? ANS>>Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего. G>Еще раз, если смотреть комплекс "приложение-субд", то всегда присутствует CA-tradeoff.
Таки прогрес. Осталось дождаться пока ты признаешь, что гораздо лучше, когда этот трейдоф управляется и гарантируется уже написанным и проверенным фрейворком, а не каждым отдельным программистом по своему разумению.
G>Кстати есть сомнение что понимание CAP у тебя правильное. То что понимание ACID у тебя неправильное я уже убедился.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>Ты спросил как откатывать транзакции, я тебе показал — не нужно просто портить старые данные. G>>Снова бред говоришь. Если я поставлю Read Uncommited я увижу незакомиченные данные. Угадай почему я их увижу. ANS>Откуда "Read Uncommited" в версионнике?
А причем тут версионники?
Я про все SQL СУБД, а не про конкретные. Механизмы у них всех похожи ибо плоды кучи исследований.
G>>Причем тут "нерабочий компьютер"? Компьютер вполне рабочий. Но вот возникает ошибка записи на диск по не важно какой причине. Как приложение узнает что ошибка произошла? Ты предложишь перечитывать данные после каждой операции записи? Ты же понимаешь что это бредовая идея?
ANS>С таким сценарием согласен. Если данные нельзя будет записать, то это отстой. Да, без минимум двух серверов и репликации или без синхронной записи (хоть через лог, хоть без) тут не обойтись.
Ну в этом собственно и проблема. Таким условиям соответствует подавляющее большинство того что сегодня разрабатывается.
ANS>>>Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable". G>>Дай ссылку на сие откровение. ANS>Зачем ссылка, это ж логика.
Логика — она у всех разная.
G>>Тут говорят что C в CAP это A в ACID.
ANS>Хм. Он ссылается на доказательство Gilbert and Lynch, а в этой работе написано: ANS>
Atomic or linearizable consistency ... there must exist a total order on all operations such that each operations looks like as if it were completed at a single instant.
ANS>Я не уверен, что это соответсвует A в ACID. Мне кажется, что гарантия прочитать записанное это "D". Более того, в ACID, вроде как, не оговаривается наличие линейного порядка между операциями с БД (и ты сказал, требования упорядоченности нет
). Хотя оно может неявно вытекать из какого-то требования. Я пока считаю, что это (неявно) вытекает из D. Но, х.з.
Да уж, такое определение вообще похоже на требование сериализуемости транзакций. Тогда нужны двуфазные блокировки.
G>>А википедия говорит что Consistency (all nodes see the same data at the same time). G>>Причем во втором определении явная дыра. Как только твое приложение (оно ведь тоже "узел") считало данные и не блокирует их то Consitency больше нет, а если блокируешь, то гарантированно Availability нет. Получается CAP-теорема редуцировалась до CA теоремы.
ANS>Не получается. Просто ты плавно приходишь к пониманию того, почему ACID-транзакции не реализуют в таких системах.
В каких? Если ты не заметил, то это верно для любой системы. Причем Partition Tolerance совершенно не к месту.
G>>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем. ANS>Ну как знаешь. Если ты считаешь, что durability можно обеспечить сложив все яйца в одну корзину, то так и считай. Я вроде всё что мог, то и написал.
Ты путаешь durability и восстановление после критического сбоя.
G>>Причем реально вырождается это в CA-tradeoff. ANS>Нет.
Ок, у тебя есть приложение, оно читает из базы на той же машине и дает пользователю редактировать данные. Как ты согласованость данных и доступность для других пользователей обеспечишь одновременно?
G>>И как раз никто не старается выполнять Consistency. ANS>Еще раз. Есть системы и CP и AP. Причем примеры есть даже в презентации Брюера.
Еще раз, C в CAP совершенно никак не относится к согласованности данных.
А вот как раз согласованность данных никому не нужна. Я на своей практики не встретился со случаем где мне нужна согласованность данных межу "узлами" приложение — субд между на протяжении нескольких запросов.
G>>>>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят? ANS>>>Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего. G>>Еще раз, если смотреть комплекс "приложение-субд", то всегда присутствует CA-tradeoff.
ANS>Таки прогрес. Осталось дождаться пока ты признаешь, что гораздо лучше, когда этот трейдоф управляется и гарантируется уже написанным и проверенным фрейворком, а не каждым отдельным программистом по своему разумению.
Он именно каждым программистом по-отдельности по своему разумению делается, потому что задачи разные. Где-то нужна доступность, а где-то согласованность данных. В первом случае будут пессимистичные блокировки, во втором — оптимистичные.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>1)Там не используются БД
A>Ыменно. А утверждалось, что половина SQL будет ВЕЗДЕ.
Ты слишком много понимаешь под словом NoSQL. Для очистки мозга предлагаю понимать это только как хранилища, позиционирующие себя таким образом.
G>Атомарность имеется ввиду сразу на всех узлах, те для системы извне любая операция должна быть атомарной.
Ввиду трудоёмкости в обеспечении такой задачи минимально необходимым требованием считается не строгая консистентность, а поддержка консистентности (линейной упорядоченности) запросов для писателя (т.е. тот кто записал должен свои изменения видеть сразу), а для остальных отложенно.
G>Берем такую штуку как SQL Azure. Известно что она Fault Tolerant и Available (это гарантирует Microsoft большим количеством девяток),
Большое колличество это: a “Monthly Availability” of 99.9% during a calendar month.
G>наружу выставлен SQL интерфейс, который поддерживает ACID, а соотвественно атомарность изменений.
G>Все три свойства на месте, в чем прикол?
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.
/.../
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.
/.../
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.
/.../
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.
/.../
Правда у них репликация в пределах одного дата-центра. У Амазона было ряд проблем с дата-центрами в этом году и всё закончилось появлением опции синхронной репликации в другой датацентр. Но что они думают о CAP-теореме я не знаю
G>Или CAP работает когда к любому узлу системы могут "снаружи" обратиться клиенты?
В роли клиента может рассматриваться не конечный пользователь/приложение, а лоад-балансер.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт.
S>Это стёб, я надеюсь?
Это правда жизни. Реальность, данная нам в ощущениях А вся веселуха начинается, когда пользователь узнаёт, что у него бек-ап месячной давности и тот не поднимается. Durability это вам не хухры-мухры.
В добавок, я наблюдал, как консистентное чтение-запись под нагрузкой в друг превращалось в неконсистентное. Ибо понадеялись на ACID, а про то, что приложение правильно готовить нужно — не подумали. А ошибки с консистентностью это такая штука, которая то есть, то нету. Уж лучше нечто с явно прописанными гарантиями и ограничениями, чем этот ваш "ACID".
ЗЫ Или ты думаешь, что 99.9% программистов за что-то несут ответсвенность?
Здравствуйте, gandjustas, Вы писали:
G>>>NoSQL — хранилища, которые так себя позиционируют. G>>>SQL — современные, как говорится mature, СУБД общего назначения. ANS>>Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально. G>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.
Особенно в наиболее известных/распространенных проектах
А вся веселуха начинается, когда пользователь узнаёт, что у него бек-ап месячной давности и тот не поднимается. Durability это вам не хухры-мухры. 