MongoDB 1.6.0

Значит блокировка все-же есть

Нету там блокировки. Попытка записать документ с не той версией сразу дает исключение. И клиент должен сам разрулить конфликт.

> Но даже в не зависимости от ответов на эти вопросы, я могу сказать, что версионность документов позволяет забить на транзакции в большинстве случаев.

Я так понимаю спор чисто терминологический, так как я считаю версионность одним из способов реализации транзакций.

Ты утверждаешь, что

Скачать, обновить, записать обратно - а за это время второй поток обновил адрес... Вот и рэйс

Я так не утверждаю. Я утверждаю, что если еcть два процесса, которые конкурируют за общий ресурс в данном случае за доступ к объекту JSON, то блокировка на изменение JSON объекта неизбежна в том или ином виде. Даже в мультиверсионной БД имеется блокировка на время включения свежей версии. Если есть блокировка и есть поддержка транзакций, возможен deadlock.

> Даже в мультиверсионной БД имеется блокировка на время включения свежей версии. Если есть блокировка и есть поддержка транзакций, возможен deadlock.

В данном случае дедлока быть не может, потому что блокирующий код не лезет ни в какие больше ресурсы, то есть не может возникнуть цикл локов. Ну если реализовано все правильно конечно.

Действительно вопрос терминологический.
Можно конечно и не считать заблокированной запись, которую нельзя изменить до тех пор, пока она не будет разблокирована другим процессом. Так?

Практика говорит об обратном. Таких БД пока-что не встречал.

Не БД, а СУБД конечно

> Действительно вопрос терминологический. Можно конечно и не считать заблокированной запись, которую нельзя изменить до тех пор, пока она не будет разблокирована другим процессом. Так?

Ну мы ведь не о таких локах говорили, да и вообще непонятно как там все в глубине реализовано, может там один вызов compare-and-swap стоит, для смены указателя на новый документ?

>А как он это делает не расскажете?

MVCC

Ну мы ведь не о таких локах говорили

Такие локи в сложном приложении способны привести к deadlock.
Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно. Транзакций пока нет, разграничения прав доступа тоже нет. Ссылочной целостности нет.
Как элементарно перевести средства с одного счёта на другой без транзакций?

http://ru.wikipedia.org/wiki/MVCC
В какой из перечисленных там СУБД проблема deadlock отсутствует как класс?

> Такие локи в сложном приложении способны привести к deadlock.

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

Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

Смешалось все в кучу, понятие SQL/NoSQL ортогонально транзакциям..

А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно. Транзакций пока нет, разграничения прав доступа тоже нет. Ссылочной целостности нет.

Как элементарно перевести средства с одного счёта на другой без транзакций?

В berkeleydb например есть транзакции.

>В какой из перечисленных там СУБД проблема deadlock отсутствует как класс?

couchdb, угадал?

http://books.couchdb.org/relax/intro/eventual-consistency#No Locking

> Такие локи не могут привести к дедлокам, почему я обьяснил выше. В каких СУБД c поддержкой транзакций принципиально отсутствуют дедлоки? Клиентсткие приложения работающие с такими СУБД не будут подвержены дедлокам?

Смешалось все в кучу, понятие SQL/NoSQL ортогонально транзакциям..

Действительно транзакции можно реализовать и в NoSQL СУБД. И таковые реализованы.

В couchdb целостность базы данных обеспечивается исключительно на уровне отдельных записей (но не на уровне связей между ними);
Нет транзакций

> лиентсткие приложения работающие с такими СУБД не будут подвержены дедлокам?

Сколько раз мне еще повторить слово «нет»? ;-)

Сколько раз мне еще повторить слово «нет»? ;-)

Не верю! Дайте мне примеров! :-) Дайте хотя-бы ссылку.

MVCC реализовано в Firebird. Это первая СУБД c MVCC. Дедлок в ней возможен. В каких СУБД с поддержкой транзакций это не так?

>В couchdb целостность базы данных обеспечивается исключительно на уровне отдельных записей

Какой смысл ты вкладываешь в термин «запись» в контексте couchdb?

> MVCC реализовано в Firebird. Это первая СУБД c MVCC. Дедлок в ней возможен. В каких СУБД с поддержкой транзакций это не так?

Те ДБ о которых ты говоришь, они с write lock-ом. А в couchdb write lock-a к примеру нету.

В couchdb транзакций нет. Я утверждаю, что если в СУБД есть поддержка транзакций, то возможны дедлоки. Добавьте в couchdb транзакции и получите возможность дедлока.

Просвещаю. «запись» в контексте couchdb это JSON-подобный документ, моделью которого является дерево (ориентированный граф);

Ну и утверждайте, что я могу сделать ;-) Когда я модифицирую документ в CouchDB, какое условие ACID нарушается?

В одиной коллекции документов предметную область не выразишь.
(Как генеалогическое древо в документную СУБД уложить?)
Как только в рамках одной транзакции появляются взаимосвязанные документы возникают дедлоки.

Т.е. получаем возможность появления дедлоков.

>В couchdb целостность базы данных обеспечивается исключительно на уровне отдельных записей

«запись» в контексте couchdb это JSON-подобный документ, моделью которого является дерево (ориентированный граф);

В РСУБД целостность базы данных обеспечивается исключительно на уровне отдельных документов.

«документ» в контексте РСУБД это SQL-подобный текст, моделью которого является [неразборчиво]

//fixed

>> Оставил одну-единственную таблицу insert-only,

да, былинный опыт

В РСУБД целостность базы данных обеспечивается исключительно на уровне отдельных документов.

Неверно. Скорее целостность на уровне кортежей.

Большинство РСУБД поддерживает ссылочную целостность, транзации. Дают возможность проверять корректность вводимых данных на уровне строк таблиц.
Поддерживают хранимые процедуры.
Поддерживают разграничение доступа на уровне таблиц и столбцов таблиц.
Поддерживают механизмы репликации данных.
Инкрементное резервное копирование.

В реляционную модель можно перенести любую предметную область, но не в модель ирерархическую или документо-ориентированную (если конечно нет ссылочной целостности).

Добавтье в документо-ориентированную СУБД обеспечение ссылочной целостности, проверки вводимых данных, триггеры, транзакции, хранимые процедуры, разграничение прав доступа и получите полноценную СУБД.
Правда и производительность у неё будет на уровне РСУБД.

>да, былинный опыт

Ты что-то перепутал, там нет слова «резюме»

>Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

в одном предложении сразу две ветряные мельницы.

Кто сказал, что _только_ использование NO-SQL СУБД, решает проблему deadlock? Да nosql вообще в целях своих не решал именно эту проблему. Просто упростили схему работы, убрали бОльшую часть транзакций (основной источник дедлоков) и подняли производительность базы и поэтому большинство дедлоков ушло. Не более того.

и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

А преимущество как раз значительное, вероятность появления дедлоков снижена на порядки.

> убрали бОльшую часть транзакций
В Mongodb есть транзакции?
Их там нет. Есть атомарность отдельного объекта коллекции и все.

А преимущество как раз значительное, вероятность появления дедлоков снижена на порядки.

Отсутствие транзакций не тянет на преимущество, скорее наоборот. От дедлоков помогает грамотное проектирование структуры БД и логики обработки данных.

> Как только в рамках одной транзакции появляются взаимосвязанные документы возникают дедлоки.

ITT носкулисты не могут понять эту простую истину.

>А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно.

1) Утверждение за весь NO-SQL, а претензии к конкретной реализации. Это неверно.

Транзакций пока нет,

Транзакции на уровне БД не обязательны.

разграничения прав доступа тоже нет.

и как же это большинтво финансовых систем использует для всех один логин к базе?

Ссылочной целостности нет.

которую опять таки обычно отключают в пользу триггеров.

Как элементарно перевести средства с одного счёта на другой без транзакций?

Версиями, метками в объектах, через очередь заданий.

А, теперь понял, трехзвенки до вас так и недошли?

>> убрали бОльшую часть транзакций

В Mongodb есть транзакции?

Их там нет. Есть атомарность отдельного объекта коллекции и все.

Читать: «убрали бОльшую часть необходимости в транзакциях»

Отсутствие транзакций не тянет на преимущество, скорее наоборот.

отсутсвие необходимости в транзакциях тянет на преимущество.

От дедлоков помогает грамотное проектирование структуры БД и логики обработки данных.

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

> Да, именно репликации. Какие БД позволяют симметрично реплицироваться? Чтобы работа с каждой шла автономно и реплицировалась на другую?

MS SQL. подозреваю что орацл и дб2 тоже умеют.

и как же это большинтво финансовых систем использует для всех один логин к базе?

Идиоты админы?

Транзакции на уровне БД не обязательны.

Обязательны

которую опять таки обычно отключают в пользу триггеров.

Не понял. Ссылочную целотность надобно отключать? Ccылочная целостность реализуют триггерами? Но как её реализовать, (ссылочную целостность) если атомарна работа только с одним объектом коллекции?

Как элементарно перевести средства с одного счёта на другой без транзакций?

Версиями, метками в объектах, через очередь заданий. т.е. реализуем транзакции самостоятельно? Зачем, если эту возможность можно заложить в СУБД?

Итого: 1. транзакции необходимы в СУБД 2. пока в Mongodb их нет 3. когда они появятся скорость обновлений данных упадет

По-прежнему нет ссылочной целостности. Та зачем тогда NOSQL. Может лучше расширить реляционную модель и добавить возможность хранения индексированных документов в строках таблиц?

> не поверишь, но как только ты избавишься от дедлоков, то уйдет и необхожимость в транзакциях. не верю. второе не следует из первого.

А, теперь понял, трехзвенки до вас так и недошли?

трёхзвенка отменяет удобство использования транзакций без извращений с метками?

>> и как же это большинтво финансовых систем использует для всех один логин к базе?

Идиоты админы?

Скорее разработчики.

>MVCC в couchdb замечательно с этим справляется без локов.

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

>>Все бы хорошо, если бы не было так плохо: описанный пример (как и весь nosql) не позволяет делать атомарный update

не понял, мы в новости про монго или где?

http://www.mongodb.org/display/DOCS/Updating#Updating-update%28%29

update() replaces the document matching criteria entirely with objNew.

А атомарное обновление делается на стороне сервера, где он лочит весь объект, вычитывает его в буфер, обновляет и записывает обратно. Тот же read-modify-write, но только для одной копии, а что там с репликами? А что с репликами, если сервер с одной из копий был недоступен?

Распределенного атомарного апдейта там нет.

Анонимус доказал, что ему носиквел не нужен. Молодец.

Вообще это хорошо, когда у людей есть выбор. Вопрос в том, что новые технологии обычно появляются тогда, когда старые подводят. И носиквел тому не исключение.

>трёхзвенка отменяет удобство использования транзакций без извращений с метками?

удобство - нет, а смысла становится много меньше. Хотя трехзвенку я упомянул в первую очередь в связи с логином и уровнями доступа к БД.

>Как элементарно перевести средства с одного счёта на другой без транзакций?

Попробую:

{«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

вот, пожалуй, самое очевидное, что приходит в голову.

удобство - нет, а смысла становится много меньше.

Смысла намного больше когда функционал транзакций реализован на уровне СУБД

Хотя трехзвенку я упомянул в первую очередь в связи с логином и уровнями доступа к БД.

У вас в трехзвенке сервер приложений единственным незашифрованным паролем с СУБД коннектится?

{«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Где первый и второй номер счёта?

>Вопрос в том, что новые технологии обычно появляются тогда, когда старые подводят. И носиквел тому не исключение.

Ну, насчет «подводят», это все-таки lor_mode, а вот то, что всякие «ораклы» всовывают туда, где им не место — это да. Любой задристаный сайтик ведь должен быть непременно ЪНтырпрайез-SQL92, хранить картинки в файлах? фи, что за дикость и ниасиляция блобов?!

>> {«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Где первый и второй номер счёта?

что значит «первый и второй номер счёта»?

> что значит «первый и второй номер счёта»?

Номер счета, с которого деньги ушли, и номер счета, на который они пришли.

Еще интересно знать, что в данном случае является «документом» - счет или акт перевода денег?

>> {«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Где первый и второй номер счёта?

ок, специально для смущенных латиницей повторяю:

{«тип»:«проводка», «Дата»:«09.08.2010» «Дебет»:«50» «Кредит»:«51» «Сумма»:«100»}