Можно ли хранить графики hbase? если да, то как вы моделируете базу данных для поддержки структуры графа?

Я играл с использованием графиков для анализа больших данных. Он работал отлично и действительно весело, но мне интересно, что делать, когда данные становятся все больше и больше?

Дайте мне знать, если есть какое-то другое решение, но я подумал о том, чтобы попробовать Hbase, потому что он масштабируется горизонтально, и я могу заставить Hadoop запускать аналитику на графике (большая часть моего кода уже написана на Java), но я не уверен, как структурировать график в базе данных nosql? Я знаю, что каждый узел может быть записью в базе данных, но я не уверен, как моделировать ребра и добавлять к ним свойства (например, имя узлов, атрибуты, pagerank, веса на ребрах и т. Д.).

Видя, как hbase / hadoop моделируется после больших таблиц и уменьшения карты, я подозреваю, что есть способ сделать это, но не уверен, как это сделать. Какие-либо предложения?

Кроме того, имеет ли это смысл то, что я пытаюсь сделать? или есть ли лучшие решения для больших графов данных?

 Arun A K14 мар. 2014 г., 09:25
Кстати, вы можете хранить графики в Hbase. Но это не лучшее решение для обработки связанных данных. Обход будет проблематичным. Вам нужно будет использовать фильтры для поиска по значениям (значениям свойств), если в качестве ключа строки используется nodeid (src node). Лучше было бы использовать доступные базы данных графиков, которые поддерживают BigData. Это всего лишь предложение, а не ответ, поэтому я добавляю это через блок комментариев.

Ответы на вопрос(4)

Binary Nerd"поскольку HBase не очень хорошо работает при обработке нескольких семейств столбцов.

Наилучшая производительность достигается с одним семейством столбцов (второй следует использовать только в том случае, если вы очень часто получаете доступ только к содержимому одного семейства столбцов, а данные, хранящиеся в другом семействе столбцов, очень велики)

 gextra03 мар. 2014 г., 14:19
вам не нужно использовать несколько семейств столбцов. Один будет достаточно. Второй, специализирующийся на Edges, все равно будет работать правильно. Рекомендация до двух. Тем не менее, вы можете хранить ребра в выделенном столбце в одном семействе столбцов.

так что, например, каждый raw будет иметь столбцы для общих свойств (name, pagerank и т. Д.) И список ключей смежных узлов (если это ориентированный граф, а не только те узлы, которые вы можете получить) от этого узла или дополнительного столбца с указанием каждого)

Взгляни наApache Giraph (Вы можете также прочитать немного больше об этомВот) хотя речь идет не о HBase, а об обработке графиков в Hadoop. Также вы можете захотеть взглянуть на Hadoop 0.23 (и выше), так как движок YARN (он же map / redu2) более открыт для алгоритмов, не связанных с картой / Reduce.

построенные на основе HBase, которые вы можете попробовать и / или изучить.

Apache S2Graph предоставляет REST API для хранения, запроса данных графа, представленных ребром и вершинами. Там вы можете найти презентацию, в которой объясняется конструкция ключей строк / столбцов. Анализ производительности операций, которые влияли или влияют на дизайн, также приведены.

Титан может использовать другие бэкэнды хранилища помимо HBase и имеет интеграцию с аналитическими средами. Он также разработан с учетом больших объемов данных.

Решение Вопроса

Я более знаком с Accumulo (терминология HBase может немного отличаться), поэтому вы можете использовать схему, подобную следующей:

SrcNode(RowKey) EdgeType(CF):DestNode(CFQ) Edge/Node Properties(Value)

Где CF = ColumnFamily и CFQ = ColumnFamilyQualifier

Вы также можете хранить свойства узлов / вершин в виде отдельных строк, используя что-то вроде:

Node(RowKey) PropertyType(CF):PropertyValue(CFQ) PropertyValue(Value)

PropertyValue может быть либо в CFQ, либо в Value

С точки зрения обработки графиков, как упомянуто @Arnon Rotem-Gal-Oz, вы можете посмотреть наApache Giraph который является реализацией Google Pregel. Pregel - это метод, который Google использует для обработки больших графов.

Использование HBase / Accumulo в качестве входных данных для giraph было отправлено недавно (7 марта 2012 г.) как запрос новой функции к Giraph:HBase / Accumulo форматы ввода и вывода (GIRAPH-153)

Ваш ответ на вопрос