схема хранилища данных без схемы - PullRequest
Новая
       9

схема хранилища данных без схемы

2 голосов
/ 01 марта 2011

Я ищу способы реализовать дизайн хранилища данных без схемы. Однако обычно термин «без схемы» используется в контексте школы NoSQL. Меня не интересует преимущество масштабируемости NoSQL. Одним из примеров является способ дружественной подачи (как объясняется в блоге Брета Тейлора). Можете ли вы указать мне какие-то другие ресурсы или примеры проектирования / тематические исследования, где основной целью является создание гибкого / не требующего схемы проекта (я даже согласен с тем, чтобы жертвовать производительностью для этого)?

Ответы [ 2 ]

2 голосов
/ 02 марта 2011

Я не на 100% уверен в вашем случае использования. Не могли бы вы поделиться какой-нибудь дополнительной информацией о том, что вы пытаетесь сделать? Когда вы говорите, что вас не интересует «NoSQL», означает ли это, что вы должны реализовать все поверх реляционной базы данных? (Какой?)

Существует несколько способов сделать реляционные схемы более гибкими:

  • Проекты EAV / Entity-Attribute-Value, в которых одна таблица хранит общую информацию обо всех «сущностях» / объектах в системе, одна таблица содержит информацию об атрибутах, которые могут иметь эти сущности, и одна таблица, в которой хранится (entity_id , attribute_id, значение). См. Например, http://en.wikipedia.org/wiki/Entity-attribute-value_model.

  • «тощие таблицы», где у вас есть широкие таблицы с одним столбцом на тип столбца (один столбец varchar, один столбец BLOB-объектов, один столбец типа int и т. Д.), А затем заполняются только те столбцы, которые соответствуют типу значения, которое вы хочу хранить. Это имеет смысл, когда вы хотите хранить только различные типы значений, а не изменять свои атрибуты на лету. Может использоваться для хранения атрибутов в схеме EAV.

  • Хранение «тройных» данных: сотрудники семантической паутины потратили довольно много времени на изучение того, как лучше всего хранить данные RDF, состоящие из троек объект-отношения-объект. Существуют «настоящие» хранилища RDF с собственным языком запросов, но некоторые из них могут использовать реляционную БД в качестве бэкэнда хранилища. Если это похоже на путь, посмотрите здесь: http://www.w3.org/2003/01/21-RDF-RDB-access/ - простой запрос Google для «хранения rdf в реляционной базе данных» должен указать вам на несколько Triplestore реализаций, которые эффективно отображают в реляционные БД.

Надеюсь, это поможет!

1 голос
/ 09 марта 2011

Возможно, вы захотите взглянуть на Berkeley DB .Он предоставляет простой в использовании API-интерфейс для определения значения ключа (а-ля NoSQL) и представляет собой библиотеку, которая напрямую связана с вашим приложением.Приятной особенностью Berkeley DB является то, что вы можете съесть свой торт и съесть его тоже.Он обеспечивает простое, гибкое, встраиваемое хранилище данных, которое ищут разработчики, но также очень быстрое, масштабируемое и надежное.

В дополнение к API пары ключ / значение Berkeley DB предлагает два других API-интерфейса, дружественных к разработчику: API коллекций Java и API Direct Persistence Layer (POJO-подобный персистентный API).

Большинство разработчиков приложений BDB используют API, который наиболее естественно соответствует тому, как приложение представляет данные.Структуры C и C ++ обычно хранятся в виде простых непрозрачных пар ключ / значение, в то время как коллекции Java, очевидно, хорошо согласуются с этим API, а классы Java хорошо согласуются с API DPL.

Удачи в поиске.

...