7 ms·
I use cypher most days over the last few years and I like it because it's a complete level of abstraction over the database. In gremlin and this new nGQL, the
by motohagiography 7y ago
I use cypher most days over the last few years and I like it because it's a complete level of abstraction over the database.
In gremlin and this new nGQL, the whole notion of "INSERT," implies that the graph is just a representation over top of a relational db, and power users should understand RDBMS concepts articulated in SQL queries first with this novel and cute graph thingy after for managers. It's like asking Excel users to understand and care about pointer arithmetic.
Gremlin leverages some peoples mental sunk costs in SQL, where cypher is very verbose, but lets me reason purely about my graph model without hacking over the implementation. The others aren't bad, but the people who will be using graphs won't be DBAs.
In this sense, cypher/Neo4j isn't a competitor to noSQL and rdbms products, it's a competitor to spreadsheets, where the majority of people actually get work done themselves, instead of specifying it and having others engineer it.
- EGreg 7y agoI was really attracted to graph databases mainly for the ability to do joins in effectively constant time rather than O(log N) time. But then I realized that sharding and localizing data can accomplish roughly the same thing. Also the graph database doesn’t have to duplicate data so much for joins, saving on memory. If you are going to have a huge dataset, build your data as RDMBS first and then make a cache in a graph database. I say this only because graph databases are not mainstream yet.
- karatestomp 7y agoI came to exactly the same conclusion after having Neo4j pushed on a project by managers who'd been sold by their "it's great for everything!" marketing. At least as of ~2 years ago, no, it wasn't. Fine for a narrow set of query types for data of a very specific kind of shape (dense graph) that you don't care about much and can re-generate if it gets screwed up. Unsuitable as a "database of record" (poor integrity enforcement, transactions very limited) and quite bad (slow, awkward) at a lot of things one might want to do with it, even kinda "graphy" things, that didn't happen to fall in its strengths. Memory hog, too. Seems like most graph databases, though possibly better at some of those things, will tend to be similar, since they have to make trade offs to achieve notably good performance at whatever they're benchmarking to put on their marketing pages. Cypher was really nice, though.
- pphysch 7y agoSpot on with my experiences. I had a great honeymoon period with Cypher via Neo4j but then the cracks quickly started to show. It was a valuable learning experience but I find myself moving back toward SQLy and JSONy things for production models.
- frant-hartm 7y agoWhat version did you use? What you are describing sounds like Neo4j from around 6 years ago, not today.
- karatestomp 7y agoAbout two years ago. Whatever was current then. We had a paid license too because this client was all-in on N4J. They had their own internal champion who'd set himself up as the "Neo4j expert" and got them to send him to conferences and hang out on phone calls and try to fix the fires he was partially responsible for but didn't get blamed for. All their projects had serious issues resulting from their insistence on a particular stack, which had basically nothing really capable of protecting data consistency at any point. We had to fight for TypeScript (vs. their prefered vanilla Javascript) to gain a tiny semblance of sanity, productivity, and stability in that environment. Transactions in N4j couldn't handle modifying one entity [edit:the schema of one entity type, I mean] while updating another, which was pretty limiting (say, you want to do safe Rails-migrations-style version bumps in the DB in the same transaction as your modifications, so they can't get out of sync). Constraints capabilities and data types were very limited. Perf if you stepped off the Golden Path, which was easy to do by accident with something that looked boring and normal, was mediocre at best for our use case (smallish sparse sub-graph fetching, mostly) [EDIT] meanwhile, all the official material from N4J was doing its MongoDBest to sell itself as 100% suitable for production for 100% of use cases, because of course it was. Look anywhere else and you got a very different, more accurate story.
- staticautomatic 7y agoI posted a thread recently about my struggle to evaluate neo against multi model alternatives but have not gotten any useful replies. Any chance I could pick your brain? Email in my profile.