Ticket #403 (closed Feature Request: wontfix)
Switch to NEO4J Enterprise
| Reported by: | joern | Owned by: | jri |
|---|---|---|---|
| Priority: | Major | Milestone: | |
| Component: | DeepaMehta Karaf Distribution | Version: | 4.0.14 |
| Keywords: | Cc: | ||
| Complexity: | 3 | Area: | Runtime Environment |
| Module: |
Description
This would provide cool features like Online Backup. Should be possible free of charge because DM is open source.
Change History
comment:2 Changed 12 years ago by dgf
- Type changed from Enhancement to Feature Request
- Component changed from DeepaMehta Standard Distribution to DeepaMehta Karaf Distribution
- Area set to Runtime Environment
We should rather rely on an abstraction like blueprints API instead of implementing more specialized connections. So the user can choose between embedded or external and small or enterprise.
IMO we need this feature only for Karaf, in the standard distribution embedding Neo4j fits better.
comment:3 Changed 12 years ago by jri
As far as I know we're not depending on Neo4j Enterprise in order to do online backup. Also keep in mind that the DM Standard Distribution doesn't deploy the Neo4j REST server but the embedded version. This is for the sake of simplified setup for end users.
Regarding Blueprints API as the main storage interface for DM I'm hesitant as well. I'm wondering weather the Blueprint abstraction fits the DM model well, especially the MehtaGraph? where edges can be players in edges, and furthermore DM's various index modes (e.g. cross-field fulltext indexing).
But the main reason for being hesitant with Blueprints is that I'm not fully sure anymore a graph database is the suitable DB for DM. This new view arised from the current work of rewriting DM's storage layer. With the new storage layer we make practical no use of the central graph DB feature -- traversal -- anymore but rely solely on Lucene indexes. This feels more like a key-value store or a columnar database now. For me, this suggests we should investigate and re-discuss the DB question on a rather fundamental level.
From my current point of view the new DeepaMehtaStorage? abstraction is the suitable main storage interface for DM. Of course there can be a Blueprints-based implementation of that interface but I would not do it the other way around for the reasons mentioned above.
comment:4 Changed 12 years ago by joern
For future use-cases, high availability will be mandatory (e.g. 1000 students using DM for courses). I thinking about thinks like clustered hosting with Neo4J. To do such things, the enterprise edition is necessary. Also there are backuptools which rely one the onlinebackup features only available with Neo4J Enterprise. One could simple include the POM of the enterprise edition and adapt settings?
comment:5 Changed 11 years ago by jri
From my point of view there is no need to act further on this issue.
Should we close this ticket?
More Info: http://www.neo4j.org/learn/licensing