5 ms·

Elaborate?

AtNightWeCode 5y ago
You elaborate. Graph databases cause expensive writes and cheap reads. Something anybody typically never ever needs. I worked with neo4j and cypher. Same garbage.
- arthurcolle 5y ago
  How large were your datasets?
- boxed 5y ago
  That's a bit much. I have a hobby project that is the graph of all taxons. It is not write heavy, to say the least. (I use mysql for it but still :))
  - AtNightWeCode 5y ago
    Pretty much common knowledge... Doc db -> very cheap reads / very cheap writes Sgl db -> cheap reads / expensive writes Graph db -> cheap reads -> very expensive writes ...for the type of data.
    - spinningslate 5y ago
      If it were as simple as that, then surely the whole world would be using document DBs exclusively. The whole world isn't doing that. So maybe there's more to it. I'm doing some work right now where a graph is a good conceptual fit to the problem space. Writes are much less common than reads. A graph-theoretic approach is a good fit for the queries it needs to support; transitive closure and topological sort for example. Would I use a graph DB for a heavily transactional system like banking? No. Different problem, different requirements, different tech choice. But you seem to be suggesting that there are no problem scenarios where the characteristics of a graph DB are a good fit. That seems naive at best.
      - AtNightWeCode 5y ago
        I am a senior IT architect. I give you the junior card but in the whole, you don't know at all what you are babbling about. ALL databases have tradeoffs.
        spinningslate 5y ago
        Please refrain from personal attacks, it doesn't contribute to the discussion. And it's not consistent with the community guidelines [0]. > ALL databases have tradeoffs That was exactly my point. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
        staticassertion 5y ago
        This is practically parody... I'm the founder of a company building a graph product. I've talked to numerous researchers in the field, read papers on the subject, I've even reviewed PHD candidates thesis for universities. I routinely field offers for consulting explicitly on graph database technology. You haven't said anything of substance and the little you have said has only served to convey your own ignorance on the subject. I've flagged a few of your posts since they break HN rules.
        AtNightWeCode 5y ago
        I worked with graph databases. I also worked with graph like queries in SQL databases a lot for investigating money laundering, flow of payments between users and so on. In single systems that handles billions of Euros. This is easily done in SQL databases and has been since the eighties. In general the only reason to use a graph database as I wrote is when you want to trade expensive writes for cheap ad hoc graph queries. So if you are investigating international money laundering with a lot of different types of relationships between different types of entities and it is significant how the entities are related then SQL can be a poor fit. Or at least, you probably need to model a lot of the relationships as entities and keep on evolving the model with new data. With graph databases you could just enter all the data from different sources as nodes and edges and then perform any query on that data still with good performance. At least in theory. In practice it can be difficult to model graph databases too. The parody is that people suddenly thinks that there is a general need for graph databases.
- bryanrasmussen 5y ago
  >Graph databases cause expensive writes and cheap reads. Something anybody typically never ever needs. I find this statement really surprising, just about every application not dealing with money I've ever been on has had lots more reads than writes and would thereby benefit if the reads were cheap - obviously nobody wants expensive writes but if the benefit is cheap reads and the expensiveness of writes can be dealt with by batching etc. I guess it's an acceptable tradeoff.
  - AtNightWeCode 5y ago
    An Orch like you will never understand the difference between a fruit and berry. You better get off the Internet before you break it all with your hairy feet. Surprising? It is basic db design.
- staticassertion 5y ago
  First of all, "expensive writes and cheap reads" is the common case. Second, nothing about graph databases implies expensive writes and cheap reads.
  - AtNightWeCode 5y ago
    This is the ONLY reason to use a graph databases.... Go a head and down vote instead of learn something. :)
    - staticassertion 5y ago
      That is not the only reason to use a graph database, and you're not exactly making a compelling argument, or a coherent one. I doubt I have much to learn from you on the subject.

Elaborate?

You elaborate. Graph databases cause expensive writes and cheap reads. Something anybody typically never ever needs. I worked with neo4j and cypher. Same garbage.

arthurcolle 5y ago
How large were your datasets?
boxed 5y ago
That's a bit much. I have a hobby project that is the graph of all taxons. It is not write heavy, to say the least. (I use mysql for it but still :))
- AtNightWeCode 5y ago
  Pretty much common knowledge... Doc db -> very cheap reads / very cheap writes Sgl db -> cheap reads / expensive writes Graph db -> cheap reads -> very expensive writes ...for the type of data.
  - spinningslate 5y ago
    If it were as simple as that, then surely the whole world would be using document DBs exclusively. The whole world isn't doing that. So maybe there's more to it. I'm doing some work right now where a graph is a good conceptual fit to the problem space. Writes are much less common than reads. A graph-theoretic approach is a good fit for the queries it needs to support; transitive closure and topological sort for example. Would I use a graph DB for a heavily transactional system like banking? No. Different problem, different requirements, different tech choice. But you seem to be suggesting that there are no problem scenarios where the characteristics of a graph DB are a good fit. That seems naive at best.
    - AtNightWeCode 5y ago
      I am a senior IT architect. I give you the junior card but in the whole, you don't know at all what you are babbling about. ALL databases have tradeoffs.
      - spinningslate 5y ago
        Please refrain from personal attacks, it doesn't contribute to the discussion. And it's not consistent with the community guidelines [0]. > ALL databases have tradeoffs That was exactly my point. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - staticassertion 5y ago
        This is practically parody... I'm the founder of a company building a graph product. I've talked to numerous researchers in the field, read papers on the subject, I've even reviewed PHD candidates thesis for universities. I routinely field offers for consulting explicitly on graph database technology. You haven't said anything of substance and the little you have said has only served to convey your own ignorance on the subject. I've flagged a few of your posts since they break HN rules.
        AtNightWeCode 5y ago
        I worked with graph databases. I also worked with graph like queries in SQL databases a lot for investigating money laundering, flow of payments between users and so on. In single systems that handles billions of Euros. This is easily done in SQL databases and has been since the eighties. In general the only reason to use a graph database as I wrote is when you want to trade expensive writes for cheap ad hoc graph queries. So if you are investigating international money laundering with a lot of different types of relationships between different types of entities and it is significant how the entities are related then SQL can be a poor fit. Or at least, you probably need to model a lot of the relationships as entities and keep on evolving the model with new data. With graph databases you could just enter all the data from different sources as nodes and edges and then perform any query on that data still with good performance. At least in theory. In practice it can be difficult to model graph databases too. The parody is that people suddenly thinks that there is a general need for graph databases.
bryanrasmussen 5y ago
>Graph databases cause expensive writes and cheap reads. Something anybody typically never ever needs. I find this statement really surprising, just about every application not dealing with money I've ever been on has had lots more reads than writes and would thereby benefit if the reads were cheap - obviously nobody wants expensive writes but if the benefit is cheap reads and the expensiveness of writes can be dealt with by batching etc. I guess it's an acceptable tradeoff.
- AtNightWeCode 5y ago
  An Orch like you will never understand the difference between a fruit and berry. You better get off the Internet before you break it all with your hairy feet. Surprising? It is basic db design.
staticassertion 5y ago
First of all, "expensive writes and cheap reads" is the common case. Second, nothing about graph databases implies expensive writes and cheap reads.
- AtNightWeCode 5y ago
  This is the ONLY reason to use a graph databases.... Go a head and down vote instead of learn something. :)
  - staticassertion 5y ago
    That is not the only reason to use a graph database, and you're not exactly making a compelling argument, or a coherent one. I doubt I have much to learn from you on the subject.