Very basic OrientDB/TinkerPop property graph DB questions - java

Thanks in advance for your patience with what may be an array of stupid questions.
I'm re-engineering a legacy enterprise application from the ground up and have down-selected to OrientDB for the underlying graph database. After perusing the OrientDB Google group, the various Wikis, etc I am left more than a little confused about what best practices apply and where to get started. More specifically:
Am I correct in my understanding that with 1.6.4 (or later) I will
need to leverage TinkerPop Blueprints in order to build a graph
database?
If so, am I obliged to use Gremlin or is the extended SQL
provided by OrientDB still available to me?
Should I, ideally, be creating the initial (non-embedded) database programatically through
the TinkerPop APIs or establishing the structure via OrientDB's native console?
Does a blueprints implementation preclude me from
using clusters or classes (can I still use the inheritance structure
built into OrientDB)?
Given that I won't be using an embedded
database, is Rexster obligatory for a TinkerPop-based
implementation?
Has anyone heard wind of a Rexster kibble to provide Cypher support? :D
The majority of my experience to date has been with MS SQL and Neo4J (as is likely implied by my questions).
Cheers,
Jon

I've received a response to this question on the OrientDB Google group. I'm going to call it answered, but would still welcome any input anyone may have.
Cheers,
Jon

Related

Play 2.0 (java): Is MongoDB suitable for hotel booking web app?

I want to implement a hotel booking system with Play framework 2.0 (Java). The app will do hotel booking with no banking transactions (credit card will be provided only as identification method to prevent fraud), user will select the desirable room and date range and the app will make the booking and update the rooms availability.
I am considering mongo over mySQL for performance reasons and also because my models will have translatable fields in a few languages which will have a lot of joins if it is in mySQL.
For Availability check I don't quite figure it out, if it is simpler in mySQL rather than mongo.
Is MongoDB suitable for that kind of web app, or I am in the wrong path?
Two simple statements :
Stick with what you know. If you know plain SQL, go for that.
Premature optimization is the root of all evil. If even before starting your application, you are already thinking of optimization, there is something terribly wrong with your way of working.
You can use mongoDB for this kind of application. I personally have some security concerns when it comes to sensitive data (i.e. credit card infirmation) as deleting the information does not automatically mean that it is unrecoverable.
From wikipedia on MongoDB:
E-commerce. Several sites are using MongoDB as the core of their ecommerce infrastructure (often in combination with an RDBMS for the final order processing and accounting).
There are some very intresting articles on pros an cons on stackoverflow Pros and cons of MongoDB?
If you want to learn a new NoSQL technology by all means go for it, but if you want to play it safe stick to the mysql solution. These applications (booking) often work well with BI solutions/data mining and this fact alone would make a noSql approach a no-go for me.

Graph Database in Java (other than Neo4J)

Greetings,
Is there any open source graph database available other than Neo4J??
NOTE: Why not Neo4J?
Neo4J is opensource, but counts primitives (number of nodes,relationships & properties). If you are using it for commercial use. And does not have any straight forward information of pricing on official website. so there can be potential vendor lock-in (Although I have just started my company, and don't have budget to spent money on software anyway.) so It is out of option.
Regards,
OrientDB (old link) appears to support graph storage in much the same was as Neo4j
As RobV said, if your graphs can be represented in just about any custom format such as RDF or DOT language, you're in luck! Here's various options you have:
RDF: Jena - Considered to be the de facto implementation of RDF for Java, however it has it's oddities such as heavy usage of Iterators.
RDF: Protégé - If you don't use Jena (and even if you would) but would like to use RDF, Protégé is the tool for you. It's basically a really well done ontology editor which makes handling the graph data a breeze. It also uses a plugin hierarchy similar to Eclipse and there's loads of plugins available so you can plugin stuff like OWL ontologies easily.
DOT: GraphViz - Another very popular tool, GraphViz can generate graphs from DOT language. Very powerful, a bit tricky to learn but also potentially all you need.
Of course if it fits your company's profile, you could develop your own and start selling it as a product.
Wikipedia lists some other alternatives: http://en.wikipedia.org/wiki/Graph_database
I suggest you to use Blueprints from tinkerpop, they allow you to use a graphDB of your choice (also from Neo4j and OrientDB). And they also provide an extension to use the db as rdf repository (using Sesame Sail).
Well,
Neo4j is Open Source under the GPLv3 for the Community Edition and AGPL for the Advanced and Enterprise editions.
For more info, please look at http://neo4j.org/licensing-guide/
/peter neubauer, part of the Neo4j team.
If your Graphs could be represented as RDF graphs then you could use Jena since that is entirely free and open source
http://jena.sourceforge.net
Whether that's in any way useful to you depends on why you need a Graph database and what type of Graphs you need to store in it.
Also take a look at ArrangoDB. A lovely multi-model database.
https://www.arangodb.com/
EDIT : Must say that I'm falling more and more in love with Arrango :)
I know, it's been a while, but, today, I was asking myself the same question, and I found OhmDB
Seems to be for lightweight purposes.

Java Embedded Databases Comparison [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I intend to develop a small (Java) application for managing my finances. I believe I need to use an embedded database, but I have no experience regarding this issue. I tried to look at some of the available products, but I can't decide which one would be more suitable for me. H2, HSQLDB, Derby and Berkeley DB seem to be good candidates, but I still don't see how they compare to each other. I appreciate your help comparing them and helping me decide which one to use.
I intend to use Hibernate for my application (unless you would recommend using DBMS-provided API), but I also want to have the ability to edit the database easily using a SQL browsing tool (modifying schema and changing data).
Thank you.
Either
HSQLDB - Used by OpenOffice, tested and stable. It's easy to use. If you want to edit your db-data, you can just open the file and edit the insert statements.
or
H2 - Said to be faster (by the developer, who originally designed hsqldb, too)
Which one you use is up to you, depending how much performance and how much stability you need.
The developer of H2 has put up a nice performance evaluation:
http://www.h2database.com/html/performance.html
I use Apache Derby for pretty much all of my embedded database needs. You can also use Sun's Java DB that is based on Derby but the latest version of Derby is much newer. It supports a lot of options that commercial, native databases support but is much smaller and easier to embed. I've had some database tables with more than a million records with no issues.
I used to use HSQLDB and Hypersonic about 3 years ago. It has some major performance issues at the time and I switch to Derby from it because of those issues. Derby has been solid even when it was in incubator at Apache.
I needed to use Java embedded database in one of my projects and I did lot of research understanding pros and cons of each database. I wrote a blog listing pros and cons of popular embedded java databases (H2, HSQLDB, Derby, ObjectDB, Neo4j, OrientDB), you can have a look at it. I chose H2 as I thought it best suited my requirements.
Link for the blog: http://sayrohan.blogspot.in/2012/12/choosing-light-weight-java-database.html
Hope it helps!
I'd go with H2, the performance is meant to much better than Derby. Read http://www.h2database.com/html/performance.html for more info.
HSQLDB is a good candidate (the fact that it is used in OpenOffice may convinced some of you), but for such a small personnal application, why not using an object database (instead of a classic relationnal database) ?
I used DB4O in one of my projects, and I'm very satisfied with it. Being object-oriented, you don't need the whole Hibernate layer, and can directly insert/update/delete/query objects ! Moreover, you don't need to worry about the schema, you directly work with the objects and DB4O does the rest !
I agree that it may take some time to get used to this new type of database, but check the DB40 tutorial to see how easy it makes working with the DB !
EDIT: As said in the comments, DB4O handles automatically the newer versions of the classes. Moreover, a tool for browsing and updating the database outside of the application is available here : http://code.google.com/p/db4o-om/
Java DB (Sun's distribution of Apache Derby) now ships in JDK 6!
I've been wanted to do something like Jason Cohen and have been thinking this looks like the easiest way being in the JDK distro (which of last week is now a requirement for my app). Or maybe I am just lazy that way.
We use HSQLDB in production as a "no-configuration" option for our application. It allows people to trial without the hassle of setting up a real database.
However we do not support it for normal use. The reasons are several:
Slows down proportionally to the size of the data.
Difficult to access outside of our app (e.g. for custom reports).
Transactions / disk-sync is difficult to get right, so it's easy to lose data.
For at least (2) and (3), there are ways around it but it's difficult; it's much easier to e.g. install MySQL.
neo4j is:
an embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables
I haven't had a chance to try it yet - but it looks very promising. Note this is not an SQL database - your object graph is persisted for you - so it might not be appropriate for your existing app.
HSQLDB may cause problems for large applications, its not quite that stable.
The best I've heard (not first hand experience however) is berkleyDB. But unless you opensource it, it will cost you an arm and a leg to use due to licensing...see this http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html for details.
ps. berkleyDB is not a relational database in case you didnt know.
Good comparison tool can be found here: http://www.jpab.org/All/All/All.html
Notice also the Head to Head DBMS/JPA Comparisons
Most things have been said already, but I can just add that I've used HSQL, Derby and Berkely DB in a few of my pet projects and they all worked just fine. So I don't think it really matters much to be honest. One thing worth mentioning is that HSQL saves itself as a text file with SQL statements which is quite good. Makes it really easy for when you are developing to do tests and setup data quickly. Can also do quick edits if needed. Guess you could easily transfer all that to any database if you ever need to change as well :)
I am a big fan of DB4O for both .Net and Java.
Performance has become much better since the early releases. The licensing model isnt too bad, either. I particularly like the options available for querying your objects. Query by example is very powerful and easy to get used to.
What criteria will you use to evaluate these ? If you don't know yet, then you don't need to decide right now. Try to make your application as database-implementation-agnostic as you can - providing the appropriate wrappers, data access objects etc., and make this decision when you have all the facts to hand and you have to decide.
If you're using relational databases and SQL then the above shouldn't be too hard (using JDBC etc). Make sure you have plenty of surrounding tests so that when you want to switch between databases, you can determine that your application's functionality remains the same.
I ran into the same issue some time ago. I didn't know which database to go for, so my first solution used Derby (or HSQLDB?), and I was later able to switch to HSQLDB (or Derby ? Can't remember which solution worked) once I'd determined where I had issues (relating to performance) and which solution would really work for me.
I have used Derby and i really hate it's data type conversion functions, especially date/time functions. (Number Type)<--> Varchar conversion it's a pain.
So that if you plan use data type conversions in your DB statements consider the use of othe embedded DB, i learn it too late.
Latest Derby Version data type conversions
I personally favor HSQLDB, but mostly because it was the first I tried.
H2 is said to be faster and provides a nicer GUI frontend (which is generic and works with any JDBC driver, by the way).
At least HSQLDB, H2 and Derby provide server modes which is great for development, because you can access the DB with your application and some tool at the same time (which embedded mode usually doesn't allow).
I guess I'm a little late (a lot late;-)) to this post, but I'd like to add Perst, an open source, object-oriented embedded database for Java &.NET. for your consideration. Perst is an open source / dual license embedded database for Java. The distribution is compatible with Google's Android platform, and also includes Perst Lite for Java ME. We've even built an Android benchmark and produced a whitepaper on the subject...you can take a look here: http://www.mcobject.com/index.cfm?fuseaction=download&pageid=581&sectionid=133
All the best,
Chris
If I am correct H2 is from the same guys who wrote HSQLDB. Its a lot better if you trust the benchmarks on their site. Also, there is some notion that sun community jumped too quickly into Derby.
I realize you mentioned SQL browsing, but everything else in your question makes me want to suggest you also consider DB4O, which is a great, simple object DB.

Hibernate Search or Compass

I can't seem to find any recent talk on the choice. Back in '06 there was criticism on Hibernate Search as being incomplete and not being ready to compete with Compass, is it now? Has anyone used both and have some perspective on making the decision.
I am developing a web app in Java in my free time, its just me so I'm looking to cut corners everywhere possible while minimizing the effect on the end product. Having said that the searching capabilities of my project are priority one! I have spent a good deal of time making the database model to back the system. The ability to get the user what they're looking for is what will set my app apart. So, speed is expendable ...obviously to a reasonable degree.
Here are my current thoughts on the technologies for this app, and if you see any glaring newb mistakes be gentle ...I'm an expert at nothing.
DB: PostgreSQL
Platform: Java
Frameworks: Spring, Hibernate, Seam
Obviously, I've chosen all free (as in beer) technologies and ones that as far as I can tell play nice together. So what do you guys think, Compass or Hibernate Search to round things out?
-Nomad311
<Careful. Biased person here: I am the project lead of Hibernate Search and author of Hibernate Search in Action by Manning>
If you are targeting Hibernate as your persistence provider, I think you are better off using Hibernate Search as the integration is very smooth (configuration, entity discovery down the the same APIs and programamtic model).
If you want to index a lot of "stuffs" that are not in your database, then Compass is a better fit.
We are working on Hibernate Search 3.2 at the moment: our road map is here
Hibernate Search is a complete product, and it's based on Lucene, which is one of the fastest open source search engine out here.
As an example, some benchmarks:
http://developers.slashdot.org/story/09/07/06/131243/Open-Source-Search-Engine-Benchmarks
Plus, it's fully integrated with Seam and Hibernate (look at the example in the Seam dist).
I suggest you to be more specific about:
Hibernate Search as being incomplete
I'd like to know in which part it is incomplete.
Compass is no more as of elasticsearch is new one after compass. So I think better to use some stable one. (Possibly Hibernate Search)

Embedded java databases [duplicate]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I intend to develop a small (Java) application for managing my finances. I believe I need to use an embedded database, but I have no experience regarding this issue. I tried to look at some of the available products, but I can't decide which one would be more suitable for me. H2, HSQLDB, Derby and Berkeley DB seem to be good candidates, but I still don't see how they compare to each other. I appreciate your help comparing them and helping me decide which one to use.
I intend to use Hibernate for my application (unless you would recommend using DBMS-provided API), but I also want to have the ability to edit the database easily using a SQL browsing tool (modifying schema and changing data).
Thank you.
Either
HSQLDB - Used by OpenOffice, tested and stable. It's easy to use. If you want to edit your db-data, you can just open the file and edit the insert statements.
or
H2 - Said to be faster (by the developer, who originally designed hsqldb, too)
Which one you use is up to you, depending how much performance and how much stability you need.
The developer of H2 has put up a nice performance evaluation:
http://www.h2database.com/html/performance.html
I use Apache Derby for pretty much all of my embedded database needs. You can also use Sun's Java DB that is based on Derby but the latest version of Derby is much newer. It supports a lot of options that commercial, native databases support but is much smaller and easier to embed. I've had some database tables with more than a million records with no issues.
I used to use HSQLDB and Hypersonic about 3 years ago. It has some major performance issues at the time and I switch to Derby from it because of those issues. Derby has been solid even when it was in incubator at Apache.
I needed to use Java embedded database in one of my projects and I did lot of research understanding pros and cons of each database. I wrote a blog listing pros and cons of popular embedded java databases (H2, HSQLDB, Derby, ObjectDB, Neo4j, OrientDB), you can have a look at it. I chose H2 as I thought it best suited my requirements.
Link for the blog: http://sayrohan.blogspot.in/2012/12/choosing-light-weight-java-database.html
Hope it helps!
I'd go with H2, the performance is meant to much better than Derby. Read http://www.h2database.com/html/performance.html for more info.
HSQLDB is a good candidate (the fact that it is used in OpenOffice may convinced some of you), but for such a small personnal application, why not using an object database (instead of a classic relationnal database) ?
I used DB4O in one of my projects, and I'm very satisfied with it. Being object-oriented, you don't need the whole Hibernate layer, and can directly insert/update/delete/query objects ! Moreover, you don't need to worry about the schema, you directly work with the objects and DB4O does the rest !
I agree that it may take some time to get used to this new type of database, but check the DB40 tutorial to see how easy it makes working with the DB !
EDIT: As said in the comments, DB4O handles automatically the newer versions of the classes. Moreover, a tool for browsing and updating the database outside of the application is available here : http://code.google.com/p/db4o-om/
Java DB (Sun's distribution of Apache Derby) now ships in JDK 6!
I've been wanted to do something like Jason Cohen and have been thinking this looks like the easiest way being in the JDK distro (which of last week is now a requirement for my app). Or maybe I am just lazy that way.
We use HSQLDB in production as a "no-configuration" option for our application. It allows people to trial without the hassle of setting up a real database.
However we do not support it for normal use. The reasons are several:
Slows down proportionally to the size of the data.
Difficult to access outside of our app (e.g. for custom reports).
Transactions / disk-sync is difficult to get right, so it's easy to lose data.
For at least (2) and (3), there are ways around it but it's difficult; it's much easier to e.g. install MySQL.
neo4j is:
an embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables
I haven't had a chance to try it yet - but it looks very promising. Note this is not an SQL database - your object graph is persisted for you - so it might not be appropriate for your existing app.
HSQLDB may cause problems for large applications, its not quite that stable.
The best I've heard (not first hand experience however) is berkleyDB. But unless you opensource it, it will cost you an arm and a leg to use due to licensing...see this http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html for details.
ps. berkleyDB is not a relational database in case you didnt know.
Good comparison tool can be found here: http://www.jpab.org/All/All/All.html
Notice also the Head to Head DBMS/JPA Comparisons
Most things have been said already, but I can just add that I've used HSQL, Derby and Berkely DB in a few of my pet projects and they all worked just fine. So I don't think it really matters much to be honest. One thing worth mentioning is that HSQL saves itself as a text file with SQL statements which is quite good. Makes it really easy for when you are developing to do tests and setup data quickly. Can also do quick edits if needed. Guess you could easily transfer all that to any database if you ever need to change as well :)
I am a big fan of DB4O for both .Net and Java.
Performance has become much better since the early releases. The licensing model isnt too bad, either. I particularly like the options available for querying your objects. Query by example is very powerful and easy to get used to.
What criteria will you use to evaluate these ? If you don't know yet, then you don't need to decide right now. Try to make your application as database-implementation-agnostic as you can - providing the appropriate wrappers, data access objects etc., and make this decision when you have all the facts to hand and you have to decide.
If you're using relational databases and SQL then the above shouldn't be too hard (using JDBC etc). Make sure you have plenty of surrounding tests so that when you want to switch between databases, you can determine that your application's functionality remains the same.
I ran into the same issue some time ago. I didn't know which database to go for, so my first solution used Derby (or HSQLDB?), and I was later able to switch to HSQLDB (or Derby ? Can't remember which solution worked) once I'd determined where I had issues (relating to performance) and which solution would really work for me.
I have used Derby and i really hate it's data type conversion functions, especially date/time functions. (Number Type)<--> Varchar conversion it's a pain.
So that if you plan use data type conversions in your DB statements consider the use of othe embedded DB, i learn it too late.
Latest Derby Version data type conversions
I personally favor HSQLDB, but mostly because it was the first I tried.
H2 is said to be faster and provides a nicer GUI frontend (which is generic and works with any JDBC driver, by the way).
At least HSQLDB, H2 and Derby provide server modes which is great for development, because you can access the DB with your application and some tool at the same time (which embedded mode usually doesn't allow).
I guess I'm a little late (a lot late;-)) to this post, but I'd like to add Perst, an open source, object-oriented embedded database for Java &.NET. for your consideration. Perst is an open source / dual license embedded database for Java. The distribution is compatible with Google's Android platform, and also includes Perst Lite for Java ME. We've even built an Android benchmark and produced a whitepaper on the subject...you can take a look here: http://www.mcobject.com/index.cfm?fuseaction=download&pageid=581&sectionid=133
All the best,
Chris
If I am correct H2 is from the same guys who wrote HSQLDB. Its a lot better if you trust the benchmarks on their site. Also, there is some notion that sun community jumped too quickly into Derby.
I realize you mentioned SQL browsing, but everything else in your question makes me want to suggest you also consider DB4O, which is a great, simple object DB.

Categories

Resources