Hi Rick,

On Wed, Dec 9, 2009 at 4:54 PM, Rick Bullotta
<rick.bullo...@burningskysoftware.com> wrote:
> Questions:
>
> -          If you delete the reference node (id = 0), how can you recreate
> it?

Being able to delete the reference node can sometimes be a problem but
I have not come up with a good solution on how to fix it. You can set
a different reference node using non standard API
(NeoModule.setReferenceNode). You can also use the batch inserter to
recreate it invoking BatchInserter.createNode( 0, null ) or start with
a new db.

>
> -          If you have a number of "loose" or disjoint graphs structured as
> trees with a single root node, is there a best practice for
> tracking/iterating only the top level node(s) of these disjoint graphs?  Is
> relating them to the reference node and doing a first level traversal the
> best way?

I would say relating them back to the reference node (or a
sub-reference node, see
http://wiki.neo4j.org/content/Design_Guide#Subreferences) is the best
way.

>
> -          We would like to treat our properties as slightly more complex
> than a simple type (they might have a last modified date, validity flag, and
> so on) - given the choice between adding properties to track this state or
> using nodes and relationships for these entities, what are the pros and cons
> of each approach?

Depends on use-cases you have that involves the specific property. If
you just need to get the last modified date such as
"entity.getLastModified()" a plain property is a good solution. If you
have a use-case that is "service.giveMeAllEntitiesOrderedByDate()"
then using relationships and nodes may be a better idea.

>
> -          One aspect of our application will store nodes that can be
> considered similar to event logs.  There may be many thousands of these
> nodes per "event stream".  We would like to be able to traverse the entries
> in chronological order, very quickly.  We were considering the following
> design possibilities:
>
> o   Simply create a node for each "stream" and a node for each entry, with a
> relationship between the stream and the entry, then implement our own sort
> routine
>
> o   Similar to the above, but create a node for each "day", and manage
> relationships to allow traversal by stream and/or day
>
> o   Create a node for each stream, a node for each entry and treat the
> entries as a forward-only linked list using relationships between the
> entries (and of course a relationship between the stream and the "first"
> entry)

Again it depends on use-case and what your data looks like. I can see
that all of the above suggested designs would work but pick the one
that solves the problem best. For example if the application always
manages these event streams by accessing events by day having a "day"
node would be a good idea. Also have a look at the timeline utility
(http://components.neo4j.org/index-util/apidocs/org/neo4j/util/timeline/TimelineIndex.html).

> -          Has the fact that the node id is an "int" rather than a "long"
> been an issue in any implementations?  Are node id's reused if deleted (I
> suspect not, but just wanted to confirm).

Node and relationship ids are reused. Currently they will not be
reused within the same "session" so you have to do a clean shutdown
then start a new NeoService for them to be reused (this may change to
reuse in same session for later release). Node (and relationship) ids
are exposed through the API as long so think of them as a long. You
are however correct that they are currently stored in a 32-bit format
but this will change as machines get more powerful (right now we are
discussing adding 1-3 bits going from ~4B to 8B,16B and 32B depending
on store files).

>
> -          Any whitepaper/best practices for high availability/load-balanced
> scenarios?  We were considering using a message queue to send "deltas"
> around between nodes or something similar.

We are currently working on our "Neo4j level" HA solution (master
slave replication but can write to slaves). Using a message queue to
send "domain layer deltas" around is how we have done this
successfully in the past so while you wait for the real HA solution I
would say thats the way to go.

> -          We'll be hosting Neo inside a servlet engine.  Plan was to start
> up Neo within the init method of an autoloading servlet.  Any other
> recommendations/suggestions?  Best practice for ensuring a clean shutdown?
>

Make sure you can redirect a new request (so it will not start a
transaction) once you intend to invoke NeoService.shutdown. Then wait
for all the current request to complete to ensure a clean shutdown. We
are hoping to fix this problem by making shutdown block new
transactions, rollback any running transactions and wait for
transactions that are in the committing state.

> -          Anyone used any kind of intermediate index or other approach to
> bridge multiple Neo instances?

Not sure I understand what you mean, could you explain some more?

>
> -          Any GUI tools for viewing/navigating the graph structure?  We are
> prototyping one in Adobe Flex, curious if there are others.
>

We have Neoclipse http://wiki.neo4j.org/content/Neoclipse (works well
on tiny graphs) and Shell http://wiki.neo4j.org/content/Shell (command
line but can be used on large graphs that are running in production).
We are in need of a graphical visualization tool that scales so let us
know how Adobe Flex works out.

> Comments/observations:
>
> -          I love the fact that you can delete nodes and relationships from
> inside an iterator.  I always hated the way I had to separately maintain a
> list of "things to be deleted" when traversing XML DOMs, for example.  Nice
> capability!
>
> -          Neo seems FAST!
>
> -          It's a bit of a major mindset change, but once the lightbulb goes
> on, the potential seems limitless!

Always great to hear stuff like this!

>
>
> Thanks in advance for guidance.

You're welcome.

Regards,
-Johan
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to