NoSQL / гибрид RDBMS со ссылочной целостностью (удаляют каскад)?

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

Есть один тип базы данных NoSQL, который поддерживает отношения. Фактически, он разработан специально для отношений: база данных графов . Базы данных графов хранят узлы и явные отношения (ребра) между этими узлами. И узлы, и ребра могут содержать данные в виде пар ключ / значение без привязки к предопределенной схеме.

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

Другой вариант - сделать весь уровень данных гибридным, используя СУБД для хранения отношений и базу данных документов для хранения фактических данных. Это немного усложнит ваше приложение, но я не думаю, что это такое уж плохое решение. Вы будете использовать две разные технологии, обе решают проблемы, для решения которых они были созданы.

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

Есть язык Gremlin , поддерживаемый базой данных графов Neo4j . Что касается вашего примера, посмотрите Контроль доступа перечисляет путь к базе данных графа и здесь . Также существует веб-инструмент, включающий REST API для Neo4j и консоль Gremlin, см. neo4j / webadmin .

Учитывая требования, которые вы указываете в своем вопросе, база данных графов, вероятно, является тем, что вы ищете, но есть и другие варианты. Как сказал @Niels van der Rest, два ограничения «отсутствие априорной схемы» и «ссылочная целостность» очень трудно согласовать. Возможно, вы сможете найти базу данных на основе тематической карты, которая могла бы это сделать, но я не знаком с конкретными реализациями, поэтому не могу сказать наверняка.

Если вы решите, что действительно не можете обойтись без ссылочной целостности, я боюсь, что вы, вероятно, застряли в РСУБД.Есть несколько приемов, которые вы можете использовать, чтобы избежать некоторых из ожидаемых вами проблем. Я расскажу о паре в https: //stackoverflow.com/questions/3395606 ... , которые могут дать вам некоторые идеи. Тем не менее, для такого рода модели данных, требующей динамической пост-априорной схемы с элементами метасхемы, СУБД всегда будет неудобной.

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

1. Map / Reduce - двух видов: распределенный, ориентированный на записи (think, MongoDB), и ориентированный на столбцы (think, Cassandra). Масштабируется очень хорошо, но у вас не будет синтаксиса, подобного SQL; присоединяется отстой; и соответствие вашей архитектуры конкретным типам запросов имеет решающее значение. В вашем случае вы сосредотачиваетесь на сущностях и их атрибутах, а не на отношениях между самими сущностями, поэтому я бы, вероятно, рассмотрел распределенное хранилище, ориентированное на записи; но только если я ожидал, что мне нужно будет масштабироваться за пределы одного узла - они действительно очень хорошо масштабируются.

2. Хранилище документов - технически бывает двух видов, но один из них представляет собой распределенное хранилище данных сопоставления / сокращения, ориентированное на записи, о котором говорилось выше. Другой - перевернутый индекс (думаю, Lucene / Solr). НЕ игнорируйте силу инвертированного индекса; они могут удивительно быстро разрешать непомерно сложные предикаты записи. Что они не могут сделать, так это хорошо обработать запросы, которые включают корреляцию или большие реляционные соединения. Тем не менее, вы будете поражены невероятной гибкостью, которую дают вам достаточно сложные предикаты записи.

3. Graph-store - бывает несколько разновидностей. Первый - это крупномасштабное специализированное хранилище ключей и значений (думаю, DBM / TokyoTyrant); второй - пространство кортежей (думаю, Neo4j); третья - это база данных RDF (думаю, Sesame / Mulgara). У меня слабость к RDF, поскольку я помогал в разработке Mulgara, поэтому я не самый объективный комментатор. Тем не менее, если ваши ограничения масштабируемости позволяют вам использовать RDF-хранилище, я считаю бесценным вывод, разрешенный денотационной семантикой RDF (что редко среди опций хранилища данных noSQL).

Некоторые решения NoSQL поддерживают безопасность и SQL. Один из них - OrientDB. Система безопасности (довольно) хорошо объяснена здесь .

Кроме того, поддерживает SQL.