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

Если кто-то создает базу данных поверх другой базы данных, например, твиттер, эта база данных наследует ограничения и неэффективность базовой базы данных?

Меня особенно интересует titan db (http://thinkaurelius.com) из-за их претензий на поддержку эффективного разделения данных на узлах.

Они утверждают, что поддерживают распределение данных по узлам из-за эффективности кассандры. Однако neo4j утверждает, что причина, по которой они не распространяют данные между узлами, а скорее дублирует весь набор данных на каждом node, заключается в том, что любой обход графика, который оставляет один node, и, следовательно, должен перемещаться по сети Ethernet, слишком медленный, чтобы быть практичным.

Так как cassandra не знает графа, он не может оптимизировать, чтобы вести обход графика на одном node. Поэтому большинство обходов графика будут проходить через границы node.

Утверждается ли, что титаны эффективно масштабируются по узлам true?

Ответ 1

Titan определяет порядок сортировки ключей для базового сервера базы данных (BOP для Cassandra, по умолчанию для HBase), а затем присваивает идентификаторы вершинам таким образом, что вершины, которые назначены одному блоку разделов, имеют идентификаторы, которые назначены на одну и ту же физическую машину, Другими словами, Титан "понимает", как базовый сервер хранилища распределяет данные и использует методы разбиения графов, которые используют это понимание. Титан использует полуавтоматическое разбиение, которое включает знания домена.

В тесте Пирсона (http://arli.us/edu-planet-scale) граф был разбит по университетам, который является почти оптимальным критерием разбиения на этот конкретный набор данных. Без разбиения на разделы масштабирование до 120 миллиардов краев было бы почти невозможно.

Titan основывается на проверенных технологиях (для масштабирования, настойчивости, горячего резервирования, доступности, аварийного восстановления и т.д.), но инновации на графическом уровне. Это тот же маршрут, что и Twitter Flock, так и Facebook Tao. Хотя это означает, что Titan медленнее при очень глубоких обходах, он позволяет Titan масштабироваться до очень больших графиков или очень много параллельных транзакций (чтение и запись).

Ответ 2

Хороший вопрос. Я думаю, это все о калибровке. Twitter (который использует Cassandra) использует базу данных графа по-настоящему определенному (они имеют только два уровня "глубины" ), поэтому запросы не должны проходить длинные графики (и они не вынуждены реплицировать весь набор данных). Я думаю, что Titan и Neo4j правы, Neo4j пытается предоставить графическую базу данных для общего назначения, поэтому у вас есть несколько решений в зависимости от того, как вы их используете, и они не могут знать, как люди будут использовать его, чтобы они применяли более распространенное решение: реплицируя весь набор данных.

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

Итак, каково будет ваше использование? Я никогда не использовал Titan, но хорошим испытанием было бы сравнить его производительность с Neo4j в зависимости от "глубины" запросов.