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

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

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

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

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

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

Где CF = ColumnFamily и CFQ = ColumnFamilyQualifier

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

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

С точки зрения обработки графиков, как упомянуто @Arnon Rotem-Gal-Oz, вы можете посмотреть на[Apache Giraph](https://incubator.apache.org/giraph/) который является реализацией Google Pregel. Pregel - это метод, который Google использует для обработки больших графов.

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



Binary Nerd"[поскольку HBase не очень хорошо работает при обработке нескольких семейств столбцов](https://hbase.apache.org/book/number.of.cfs.html).

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



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

Взгляни на[Apache Giraph](https://incubator.apache.org/giraph/) (Вы можете также прочитать немного больше об этом[Вот](https://engineering.linkedin.com/open-source/apache-giraph-framework-large-scale-graph-processing-hadoop-reaches-01-milestone)) хотя речь идет не о HBase, а об обработке графиков в Hadoop. Также вы можете захотеть взглянуть на Hadoop 0.23 (и выше), так как движок YARN (он же map / redu2) более открыт для алгоритмов, не связанных с картой / Reduce.



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

[Apache S2Graph](https://s2graph.incubator.apache.org/) предоставляет REST API для хранения, запроса данных графа, представленных ребром и вершинами. Там вы можете найти презентацию, в которой объясняется конструкция ключей строк / столбцов. Анализ производительности операций, которые влияли или влияют на дизайн, также приведены.

[Титан](http://titan.thinkaurelius.com/) может использовать другие бэкэнды хранилища помимо HBase и имеет интеграцию с аналитическими средами. Он также разработан с учетом больших объемов данных.