2016-03-24 10 views
6

W moim systemie mam wymóg, aby liczba krawędzi w węźle była przechowywana jako własność wewnętrzna na wierzchołku, jak również indeks centryczny wierzchołka na określonej krawędzi wychodzącej. To oczywiście wymaga ode mnie policzenia liczby krawędzi w węźle po zakończeniu ładowania wszystkich danych. Czynię to w następujący sposób:Zliczanie Super węzłów na tytanie

long edgeCount = graph.getGraph().traversal().V(vertexId).bothE().count().next(); 

Jednak kiedy skalowanie moich testów do punktu, w którym moje niektóre węzły są „super” węzły Otrzymuję następujący wyjątek od powyższej linii:

Caused by: com.netflix.astyanax.connectionpool.exceptions.TransportException: TransportException: [host=127.0.0.1(127.0.0.1):9160, latency=4792(4792), attempts=1]org.apache.thrift.transport.TTransportException: Frame size (70936735) larger than max length (62914560)! 
    at com.netflix.astyanax.thrift.ThriftConverter.ToConnectionPoolException(ThriftConverter.java:197) ~[astyanax-thrift-3.8.0.jar!/:3.8.0] 
    at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:65) ~[astyanax-thrift-3.8.0.jar!/:3.8.0] 
    at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:28) ~[astyanax-thrift-3.8.0.jar!/:3.8.0] 
    at com.netflix.astyanax.thrift.ThriftSyncConnectionFactoryImpl$ThriftConnection.execute(ThriftSyncConnectionFactoryImpl.java:153) ~[astyanax-thrift-3.8.0.jar!/:3.8.0] 
    at com.netflix.astyanax.connectionpool.impl.AbstractExecuteWithFailoverImpl.tryOperation(AbstractExecuteWithFailoverImpl.java:119) ~[astyanax-core-3.8.0.jar!/:3.8.0] 
    at com.netflix.astyanax.connectionpool.impl.AbstractHostPartitionConnectionPool.executeWithFailover(AbstractHostPartitionConnectionPool.java:352) ~[astyanax-core-3.8.0.jar!/:3.8.0] 
    at com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$4.execute(ThriftColumnFamilyQueryImpl.java:538) ~[astyanax-thrift-3.8.0.jar!/:3.8.0] 
    at com.thinkaurelius.titan.diskstorage.cassandra.astyanax.AstyanaxKeyColumnValueStore.getNamesSlice(AstyanaxKeyColumnValueStore.java:112) ~[titan-cassandra-1.0.0.jar!/:na] 

Jaki jest najlepszy sposób, aby to naprawić? Czy powinienem po prostu zwiększyć rozmiar klatki, czy jest lepszy sposób na zliczanie liczby krawędzi na węźle?

Odpowiedz

3

Tak, konieczne będzie zwiększenie rozmiaru ramki. Kiedy masz supernodę, istnieje naprawdę duży wiersz, który musi zostać odczytany z zaplecza pamięci, a to jest nawet prawdziwe w przypadku OLAP. Zgadzam się, że jeśli planujesz obliczyć to na każdym wierzchołku na wykresie, najlepiej byłoby zrobić to jako operację OLAP.

Ten i kilka innych dobrych wskazówek można znaleźć w tym Titan mailing list thread. Pamiętaj, że link jest dość stary, więc koncepcje są nadal aktualne, ale niektóre nazwy właściwości konfiguracyjnych Titan mogą być inne.

+0

Czy to oznacza, że ​​muszę zacząć analizować integrację Gremlin-Hadoop? –

3

Takie zadanie, które z natury jest OLAP, powinno być wykonywane przy użyciu systemu rozproszonego, bez użycia przejścia.

Istnieje koncepcja o nazwie GraphComputer w TinkerPop 3, której można użyć do wykonania takiego zadania.

Pozwala zasadniczo na uruchamianie zapytań Gremlina, które będą oceniane na wielu komputerach.

Na przykład można użyć numeru SparkGraphComputer, aby wyświetlać zapytania pod numerem Apache Spark.

Powiązane problemy