WarstonedexsuЧто именно понять? Не думаю, что будут отличия от в sql ориентированных и nosql докуменооборотах. Ну кроме работы с ДБ :)Подход - да, будет одинаковым. А вот реализация хранения на noSQL будет оч-чень интересна... Как они хранят данные, если нет транзакций? Как они их обновляют? Откатывают и т.д.
Считайте, что ACID есть, но autocommit отключить нельзя.

Warstone,

я бы вам посоветовал прежде всего прочитать http://habrahabr.ru/blogs/nosql/77909/ и http://habrahabr.ru/blogs/nosql/102564/ , выбрать для себя подходящие названия после такого поверхностного знакомства и дальше читать про них. Я пока сам присматриваюсь, практического опыта на своей инфраструктуре еще нет, поэтому посоветовать что-то более конкретное не смогу.

По теории доходчивыми словами что сам знаю про nosql объяснить смогу, если хотите - задавайте вопросы.

WarstoneДа и вообще... Плюсы и минусы именно подходов, а не конкретных СУБД?
Насколько я понимаю,
- key-value - это всегда ключ и значение,
- документо-ориентированные - это ключ, поле (фактически, составной ключ) и значение с некими ухищрениями для улучшения производительности; т. е. полностью schema less хранилище.
Вторыми я особо не интересовался, как-то сразу зацепили column-oriented, поэтому сказать уверенно и подробнее не могу. :)

privateMongoDB - очень классная штуковина, я попробовал для своего небольшого проекта, эти сайты на ней сделаны (хотя еще не завершены) bos-tec.com, bom4.com, robotigra.ru.

Транзакций в NoSQL в общем случае скорей всего воообще не будет, потому что
- их реализация в распределенной системе очень сложна
- уменьшает производительность
- для некоторых архитектур реализовать невозможно в принципе (CAP theorem)

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

Что можно сделать в тех 5% случаев когда без нее никак - реализовывать самому в коде, используя какой-то сторонний сервис-менеджер транзакций или использовать вместе с транзакционной базой.
Когда вы говорите об отсутствии транзакций, не забывайте, что люди могут вас неправильно понять. Транзакция прежде всего - это объем работ, переводящий БД из одного валидного инварианта в другой. И в этом смысле во всех (даже memcache) nosql решениях транзакции есть.

Другое дело, что поддержки объема работ из двух и более действий действительно в части nosql СУБД нет вообще (но CAP theorem тут не при чем, просто реализация или сложна или весомо ухудшит производительность), а в части такая поддержка дана взамен на availability (CAP theorem), но не отсутствует совсем.

private,

two phase commitом.

Я имел в виду, что все nosql решения можно поделить на два вида:
1. те которые не поддерживают объем работ > 1 действия by design, например в memcache это просто не нужно; если туда начнут навешивать сложную логику типа того же two phase commitа, memcache уже будет предназначаться для других вещей, нежели очень быстрое кэширование;
2. те, в которые эту поддержку реально вставить, но придется или временно (на одну транзакцию) или постоянно жертвовать availability или partition tolerance - тут уже в полный рост CAP.

privateавторно CAP theorem тут не при чем разве? :) а как можно в принципе реализовать транзакцию на любой eventially consistent базе, например на CouchDB?
Наверное я плохо выразился. CAP theorem, конечно, причем, но даже если бы её бы не было - очевидно, что дополнительный функционал давал бы ухудшение производительности (это и без CAP theorem понятно), а некоторым СУБД это просто не нужно (пример привел выше - memcache).