Какое программное обеспечение следует использовать для распределенного хранения и обработки графов?

Коротко о проблеме:

  1. Существует огромное количество входных данных в формате JSON. Например, сейчас он составляет около 1 ТБ, но он будет расти. Мне сказали, что у нас будет кластер.
  2. Мне нужно обработать эти данные, сделать из них график и сохранить в базе данных. Поэтому каждый раз, когда я получаю новый JSON, мне приходится просматривать весь граф в базе данных, чтобы завершить его.
  3. Позже у меня будет тонкий клиент в браузере, где я буду визуализировать некоторые части графика, искать в нем, проходить по нему, делать некоторую фильтрацию и т. д. Так что эта система не является высоконагруженной, просто много обработки и данных.

У меня нет опыта работы с распределенными системами, базами данных NoSQL и прочими подобными "большими данными". Во время своего небольшого исследования я обнаружил, что их слишком много, и сейчас я просто потерян.

Что у меня есть на доске на данный момент:

  1. GraphX ​​(GraphFrames) Apache Spark для распределенных вычислений поверх некоторого хранилища (HDFS, Cassanda, HBase,...) и процессора (Yarn, Mesos, Kubernetes,...).
  2. Некоторая графовая база данных. Я думаю, хорошо использовать язык запросов графа, такой как Cipher в neo4j или Gremlin в JanusGraph/TitanDB. Neo4j хорош, но у него кластеризация только в EE и мне нужно что-то с открытым исходным кодом. Так что теперь я думаю о последних, у которых по умолчанию есть Gremlin + Cassandra + Elasticsearch.
  3. Может быть, мне ничего из этого не нужно, просто сохраните график как матрицу смежности в какой-нибудь СУБД, такой как Postgres, и все.
  4. Не знаю, нужен ли мне Spark во 2 или 3. Нужен ли он вообще?

Мой начальник сказал мне проверить Elasticsearch. Но я думаю, что могу использовать его только как дополнительный полнотекстовый поисковик.

Спасибо за любой ответ!


person Gleb Ignatev    schedule 28.05.2018    source источник


Ответы (1)


Начнем с пары уточняющих вопросов:

  1. 1 ТБ не является огромным объемом данных, если он также (близок) к общему объему данных. Это ? Сколько новых данных вы ожидаете и с какой скоростью они будут поступать.
  2. Зачем вам обходить весь график, если каждый JSON просто ссылается на небольшую часть графика? Это либо новые данные, либо обновление существующих данных (которые вы должны точно определить), не так ли?
  3. Да, именно так вы используете графовую базу данных...

Остальное зависит от вашего ответа на 1). Если мы говорим о количестве поступающих событий Интернета вещей (десятки тысяч в секунду... стабильно), вам может понадобиться решение для больших данных. Если нет, то ваша главная проблема состоит в том, чтобы выполнить первоначальную загрузку и затем легко отплыть оттуда ;-).

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

С уважением, Том

person Tom Geudens    schedule 29.05.2018
comment
Эй, спасибо за ваш ответ! Это очень полезно! Наверное, вы правы, я как-то сделал неверные выводы. Не знаю насчет общего объема данных, но сомневаюсь, что больше 100 Тб. Что касается интенсивности поступающих данных, она будет очень низкой. Так что я думаю, что мне действительно не нужны вещи типа MapReduce, может быть, я должен просто попробовать graph db и все. - person Gleb Ignatev; 30.05.2018
comment
Я не думаю, что скоро получу больше отзывов, поэтому я отмечу ваш ответ как ответ к концу дня. - person Gleb Ignatev; 30.05.2018
comment
@GlebIgnatieff Я не могу сделать для вас такой вывод (это было бы самоуверенно :-), но вот пара замечаний. 1) Размер начальной загрузки не так важен, как количество транзакционных обновлений. 2) Размер базы данных не так важен, если большинство (если не все) запросов касаются только небольшой ее части и если эта небольшая часть остается примерно того же размера. независимо от того, насколько велика общая база данных. - person Tom Geudens; 30.05.2018