Здравствуйте, 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 внизу.