[orientdb] Re: OrientDB vs Neo4j performance using graphdb-benchmarks project
Neo4j 2.2.0 seems to have significant improvements in certain areas (specially in execution plans -- as well as memory management). I don't know what is happening in this group, but I definitely have a hard time finding resources on OrientDB. The engine is much more flexible for my use cases, but the query interface does not behave, and I have difficult finding basic help. On Saturday, April 25, 2015 at 6:07:42 PM UTC-4, George Niculae wrote: vineri, 24 aprilie 2015, 19:11:18 UTC+2, retrography a scris: What about Neo4j 2.2.0? Well the scope of this exercise was to figure out if graphdb-benchmarks project is the right tool for comparing them, additional effort is required for upgrading Neo4j library as there were changes in API. If it proves it can be used then I'll update Neo4j library and contribute changes upstream. Unfortunately seems like there are not too many people (actually no one considering feedback I got so far) on this mailing list using it, so probably I have to look for something else Buy the way, the scores you are citing for Neo4j seem to be way above what is reported on the project's website: Right, but pretty sure they depend on system used for testing - mind that also OrientDB scores are higher than what is reported there. George ENQW-FN1.87*0.56*0.95AMQW-FN6.473.50*1.85*YTQW-FN20.719.34*4.51*LJQW-FN 213.41303.09*47.07*ENQW-FA3.780.71*0.16*AMQW-FA13.772.30*0.36*YTQW-FA 42.826.15*1.46*LJQW-FA460.25518.12*16.53* -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[orientdb] Re: OrientDB vs Neo4j performance using graphdb-benchmarks project
vineri, 24 aprilie 2015, 19:11:18 UTC+2, retrography a scris: What about Neo4j 2.2.0? Well the scope of this exercise was to figure out if graphdb-benchmarks project is the right tool for comparing them, additional effort is required for upgrading Neo4j library as there were changes in API. If it proves it can be used then I'll update Neo4j library and contribute changes upstream. Unfortunately seems like there are not too many people (actually no one considering feedback I got so far) on this mailing list using it, so probably I have to look for something else Buy the way, the scores you are citing for Neo4j seem to be way above what is reported on the project's website: Right, but pretty sure they depend on system used for testing - mind that also OrientDB scores are higher than what is reported there. George ENQW-FN1.87*0.56*0.95AMQW-FN6.473.50*1.85*YTQW-FN20.719.34*4.51*LJQW-FN 213.41303.09*47.07*ENQW-FA3.780.71*0.16*AMQW-FA13.772.30*0.36*YTQW-FA42.82 6.15*1.46*LJQW-FA460.25518.12*16.53* -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] Re: OrientDB and neo4J
Hi Erich, On 13 August 2014 22:52, Erich Heine sophac...@gmail.com wrote: I ended up choosing OrientDB because: * Part of my data model was very painful with a traditional SQL database, whereas graphs work nicely. * Parts of my data model very much like the Document DB aspects of Orient - especially the EMBEDDED* types. * Licensing is good * The various query/fetching methods - SQL dialect, gremlin, direct object load, etc, map to various ways I think about accessing my data. * The times I want to enforce schema, I can, which gives me a certain level of type-safe comfort I enjoy. The reason I chose against Neo4j was mostly licensing, the above is just a nice benefit. Thanks for the feedback ;-) A couple of Orient cons from my POV: * When working in a non-jvm language, it somewhat painful to use the binary or http interfaces. The http interface feels a bit inconsitent, and arbitrary when it comes to return values, and what can and cannot be done, rather than a full API. e.g. I use python, and interfacing with full features is just frustrating sometimes (and bulbflow/rexster don't really allow me to use everything fully) If you have any specific issue to report against API calls, we can work on it. * Some things are non-intuitive in the Orient way of doing things, and it's taken a lot of experimenting to get things done sometimes. Being a small community still, not every question I have is answered by a simple google search. This part needs a bigger re-work, mostly by using a new SQL Engine more compliant, more strict and with a better reporting in case of errors. Then we need to improve documentation, this is something everybody ask for. Lvc@ HTH On Thursday, January 5, 2012 11:56:14 PM UTC-6, Luanne Misquitta wrote: Hi everyone, Did any of you consider using neo4J and why did you pick OrientDB over it? Thanks Luanne -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] Re: OrientDB and neo4J
Hi Luca, On Thursday, August 14, 2014 2:26:13 AM UTC-5, Lvc@ wrote: snip A couple of Orient cons from my POV: * When working in a non-jvm language, it somewhat painful to use the binary or http interfaces. The http interface feels a bit inconsitent, and arbitrary when it comes to return values, and what can and cannot be done, rather than a full API. e.g. I use python, and interfacing with full features is just frustrating sometimes (and bulbflow/rexster don't really allow me to use everything fully) If you have any specific issue to report against API calls, we can work on it. I have some notes I've made as I work on my OrientDB related project. I plan on going through them thoroughly in the next couple of weeks and writing up something about it. Some of it is just learning curve related frustration on my part - this happens with any new (for me) technology, but some of it probably should be mentioned in the form of suggestions or feature requests. Regards, Erich -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] Re: OrientDB and neo4J
* Some things are non-intuitive in the Orient way of doing things, and it's taken a lot of experimenting to get things done sometimes. Being a small community still, not every question I have is answered by a simple google search. This part needs a bigger re-work, mostly by using a new SQL Engine more compliant, more strict and with a better reporting in case of errors. Then we need to improve documentation, this is something everybody ask for. Lvc@ Hi Luca, I'd like to add my voice to the need for improved documentation. I really like OrientDB in our project, but I and my team have concerns about documentation and stability that may cause me to spend scarce staff time in evaluating Neo4J or other DBs as alternatives. An example of stability concerns was a recent episode using 1.7.7 where we found that a small percentage of edges that we were creating in one of our loaders were only in one direction, could not be traversed in the other direction. We were going to report the problem and provide a code example - but then the problem disappeared and was not reproducible. We are left with a vague fear that the problem would recur and compromise our users data. Its certainly possible that this is our bug in the sense that we may be using the graph or document model incorrectly, but I'm concerned that we were able to provoke a behavior using low-level graph model operations that was 99% successful rather than either working or failing. We apparently ran into some edge case but we have no idea what the cause of the problem was or why it went away. While reading the dialog on this google group, I have been very impressed with your rapid response to bugs and questions. On the other hand, I'm worried that you and your team may be too responsive to requests for features - you have a fundamentally strong product but it can be compromised by spreading your efforts too broadly. (I'm sympathetic to the problem - our project faces the same feature vs. robustness tradeoffs as we come up to our v1.0 release) So I would like to put in a vote for a very solid, well-documented core OrientDB - and a release that we can commit to for a fairly long time if we limit ourselves to that core functionality. From the perspective of the NDEx project, here's a cut at our top priorities for OrientDB: (I understand that some of these issues are currently addressed. I'm enumerating our priorities, not making a list of implicit complaints :-) ) Robust operation of the Graph Model and Document Model Especially the reliability and correctness of stored content, methods for verifying correctness and consistency of database. Documentation and executable Java code examples for Graph and Document Model use Schema management Best practices for efficient queries and inserts Use of transactions Large inserts - when and why to turn off transactions, best practices to be robust without transactions. Best practices for indexing Including Lucene Documentation and code examples for use of OrientDB in embedded vs remote mode Connection pool management Documentation and script examples showing best practices for maintenance of production databases backup and restore strategies for recovery in cases of corrupted data replication migration between DB versions Clear separation of base Graph and Document Model usage documentation from higher level abstractions. we need simplicity, maintainability, and performance. Tinkerpop is cool, but the use of that option and the additional mental and computational overhead should be a very distinct choice. In the future, we will also be interested in scalabilty, distributed servers. But these are only of concern if the our single processor server is solid. Orient is of course a for-profit company. If some utilities / support packages aimed at production databases were part of the enterprise edition or support contracts, I'd be happy to hear more about it. Dexter Dexter Pratt Director, NDEx project Ideker Lab UCSD / Cytoscape Consortium dexterpratt@gmail.com - dex...@ndexbio.org www.ndexbio.org -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] Re: OrientDB and neo4J
Hi Dexter, Hi Luca, I’d like to add my voice to the need for improved documentation. An example of stability concerns was a recent episode using 1.7.7 where we found that a *small percentage of edges* that we were creating in one of our loaders were only in one direction, could not be traversed in the other direction. We were going to report the problem and provide a code example - *but then the problem disappeared and was not reproducible*. We are left with a vague fear that the problem would recur and compromise our users data. Its certainly possible that this is our bug in the sense that we may be using the graph or document model incorrectly, but I’m concerned that we were able to provoke a behavior using low-level graph model operations that was 99% successful rather than either working or failing. We apparently ran into some edge case but we have no idea what the cause of the problem was or why it went away. We usually see such problems in 2 cases: - Graph and Document API are used together - Operations against Graph are non transactional If you can find that the problem is in OrientDB, please let us know to fix it asap. While reading the dialog on this google group, I have been very impressed with your rapid response to bugs and questions. On the other hand, I’m worried that you and your team may be too responsive to requests for features - you have a fundamentally strong product but it can be compromised by spreading your efforts too broadly. (I’m sympathetic to the problem - our project faces the same feature vs. robustness tradeoffs as we come up to our v1.0 release) So I would like to put in a vote for a very solid, well-documented core OrientDB - and a release that we can commit to for a fairly long time if we limit ourselves to that core functionality. This is what most of the users asked us, and this is the reason why we're working hard to provide an always more efficient, fast and reliable engine with OrientDB 2.0. We've also started to rewrite our SQL engine to be more strict avoiding weird corner cases with some syntax. This will be ready in 2.1. All the last new components are configured as external plugins. Take a look at: - OrientDB-Lucene (https://github.com/orientechnologies/orientdb-lucene) and - OrientDB-ETL (https://github.com/orientechnologies/orientdb-etl/wiki) From the perspective of the NDEx project, here’s a cut at our top priorities for OrientDB: *(I understand that some of these issues are currently addressed. I’m enumerating our priorities, not making a list of implicit complaints :-) )* - Robust operation of the Graph Model and Document Model - Especially the reliability and correctness of stored content, methods for verifying correctness and consistency of database. - Documentation and executable Java code examples for Graph and Document Model use - Schema management - Best practices for efficient queries and inserts - Use of transactions - Large inserts - when and why to turn off transactions, best practices to be robust without transactions. - Best practices for indexing - Including Lucene - Documentation and code examples for use of OrientDB in embedded vs remote mode - Connection pool management - Documentation and script examples showing best practices for maintenance of production databases - backup and restore - strategies for recovery in cases of corrupted data - replication - migration between DB versions - Clear separation of base Graph and Document Model usage documentation from higher level abstractions. - we need simplicity, maintainability, and performance. - Tinkerpop is cool, but the use of that option and the additional mental and computational overhead should be a very distinct choice. Thanks for the list! Improving the documentation is on our todo-list, any suggestions like yours is welcome. In the future, we will also be interested in scalabilty, distributed servers. But these are only of concern if the our single processor server is solid. Orient is of course a for-profit company. If some utilities / support packages aimed at production databases were part of the enterprise edition or support contracts, I’d be happy to hear more about it. OrientDB is an Open Source project, so it's non-profit. But Orient Technologies was created to give professional support to the Open product. We have two support plans: Development and Production. Take a look at: http://www.orientechnologies.com/support/. With both the supports you'd have a private channel with OrientDB committers to help your team to fix problems and to validate the way OrientDB has been used. Lvc@ Dexter Dexter Pratt Director, NDEx project Ideker Lab UCSD / Cytoscape Consortium dexterpratt.bio@g depr...@ucsd.edumail.com - dex...@ndexbio.org www.ndexbio.org
Re: [orientdb] Re: OrientDB and neo4J
Thanks for the prompt and thoughtful response, comments below... - Dexter Hi Dexter, Hi Luca, I'd like to add my voice to the need for improved documentation. An example of stability concerns was a recent episode using 1.7.7 where we found that a small percentage of edges that we were creating in one of our loaders were only in one direction, could not be traversed in the other direction. We were going to report the problem and provide a code example - but then the problem disappeared and was not reproducible. We are left with a vague fear that the problem would recur and compromise our users data. Its certainly possible that this is our bug in the sense that we may be using the graph or document model incorrectly, but I'm concerned that we were able to provoke a behavior using low-level graph model operations that was 99% successful rather than either working or failing. We apparently ran into some edge case but we have no idea what the cause of the problem was or why it went away. We usually see such problems in 2 cases: - Graph and Document API are used together This is an excellent insight. I'll have to review with my team to see if we might have done this, but this is the kind of roadmap / best practices documentation that would be wonderful to make more prominent. I'll go back and see if I can find this in the documentation, but your advice raises the following questions: Is it *always* a bad idea to mix the two models? Or just within one transaction? What about cases where different parts of a multi module application use the same DB? Is it only bad in the context of writes? Or are queries problematic? - Operations against Graph are non transactional If you can find that the problem is in OrientDB, please let us know to fix it asap. Thanks, as I said before, we appreciate your responsiveness and obvious hard work on this system While reading the dialog on this google group, I have been very impressed with your rapid response to bugs and questions. On the other hand, I'm worried that you and your team may be too responsive to requests for features - you have a fundamentally strong product but it can be compromised by spreading your efforts too broadly. (I'm sympathetic to the problem - our project faces the same feature vs. robustness tradeoffs as we come up to our v1.0 release) So I would like to put in a vote for a very solid, well-documented core OrientDB - and a release that we can commit to for a fairly long time if we limit ourselves to that core functionality. This is what most of the users asked us, and this is the reason why we're working hard to provide an always more efficient, fast and reliable engine with OrientDB 2.0. We've also started to rewrite our SQL engine to be more strict avoiding weird corner cases with some syntax. This will be ready in 2.1. Great, I'm very happy to hear that 2.0 is focused on reliability stability. All the last new components are configured as external plugins. Take a look at: - OrientDB-Lucene (https://github.com/orientechnologies/orientdb-lucene) and - OrientDB-ETL (https://github.com/orientechnologies/orientdb-etl/wiki) More good news - we will start using the lucene plugin shortly From the perspective of the NDEx project, here's a cut at our top priorities for OrientDB: (I understand that some of these issues are currently addressed. I'm enumerating our priorities, not making a list of implicit complaints :-) ) Robust operation of the Graph Model and Document Model Especially the reliability and correctness of stored content, methods for verifying correctness and consistency of database. Documentation and executable Java code examples for Graph and Document Model use Schema management Best practices for efficient queries and inserts Use of transactions Large inserts - when and why to turn off transactions, best practices to be robust without transactions. Best practices for indexing Including Lucene Documentation and code examples for use of OrientDB in embedded vs remote mode Connection pool management Documentation and script examples showing best practices for maintenance of production databases backup and restore strategies for recovery in cases of corrupted data replication migration between DB versions Clear separation of base Graph and Document Model usage documentation from higher level abstractions. we need simplicity, maintainability, and performance. Tinkerpop is cool, but the use of that option and the additional mental and computational overhead should be a very distinct choice. Thanks for the list! Improving the documentation is on our todo-list, any suggestions like yours is welcome. In the future, we will also be interested in scalabilty, distributed servers. But these are only of concern if the our single processor server is solid. Orient is of course a for-profit
Re: [orientdb] Re: OrientDB and neo4J
This is an old post, but always actual. We've published a page with a comparison between two products by also collecting the feedback of users that worked with both: http://www.orientechnologies.com/orientdb-vs-neo4j/ Lvc@ On Wednesday, 11 January 2012 18:51:09 UTC+1, bayoda wrote: *absolute pro: * Licence: Apache 2.0 Some Marketing from Luca :-) Speedy problem solution Speedy BugFixes (that's a must!) scaleable (as we found out) speed (raw write speed on Key Value like storage with blobs - nearly 100mb on SAS2 Discs) index speed *cons actually: * multithread capabilities - h - a little bit problematic - but seems to be in reworking good feature set - but luca is sometimes alone with testing (and real life is not all-times a junit test) so testruns about several 100 GBs of Data sometimes show bottle necks - index / memory pressure and co - but luca tries to fix fast! some pure java functionality (no external libraries) makes more problems - than external libraries would do Linked Hash Map - Problems with Memory for example) and luca doesn't like to embedd external things ;-) but just give it a try - i think orient is getting more mature ... we work with it since 14 months now michael 2012/1/11 TheSweetlink yanosh...@gmail.com I looked at Neo4J and liked the product very much. It has a lot of good momentum. Then I came across OrientDB when researching which graphdb I wanted to use. I ultimately chose OrientDB because of: 1) Licensing. Neo4J clustered setups require a costly license and OrientDB's Apache 2.0 license is extremely liberal. Free for any use. I intend to run multi-master OrientDB with no upfront software cost. 2) SQL syntax + gremlin graph traversal language = VERY powerful ways to explore/grow/analyze your graph. 3) Mixing schema-full/-mixed-/less allows you to arbitrarily add/ remove criteria from your schema. Also a very easy transition for anyone working with SQL-based RDBMS. 4) Luca and OrientDB community respond with lightning speed. Both are good products that have slight nuances between the two. Ex. Neo4J has lots of different algos for analyzing your graph depth or breadth first and much more but OrientDB has SQL syntax + gremlin, also a very powerful way to traverse your graph which can accomplish similar results. If you're in python you might choose the Bulbflow project and abstract yourself from both OrientDB and Neo4J, however this would not allow you to take advantage of many useful Orient Best performance has seemed to go back and forth between the two and it's hard to tell because benchmarks are good but != real life. Switching to OrientDB from a traditional RDBMS made a very noticable difference in performance. Queries with heavy joining took on average 90-100ms. and refactoring my code to use OrientDB dropped those times to 1-10ms. Not everyone will experience a 10 fold performance increase, sometimes less, perhaps many times more depending on your setup. I encourage you to explore both products more and hopefully you'll wind up here if it suits your project best. :) -David On Jan 9, 4:59 am, Stuart Roebuck stuart.roeb...@gmail.com wrote: Personally, I didn't view my need to be for a graph database. I was looking for something light, embeddable, simple and key value based. When I reviewed the options Neo4J appeared to be quite different from the rest in it's graph focus and I made the assumption - rightly or wrongly that the graph handling capabilities might come at a performance cost for those not particularly requiring that functionality. On reflection I think OrientDB is currently quite early in its lifecycle and Neo4J looks like it may have more mature multi-threaded access. -- bayoda.com - Professional Online Backup Solutions for Small and Medium Sized Companies -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[orientdb] Re: OrientDB and neo4J
I ended up choosing OrientDB because: * Part of my data model was very painful with a traditional SQL database, whereas graphs work nicely. * Parts of my data model very much like the Document DB aspects of Orient - especially the EMBEDDED* types. * Licensing is good * The various query/fetching methods - SQL dialect, gremlin, direct object load, etc, map to various ways I think about accessing my data. * The times I want to enforce schema, I can, which gives me a certain level of type-safe comfort I enjoy. The reason I chose against Neo4j was mostly licensing, the above is just a nice benefit. A couple of Orient cons from my POV: * When working in a non-jvm language, it somewhat painful to use the binary or http interfaces. The http interface feels a bit inconsitent, and arbitrary when it comes to return values, and what can and cannot be done, rather than a full API. e.g. I use python, and interfacing with full features is just frustrating sometimes (and bulbflow/rexster don't really allow me to use everything fully) * Some things are non-intuitive in the Orient way of doing things, and it's taken a lot of experimenting to get things done sometimes. Being a small community still, not every question I have is answered by a simple google search. HTH On Thursday, January 5, 2012 11:56:14 PM UTC-6, Luanne Misquitta wrote: Hi everyone, Did any of you consider using neo4J and why did you pick OrientDB over it? Thanks Luanne -- --- You received this message because you are subscribed to the Google Groups OrientDB group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
