Introducción a las BBDD de grafos

• Basadas en el concepto matemático de grafo
• Nodos o vértices, que contienen un identificador y un conjunto de propiedades
• Un conjunto de arcos o aristas que conectan pares de nodos, de forma dirigida o no; los arcos pueden tener sus propios atributos
• En el caso particular de Neo4j, los nodos también pueden tener un conjunto de etiquetas (label) y pares ⟨clave, valor⟩. La etiqueta equivale a su «tipo»
• Incluyen un lenguaje de búsqueda de elementos y manipulación del grafo

Ventajas de las BBDD de grafos

• Navegación eficiente: recorrido de relaciones en tiempo constante mediante index-free adjacency
• Flexibilidad de esquema: fácil añadir nuevos tipos de nodos y relaciones sin afectar a los datos existentes
• Consultas intuitivas: el lenguaje refleja la estructura visual del grafo (ASCII art)
• Modelado natural: muchos dominios son inherentemente grafos (redes sociales, dependencias, rutas)
• Análisis de relaciones: algoritmos especializados para detectar patrones, comunidades, rutas óptimas

Desventajas y limitaciones

• Operaciones agregadas masivas: menos eficientes que los RDBMS para operaciones OLAP
• Escalado horizontal limitado: Neo4j Community sólo soporta una instancia; Enterprise usa replicación master-slave
• Consultas globales costosas: recorrer todo el grafo puede ser ineficiente
• Curva de aprendizaje: requiere pensar de forma diferente al modelo relacional
• Tamaño de datos: mejor rendimiento cuando el grafo completo cabe en memoria

Property Graph vs. RDF

Dos modelos principales de bases de datos de grafos:

• Property Graph (Neo4j, Neptune, CosmosDB): nodos y relaciones con propiedades, relaciones con nombre y dirección, lenguajes Cypher/Gremlin — orientado a aplicaciones
• RDF (Resource Description Framework): tripletas sujeto-predicado-objeto, ontologías y razonamiento lógico, lenguaje SPARQL, bases de datos Blazegraph/GraphDB/Stardog — orientado a web semántica y conocimiento

Neo4j es Property Graph

Tipos de BBDD de grafos

Se pueden clasificar atendiendo a dos dimensiones:

• Almacenamiento subyacente: nativo de grafos, o bien relacional/de otro tipo
• Motor de procesamiento: motor de grafos donde las entidades «apuntan» físicamente a otras (index-free adjacency), o bien se simula el procesamiento de grafos usando índices

Ejemplos por cuadrante: nativo/nativo — Neo4j, InfiniteGraph; no nativo/nativo — OrientDB, JanusGraph; no nativo/no nativo — GraphDB sobre RDBMS

Aplicabilidad de grafos

• Los grafos, conceptualmente, aparecen en casi cualquier dominio
• Su flexibilidad hace que se puedan aplicar de diferentes formas:
  • Gestión de identidad y acceso (IAM): permisos, roles, herencia
  • Cadenas de suministro: proveedores, productos, rutas
  • Análisis de dependencias de software: paquetes, versiones
  • Redes de transporte: estaciones, rutas, conexiones
  • Estructuras jerárquicas recursivas: organizaciones, taxonomías

Flexibilidad y eficiencia

Las bases de datos de grafos suplen dos carencias fundamentales:

1. La carencia expresiva del resto de paradigmas para ciertas relaciones entre datos
2. La eficiencia del tratamiento de estos datos con algoritmos basados en grafos, frente a otros paradigmas

Clave de eficiencia: index-free adjacency — cada nodo mantiene referencias directas a nodos adyacentes, sin búsquedas en índices, tiempo constante O(1) para acceder a vecinos

Ejemplo: una relación de amistad (friend) entre usuarios de una red social

Consulta: amigos de Bob

SELECT p1.Person
FROM Person p1 JOIN PersonFriend
ON PersonFriend.FriendID = p1.ID
JOIN Person p2
ON PersonFriend.PersonID = p2.ID
WHERE p2.Person = 'Bob'

Es sencilla y no es computacionalmente muy compleja

Consulta inversa

Como la relación de amistad no siempre es recíproca, a veces hay que hacer la búsqueda inversa:

SELECT p1.Person
FROM Person p1 JOIN PersonFriend
ON PersonFriend.PersonID = p1.ID
JOIN Person p2
ON PersonFriend.FriendID = p2.ID
WHERE p2.Person = 'Bob'

Esta consulta es más costosa que la anterior, porque hay que recorrer todas las filas de PersonFriend

El experimento de Neo4j in Action

Partner y Vukotic compararon Neo4j y MySQL con esta tabla, buscando amigos de amigos en diferentes profundidades, en una red de 1 millón de personas con ~50 amigos cada una. (Experimento de 2014; el principio de eficiencia se mantiene en versiones modernas.)

Nota: SQL puede ser mejor para operaciones masivas de agregación (OLAP) sobre todo el dataset

Introducción a Neo4j

• Base de datos de grafos con posibilidad de extenderse a varios ordenadores (sólo uno soporta escritura, replicación master-slave)
• Versiones: Community (gratuita, una instancia, límites de autenticación), Enterprise (clustering, backup online, seguridad avanzada), Neo4j Aura (cloud gestionado, DBaaS)
• Compatible con el estándar Apache TinkerPop
• Lenguaje de creación y consulta de grafos: Cypher
• Browser web y consola para lanzar consultas; Neo4j Desktop para desarrollo local

Introducción a Neo4j (ii)

• Multitud de algoritmos de recorrido de grafos, con la posibilidad de añadir más
• APOC Library: procedimientos y funciones avanzadas, muy utilizada
• Graph Data Science (GDS): librería de algoritmos de grafos (PageRank, comunidades, etc.)
• Se puede usar desde Jupyter Notebook a través de una extensión
• Drivers oficiales: Python, Java, JavaScript, .NET, Go
• Ofrece también todos sus servicios a través de un API REST

El lenguaje Cypher

Lenguaje de especificación de búsquedas y modificaciones en el grafo

Nodos:

( nombre:Etiqueta { propiedad: valor, ... } )

Relaciones, usando ASCII art:

(nodo_origen)-[:RELACIÓN]->(nodo_destino)

Cypher: relaciones

Con propiedades:

(n1)-[:RELACIÓN {año: 2017}]->(n2)

En el otro sentido:

(nodo1)<-[:RELACIÓN]-(nodo2)

Omitiendo relaciones y nodos intermedios:

(nodo1)-[:RELACIÓN]->()-[:RELACIÓN2]->(nodo2)
(nodo1)-->(nodo3)

Cypher: repetición de relaciones

Repetida un número acotado o no acotado de veces:

(nodo1)-[:RELACIÓN*1..10]->(nodo2)
(nodo3)-[:RELACIÓN*0..]->(nodoX)

Conjunto no limitado de relaciones, de forma general:

(nodo1)-[*]-(nodo2)

Cypher: CREATE

Creación de nodos y enlaces:

CREATE (nodo1:Etiqueta1 { propX: valorX, ... } ),
       (nodo2:Etiqueta2 { propY: valorY, ... } ),
       ...
       (nodo1)-[:RELACIONADO_CON]->(nodo2)

Consultas: MATCH

Consulta a través de ejemplos (query by example): especifica nodos y propiedades como ejemplo de lo que se busca

MATCH especificación, especificación, ...
[WHERE especificación]
[ORDER BY campo]
[LIMIT x]
RETURN [DISTINCT] nodos

MATCH también se usa para seleccionar nodos a crear (CREATE) o borrar (DELETE/DETACH DELETE). Retorna todos los posts:

MATCH (n:Post) RETURN n

Consultas: restricciones

MATCH (n { nombre: 'Diego' }) RETURN n.edad;

En este caso se devuelve una tabla, no un subgrafo

Consultas: nodos anónimos y caminos

Todos los abuelos con sus nietos:

MATCH (nieto), (abuelo),
   (nieto)-[:HIJO_DE]->()-[:HIJO_DE]->(abuelo)
 RETURN abuelo, nieto

O incluso (nótense los nodos anónimos):

MATCH (nieto)-[:HIJO_DE]->()-[:HIJO_DE]->(abuelo)
  RETURN abuelo, nieto

También:

MATCH (nieto)-[:HIJO_DE*2]->(abuelo)
  RETURN abuelo, nieto

Funciones de agregación (ii)

// Promedio de edad de usuarios
MATCH (u:User)
RETURN avg(u.edad) AS edad_promedio

// Recopilar amigos en una lista
MATCH (p:Persona {nombre: 'Ana'})-[:AMIGO_DE]->(amigo)
RETURN p.nombre, collect(amigo.nombre) AS amigos

Otras funciones: sum(), max(), min(), collect(), percentileDisc()

Funciones de strings

MATCH (p:Post)
RETURN p.Title, toUpper(p.Title), toLower(p.Title)

MATCH (p:Post)
WHERE p.Title CONTAINS 'Neo4j'
RETURN p.Title

// split, substring, replace, trim
RETURN split("a,b,c", ",") AS lista

Funciones de listas

MATCH (u:User)-[:AMIGO_DE]->(amigo)
WITH u, collect(amigo) AS amigos
RETURN u.nombre, size(amigos) AS num_amigos,
       head(amigos) AS primer_amigo

Otras: tail(), last(), range(), reduce()

UNWIND: descomponer listas

UNWIND convierte una lista en filas individuales:

UNWIND [1, 2, 3] AS numero
RETURN numero

Útil para procesar listas de datos:

WITH ['Alice', 'Bob', 'Charlie'] AS nombres
UNWIND nombres AS nombre
CREATE (:Persona {nombre: nombre})

UNWIND con collect

MATCH (u:User)
WITH collect(u.email) AS emails
UNWIND emails AS email
RETURN toLower(email) AS email_normalizado

Variables de caminos

Se pueden asignar caminos completos a variables:

MATCH p = (a:Persona)-[:AMIGO_DE*1..3]->(b:Persona)
WHERE a.nombre = 'Ana' AND b.nombre = 'Carlos'
RETURN p, length(p)

Útil para algoritmos de caminos:

MATCH p = shortestPath(
  (a:Persona {nombre: 'Ana'})-[*]-(b:Persona {nombre: 'Carlos'})
)
RETURN p, length(p) AS distancia

Todos los caminos más cortos

MATCH p = allShortestPaths(
  (a:Persona {nombre: 'Ana'})-[*]-(b:Persona {nombre: 'Carlos'})
)
RETURN p

Filtros en relaciones

MATCH (u:User)-[r:AMIGO_DE WHERE r.desde > 2020]->(amigo)
RETURN u.nombre, amigo.nombre, r.desde

También en patrones de camino variable:

MATCH (a)-[r:CONOCE*1..3 WHERE r.confianza > 0.7]->(b)
RETURN a, b

UNION: combinar resultados

UNION elimina duplicados; UNION ALL los mantiene

// Usuarios activos: escribieron post O comentaron
MATCH (u:User)-[:WROTE]->(:Post)
RETURN u.nombre AS usuario
UNION
MATCH (u:User)-[:COMMENTED]->(:Comment)
RETURN u.nombre AS usuario

Las columnas devueltas deben coincidir en tipo y número

UNION ALL: mantiene duplicados

MATCH (u:User)-[:WROTE]->(:Post)
RETURN u.nombre AS usuario, 'post' AS actividad
UNION ALL
MATCH (u:User)-[:COMMENTED]->(:Comment)
RETURN u.nombre AS usuario, 'comment' AS actividad

CALL: procedimientos

• CALL ejecuta procedimientos almacenados
• Neo4j incluye muchos procedimientos built-in; APOC añade 450+ procedimientos más

// Listar todos los procedimientos
CALL dbms.procedures()
YIELD name, signature, description
WHERE name STARTS WITH 'apoc'
RETURN name, signature
LIMIT 10

CALL: con y sin resultados

// Ejecutar procedimiento con resultados
CALL db.labels() YIELD label
RETURN label, count(*) AS count

// Procedimiento sin resultados (standalone)
CALL db.clearQueryCaches()

CALL: procedimientos útiles

// Ver esquema del grafo
CALL db.schema.visualization()

// Estadísticas de nodos
CALL db.stats.retrieve('NODES')

// Crear constraint dinámicamente con APOC
CALL apoc.schema.assert(
  {User: ['email']},
  {User: ['id']}
)

Índices

Se pueden crear índices para búsquedas rápidas sobre atributos:

CREATE INDEX post_title_idx IF NOT EXISTS
FOR (n:Etiqueta) ON (n.nombre_campo)

Índices compuestos

Un índice sobre varias propiedades de la misma etiqueta:

CREATE INDEX usuario_nombre_apellido IF NOT EXISTS
FOR (u:Usuario) ON (u.nombre, u.apellido);

• Sirve a las consultas que filtran a la vez por nombre y apellido
• Existe también en la edición Community, la de las prácticas

Índices full-text

CREATE FULLTEXT INDEX postContent IF NOT EXISTS
FOR (n:Post) ON EACH [n.title, n.body];

// Uso
CALL db.index.fulltext.queryNodes(
  'postContent', 'Neo4j AND graphs'
) YIELD node, score
RETURN node.title, score

Ver índices y constraints:

SHOW INDEXES;
SHOW CONSTRAINTS;

Principios de modelado en grafos

• Empezar por las preguntas, no por los datos: ¿qué consultas necesitamos responder? Diseñar el modelo para optimizarlas
• Whiteboard-friendly: dibujar el modelo en una pizarra
• Principio: los datos conectados son tan importantes como los datos mismos
• Desnormalizar: a diferencia de RDBMS, duplicar datos puede ser beneficioso
• Evolución: el modelo puede evolucionar sin migraciones complejas

Relaciones vs. propiedades

Usar relaciones cuando: conectan dos entidades, la conexión tiene semántica importante, hay que navegarla, o puede tener propiedades (peso, fecha, tipo)

Usar propiedades cuando: el valor es un dato simple del nodo, sin necesidad de navegación

Ejemplo: «Trabaja en» como relación si se quiere «empleados de la empresa X»; como propiedad si sólo se guarda el nombre, sin navegación

Fan-out y fan-in

• Fan-out: un nodo con muchas relaciones salientes (p. ej. usuario con miles de posts) — puede ser lento al cargar el nodo
• Fan-in: un nodo con muchas relaciones entrantes (p. ej. tag popular en miles de posts) — problema de rendimiento similar
• Solución: usar nodos intermedios o diferentes tipos de relaciones
  • Agrupar por fecha, categoría, etc
  • Ejemplo: Usuario → Año → Mes → Posts

Graph Data Science Library (GDS)

• Librería de Neo4j para algoritmos de grafos avanzados; se instala como plugin separado
• Tres categorías principales:
  1. Pathfinding: encontrar caminos y rutas óptimas
  2. Centralidad: identificar nodos importantes
  3. Detección de comunidades: encontrar grupos conectados
  4. Similitud: encontrar nodos similares
• Operación típica: crear proyección del grafo en memoria, ejecutar el algoritmo, y escribir o analizar los resultados

Pathfinding: shortest path

Camino más corto entre dos nodos:

MATCH p = shortestPath(
  (a:Ciudad {nombre: 'Madrid'})-[*]-(b:Ciudad {nombre: 'Barcelona'})
)
RETURN p, length(p)

Pathfinding: Dijkstra

Camino más corto con pesos:

MATCH (a:Ciudad {nombre: 'Madrid'}), (b:Ciudad {nombre: 'Barcelona'})
CALL gds.shortestPath.dijkstra.stream({
  sourceNode: a, targetNode: b,
  relationshipWeightProperty: 'distancia'
})
YIELD path, totalCost
RETURN path, totalCost

• A*: camino con heurística (más rápido)
• All Shortest Paths: todos los caminos más cortos

Algoritmos de centralidad

PageRank: importancia basada en conexiones — original de Google, identifica nodos influyentes

CALL gds.pageRank.stream({
  nodeProjection: 'User',
  relationshipProjection: 'FOLLOWS'
})
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).nombre AS usuario, score
ORDER BY score DESC LIMIT 10

• Betweenness Centrality: nodos que actúan como puentes
• Closeness Centrality: nodos más cerca del resto
• Degree Centrality: basado en número de conexiones

Algoritmos de comunidades

Louvain: detecta comunidades optimizando modularidad

CALL gds.louvain.stream({
  nodeProjection: 'User',
  relationshipProjection: 'FRIENDS_WITH'
})
YIELD nodeId, communityId
RETURN communityId, count(*) AS size
ORDER BY size DESC

• Label Propagation: propagación de etiquetas para comunidades
• Weakly Connected Components: componentes conectados
• Triangle Count: detecta clustering

Algoritmos de similitud

Node Similarity: nodos con vecinos similares

CALL gds.nodeSimilarity.stream({
  nodeProjection: 'User',
  relationshipProjection: 'LIKES'
})
YIELD node1, node2, similarity
WHERE similarity > 0.5
RETURN gds.util.asNode(node1).nombre,
       gds.util.asNode(node2).nombre,
       similarity

• Jaccard Similarity: basado en intersección de vecinos
• Cosine Similarity: para vectores de propiedades — útil para sistemas de recomendación

Evitar productos cartesianos

// MAL - Cartesian product
MATCH (u:User), (p:Post)
WHERE u.id = p.userId
RETURN u, p

// BIEN - Usar relaciones
MATCH (u:User)-[:WROTE]->(p:Post)
RETURN u, p

Usar índices

// Crear índice primero
CREATE INDEX user_email IF NOT EXISTS
FOR (u:User) ON (u.email);

// Consulta aprovecha el índice
MATCH (u:User {email: 'user@example.com'})
RETURN u

Usar parámetros

Para reutilización de planes:

// Sin parámetros - nuevo plan cada vez
MATCH (u:User {email: 'user1@example.com'}) RETURN u
MATCH (u:User {email: 'user2@example.com'}) RETURN u

// Con parámetros - plan reutilizado
MATCH (u:User {email: $email}) RETURN u

Analizar rendimiento: EXPLAIN

Muestra el plan de ejecución sin ejecutar:

EXPLAIN
MATCH (u:User {email: $email})-[:WROTE]->(p:Post)
RETURN u, p

Útil para ver si usa índices

Analizar rendimiento: PROFILE

Ejecuta y muestra estadísticas detalladas:

PROFILE
MATCH (u:User {email: $email})-[:WROTE]->(p:Post)
RETURN u, p

Muestra: filas procesadas en cada paso, db hits (accesos a disco/caché) y tiempo de ejecución

Buscar: alto db hits, muchas filas procesadas innecesariamente

Operaciones masivas: batching

Para operaciones masivas, usar transacciones por lotes; no insertar/actualizar millones de nodos en una sola transacción:

// Cargar CSV en lotes de 1000
LOAD CSV WITH HEADERS FROM 'file:///users.csv' AS row
CALL {
  WITH row
  MERGE (u:User {id: row.id})
  SET u.nombre = row.nombre, u.email = row.email
} IN TRANSACTIONS OF 1000 ROWS

APOC para procesamiento paralelo

CALL apoc.periodic.iterate(
  "MATCH (u:User) RETURN u",
  "SET u.processed = true",
  {batchSize: 1000, parallel: true}
)

Configuración de memoria

• Heap memory: para transacciones y consultas. Típico 8–16 GB en producción; se configura con dbms.memory.heap.max_size en neo4j.conf
• Page cache: para cachear el grafo en memoria. Lo más grande posible (RAM disponible − heap − SO); se configura con dbms.memory.pagecache.size. Idealmente, todo el grafo en page cache
• Regla general: 50 % de la RAM para page cache, 25 % para heap
• Monitorizar: :queries en el browser, métricas JMX

Transacciones y concurrencia

• Neo4j es ACID completo
• Usa write locks en nodos/relaciones modificadas; los read locks no bloquean otras lecturas
• Deadlocks posibles en escrituras concurrentes: Neo4j los detecta y aborta la transacción automáticamente — hay que reintentarla
• Buenas prácticas: transacciones cortas, procesar en lotes (batching), usar MERGE con cuidado (puede causar conflictos), evitar modificar los mismos nodos desde múltiples threads

Modelo de datos de Stack Overflow

Entidades principales: Users, Posts (preguntas y respuestas), Tags, Comments

Relaciones:

• User -[:WROTE]-> Post
• Post -[:ANSWERS]-> Post (respuesta a pregunta)
• Post -[:TAGGED_WITH]-> Tag
• User -[:COMMENTED]-> Comment -[:ON]-> Post

Stack Overflow, SQL

La consulta de reciprocidad, sesión 2: parejas de usuarios que se han respondido mutuamente

CREATE VIEW Pairs AS SELECT DISTINCT Q.OwnerUserId AS questioner, A.OwnerUserId AS answerer
FROM Posts Q JOIN Posts A ON Q.AcceptedAnswerId = A.Id
AND Q.OwnerUserId <> A.OwnerUserId;

SELECT P1.questioner AS U1, P2.questioner AS U2
FROM Pairs P1, Pairs P2
WHERE P1.questioner = P2.answerer
  AND P2.questioner = P1.answerer
  AND P1.questioner < P2.questioner;

Stack Overflow, SQL (con CTE)

WITH Pairs AS (
  SELECT DISTINCT Q.OwnerUserId AS questioner, A.OwnerUserId AS answerer
  FROM Posts Q JOIN Posts A ON Q.AcceptedAnswerId = A.Id
  AND Q.OwnerUserId <> A.OwnerUserId
)
SELECT P1.questioner AS U1, P2.questioner AS U2
FROM Pairs P1, Pairs P2
WHERE P1.questioner = P2.answerer
  AND P2.questioner = P1.answerer
  AND P1.questioner < P2.questioner;

Top usuarios por respuestas aceptadas

MATCH (u:User)-[:WROTE]->(a:Answer)-[:ANSWERS]->(q:Question)
WHERE q.AcceptedAnswerId = a.Id
RETURN u.DisplayName, count(a) AS respuestas_aceptadas
ORDER BY respuestas_aceptadas DESC
LIMIT 10

Preguntas sin respuesta

MATCH (q:Question)
WHERE NOT (q)<-[:ANSWERS]-()
RETURN q.Title, q.CreationDate
ORDER BY q.ViewCount DESC
LIMIT 100

Tags más relacionados (co-ocurrencia)

MATCH (t1:Tag)<-[:TAGGED_WITH]-(q:Question)-[:TAGGED_WITH]->(t2:Tag)
WHERE t1.TagName < t2.TagName
RETURN t1.TagName, t2.TagName, count(q) AS veces
ORDER BY veces DESC
LIMIT 20

Expertos por tag

Más respuestas aceptadas en un tag:

MATCH (u:User)-[:WROTE]->(a:Answer)-[:ANSWERS]->(q:Question)
      -[:TAGGED_WITH]->(t:Tag {TagName: 'neo4j'})
WHERE q.AcceptedAnswerId = a.Id
RETURN u.Id AS usuario, u.DisplayName AS nombre,
       count(a) AS respuestas
ORDER BY respuestas DESC, usuario
LIMIT 10

Agrupamos también por Id para no sumar las respuestas de usuarios distintos con el mismo nombre visible

Sistema de recomendación simple

Recomendar amigos: amigos de mis amigos que no conozco

MATCH (yo:User {nombre: 'Ana'})-[:AMIGO_DE]->()-[:AMIGO_DE]->(recomendado)
WHERE NOT (yo)-[:AMIGO_DE]->(recomendado) AND recomendado <> yo
RETURN recomendado.nombre, count(*) AS amigos_comunes
ORDER BY amigos_comunes DESC
LIMIT 10

Recomendar productos

Basado en compras similares:

MATCH (yo:User {id: 123})-[:COMPRO]->(p:Producto)
      <-[:COMPRO]-(otro:User)-[:COMPRO]->(recomendacion:Producto)
WHERE NOT (yo)-[:COMPRO]->(recomendacion)
RETURN recomendacion.nombre, count(*) AS popularidad
ORDER BY popularidad DESC
LIMIT 10

Recomendar contenido

Por similitud de intereses:

MATCH (yo:User {id: 123})-[:INTERESTED_IN]->(t:Tag)
      <-[:INTERESTED_IN]-(similar:User)-[:WROTE]->(post:Post)
WHERE NOT (yo)-[:WROTE]->(post)
WITH post, count(DISTINCT similar) AS usuarios_similares
RETURN post.titulo, usuarios_similares
ORDER BY usuarios_similares DESC
LIMIT 10

Carga de datos desde CSV

• Neo4j puede cargar datos directamente desde archivos CSV
• Los archivos deben estar en import/, dentro del directorio de Neo4j

Cargar usuarios:

LOAD CSV WITH HEADERS FROM 'file:///users.csv' AS row
CALL {
  WITH row
  MERGE (u:User {Id: row.Id})
  SET u.DisplayName = row.DisplayName,
      u.Reputation = toInteger(row.Reputation),
      u.CreationDate = datetime(row.CreationDate)
} IN TRANSACTIONS OF 1000 ROWS

Importación masiva

Para grandes volúmenes, neo4j-admin import:

neo4j-admin import \
  --nodes=User=users.csv \
  --nodes=Post=posts.csv \
  --relationships=WROTE=wrote.csv \
  --relationships=ANSWERS=answers.csv

Mucho más rápido (millones de nodos por minuto). Requiere base de datos vacía

Recursos de aprendizaje

• GraphAcademy (graphacademy.neo4j.com): cursos gratuitos online interactivos y certificaciones oficiales, de básico a avanzado
• Neo4j Sandbox (sandbox.neo4j.com): entornos precargados para experimentar (Movie Graph, Twitter, Game of Thrones, etc.), sin instalación
• Documentación oficial (neo4j.com/docs)
• Comunidad: Neo4j Community Forum, Stack Overflow (tag neo4j)
• Canal de YouTube de Neo4j: tutoriales y casos de uso

Herramientas y extensiones

• Neo4j Desktop: entorno de desarrollo local, gestión de varias bases de datos, plugins (APOC, GDS, Bloom)
• Neo4j Bloom: visualización y exploración de grafos, interfaz para usuarios no técnicos, búsqueda en lenguaje natural
• APOC (Awesome Procedures On Cypher): 450+ procedimientos y funciones; importación/exportación de datos; utilidades de texto, fecha, JSON
• Neoclipse: IDE Eclipse para Neo4j (descontinuado, pero útil)