Thanks a lot for your answers,
First, let me just comment on you answers.
1. Great, thats what a thought.
2. About XA transactions, I do not want to get into anything messy... but
"normal" spring transaction integration looked great!
Perhaps its time to remove this
http://wiki.neo4j.org/content/Spring_And_Neo?
3. There is no legacy integration at all at database level.
I actually proposed Neo in the beginning of the project since it seemed like a
perfect fit,
but after some (policy, policy) discussion we decided to use a database and
pray that
we would not get into trouble.
Unfortunately, the biggest problem is not technical, it´s policy. People still
feel safe
when using a relational database even if it that solution really does not fit
properly.
My project leader actually told me face to face today that this is a fact.
The idea with only replacing a part of the system with neo, was to sneak in in
but still
keeping the sql database => everybody happy.
If would really, really appreciate any good arguments for replacing Neo with an
sql database, not from a performance perspective or developer perspective
(not needed...). Any arguments for not switching is also appreciated.
Important concerns:
- Replication (multiple machines running neo) (HA requirements are not explicit
yet)
- Daily operations (operation personnel know their Sql database)
- Backup and restore
- etc
Best regards
/johan
2008-11-25 Emil Eifrem wrote:
Hi Johan,
>
>See comments inline.
>
>On Tue, Nov 25, 2008 at 10:45 AM, wrote:
>> Our problem (as you may have guessed) is that we have performance issues
>> when doing
>> large changes in the topology (for minor changes it works ok), like deletion
>> of large groups. The topology does not have to be that large either...
>> Removing a group with 300 connected units (300x300 relationships) is enough
>> to cause improper response times. Since it is a many2many relationship we
>> have to resolve and remove all relationships before removal of any units and
>> this is what is time consuming.
>>
>> Question:
>> 1. I was hoping that neo could help us speed up things here
>
>This sounds very likely. One guy I talked to summed up Neo4j as
>"solving the many-to-many problem." From your description of the
>domain it seems like a perfect fit.
>
>I obviously need to know more numbers to say for sure but it sounds
>like we'll be able to do at least sub-second times on all those
>operations.
>
>> 2. I would like to use neo for the topology part only. Simply (well.. not
>> that simply perhaps) switch our TopologyRepository (impl today as
>> JpaTopologyRepository) to a
>> NeoTopologyRepository. I know that transactions are supported, but is it
>> possible to use it with a jta transactionmanager since we will end up with
>> two different datasources if we keep the rest of the system in the
>> relational database? We are using spring.
>> I found this, what is the status?
>> http://wiki.neo4j.org/content/Spring_And_Neo
>
>Well, Johan should fill in with the latest details here, but we
>certainly support both participating in and directing a 2PC
>environment. I.e. both registering Neo4j as an XA resource to another
>transaction manager or setting up our transaction manager to be in
>charge. But IIRC, it currently requires a pretty messy config that we
>need to shape up to expose it properly.
>
>> 3. Or is it better(or easier?) to simply use Neo for everything?
>
>Do you have any legacy integration against your existing SQL database?
>Do you have reporting tools (like Crystal Reports or Jasper or
>something like that) that's already setup against it?
>
>If not, it'll certainly be easier and very doable to just use Neo4j to
>persist the entire domain.
>
>Cheers,
>
>--
>Emil Eifrém, CEO [EMAIL PROTECTED]
>Neo Technology, www.neotechnology.com
>Cell: +46 733 462 271 | US: 206 403 8808
>_______________________________________________
>Neo mailing list
>User@lists.neo4j.org
>https://lists.neo4j.org/mailman/listinfo/user
>
>
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
