Проектирование нереляционных баз данных [закрыто]

Мне интересно услышать о стратегиях проектирования, которые вы использовали с нереляционные базы данных "nosql" - то есть (в основном новый) класс хранилищ данных, которые не используют традиционный реляционный дизайн или SQL (например, Hypertable, CouchDB, SimpleDB, Google App Engine datastore, Voldemort, Cassandra, SQL Data Services и т. д.). Их также часто называют "хранилищами ключей / значений", и на базе они действуют как гигантский распределенный постоянный хэш таблицы.

в частности, я хочу узнать о различиях в концептуальный дизайн данных С этими новыми базами данных. Что проще, что сложнее, что вообще нельзя сделать?

• вы придумали альтернативные проекты, которые работают намного лучше в нереляционных мира?




• вы ударились головой о что-нибудь, что кажется невозможным?




• вы преодолели разрыв с любым дизайном шаблоны, например, для перевода с одного на другой?




• вы даже делаете явные модели данных вообще сейчас (например, в UML) или вы отбросили их полностью в пользу полуструктурированных / ориентированных на документ данных blobs?




• вы пропускаете какие-либо основные дополнительные услуги, которые предоставляют РСУБД, такие как реляционная целостность, произвольно сложная поддержка транзакций, триггеры и т. д.?

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

к вашему сведению, здесь были обсуждения StackOverflow по аналогичным темам:

• следующее поколение баз данных


• изменение схем для работы с Google App Engine


• выбор документа, ориентированного база данных