Hi Thomas,
From what I understand (someone correct me if I'm wrong please)
- Neo4j does reuse the holes.
- It will not reuse the holes you created in the current session, but will
reuse all holes created in previous sessions.
My problem is a bit of a strange use case as I'm trying to reduce the
Hey,
Is there a way to compact the data stores (relationships, nodes, properties)
in Neo4j?
I don't mind if its a manual operation.
I have some datasets that have had a lot of relationships removed from them
but the file is still the same size, so I'm guessing there are a lot of
holes in this
Alex,
You are correct about the holes in the store file and I would
suggest you export the data and then re-import it again. Neo4j is not
optimized for the use case were more data is removed than added over
time.
It would be possible to write a compacting utility but since this is
not a very
Hi Johan,
Do you mean a utility that creates a new Neo4j instance and copies all
entities into it from an old Neo4j instance?
That's definitely no problem.
I've written a bit of import/export code in my graph_gen_utils branch.
I have a GraphReader interface which is generic and only contains
I've thought about this briefly, and somehow it actually seems easier (to
me) to consider a compacting (defragmenting) algorithm than a generic
import/export. The problem is that in both cases you have to deal with the
same issue, the node/relationship ID's are changed. For the import/export
this
Hi Craig,
Just a quick note about needing to keep all IDs in memory during an
import/export operation. The way I'm doing it at the moment it's not
necessary to do so.
When exporting:
Write IDs to the exported format (this could be JSON, XML, GML, GraphML,
etc)
When importing:
First import all
Yes. I guess you cannot escape an old-new ID map (or in your case ID-GID). I
think it is possible to maintain that outside the database:
- In memory, as I suggested, but only valid under some circumstances
- On disk, and lucene is a good idea here. Why not index with lucene, but
without
- On disk, and lucene is a good idea here. Why not index with lucene,
but without storing the property to the node?
I like it!
This sounds like a cleaner approach than my current one, and (I'm not sure
about how to do this either) may be no more complex than the way I'm doing
it.
Like you say,
On Wed, Jun 2, 2010 at 9:30 AM, Johan Svensson jo...@neotechnology.comwrote:
Alex,
You are correct about the holes in the store file and I would
suggest you export the data and then re-import it again. Neo4j is not
optimized for the use case were more data is removed than added over
time.
9 matches
Mail list logo
