Я пишу приложение ruby, которое хранит данные типа предка. То есть Семейное дерево.Предложение для типа предков База данных: MongoDB, Redis и т. Д.?
Для остальной части приложения я использую MongoDB для хранения, поскольку он поддается иерархической структуре, однако данные о предках не совсем подходят для этой модели, хотя в некотором смысле она иерархична. Мне любопытно, есть ли у кого-нибудь предложение о том, следует ли мне заменять более подходящий уровень базы данных для их обработки?
I.e. A сопряжен с B (двунаправленный) и имеет родителей C и D. B имеет родителей E и F. A и B имеют детей G, H, I. G сопряжен с H и так далее.
Так что это не совсем рекурсивно, поскольку один узел имеет 2 родительских узла. Поэтому в MongoDB вложение не имеет смысла, поскольку оба родителя будут вставлять одно и то же дерево в дубликат. Это ближе к социальному графу только более жесткому (есть только два типа отношений). Я думаю, что наборы Redis будут работать очень хорошо, но прежде чем я углубится в стек с настойчивостью Полиглота, я надеялся, что смогу получить отзывы от других, которые, возможно, разработали аналогичные структуры. Другое беспокойство, которое я испытываю с Redis, заключается в хранении всех этих деревьев в памяти, возможно, не является отличной идеей, хотя, если бы я только сохранял отношения в Redis с данными объекта в документах MongoDB, это, вероятно, было бы в порядке.
Я играл с neo4j, и это действительно кажется очень гладким. Однако не огромный поклонник их лицензирования. Thing является документом databse, таким как mongodb, идеально подходит для остальной части моего приложения, поэтому я либо буду использовать mongodb для всего, либо я буду смешивать в другом решении только для данных родословной. будет ли база графиков давать мне какие-либо преимущества перед наборами redis? Кажется, что график db будет излишним. –
Невозможно сказать, слишком ли велико, если нет контекста того, что делает ваше приложение. При использовании нереляционной базы данных есть две вещи, которые вам необходимо рассмотреть заранее: как вы храните данные и как вы обращаетесь к ней. Вторая часть отсутствует в вашем описании, поэтому ответить невозможно. Вам нужно будет ориентироваться в отношениях глубже 1 уровня (это то, что вы можете получить с Redis или Twitter FlockDB)? В более общем плане, чем больше вам нужно ориентироваться в отношениях, но и обнаруживать его аспекты, тем больше имеет смысл график db. – alexpopescu
Ну, я довольно много разбираюсь в этой теме со времени публикации. По сути, я имею дело с DAG (Directed Acyclic Graph). Neo4j (и, возможно, другие графические DB) определенно кажутся наиболее подходящими для перемещения узлов. Пользователи смогут добавлять узел (отец, если он не существует, мать, если он не существует, и несколько детей) для любого данного узла, и система визуализирует график до определенной глубины, давайте скажем, радиус 3 в любом направлении от сфокусированного узла. Таким образом, я прохожу до 3 узлов. Определенно начинает звучать как проблема с db графика. –