3 ms·

> Nobody is using joins at scale and every large company that started their scaling journey in a SQL database started by performing multiple queries on a distri

> Nobody is using joins at scale and every large company that started their scaling journey in a SQL database started by performing multiple queries on a distributed database. I've used joins "at scale" in multiple jobs in (conventional relational) databases up to a few TB with tens of thousands of transactions per second and never experienced any performance problem that was the result of a join, unless you count cross joins with no filters. I have never seen an instance where doing a join was faster in code and I don't see how it could be except perhaps in some unusual edge cases. I'm sure things change at Google or Facebook scale, but almost nobody is Google or Facebook scale. I've never understood the "joins are slow" meme or where it came from. I'm also having difficulty understanding how writing analytic SQL queries is slower than writing normal code. Can you go into more detail? In my experience, the "slow" part of writing any analytic query is deciding exactly what you want to know and making sure you understand that the data means what you think it means. Once you have that, the only thing slowing you down is your typing speed, and I don't think a more compact syntax would really make a difference.

189523954 8y ago
>I've never understood the "joins are slow" meme or where it came from. Well SQL databases generally don't support joining across a sharded database, which is usually necessary to scale unless you try to scale vertically with high powered machines and your data fits into memory and so on. They are also obviously slow compared to denormalizing and querying without a join. Then there is the other fact I mentioned that they contain redundant data so if the query you need to pull into code is large enough, it is a lot of data that has to get sent over the network. >I'm also having difficulty understanding how writing analytic SQL queries is slower than writing normal code. Can you go into more detail? Yes. A programming language, combined with a database like mongo or an ORM, allows you to create complex queries much more quickly compared to SQL. You can maybe go into stored procedures and start doing loops and recombining multiple queries in there, but programming languages like javascript etc are typically much nicer than those used in stored procedures. I am talking about queries that require joins, self-joins, sub-queries, multiple types of joins, group bys layered on top of each other and so on. They are horseshit and terrible compared to nice programming languages and maybe using a couple of queries instead of one. >In my experience, the "slow" part of writing any analytic query is deciding exactly what you want to know and making sure you understand that the data means what you think it means. This takes a while, but so does writing the query. My non-programming coworker, while good with SQL, spent entire days trying to write the query to a query that he already knew in concept (as in, he knew what he wanted). So I don't agree with your point that understanding what you need is going to take so much time.
- Amezarak 8y ago
  > Yes. A programming language, combined with a database like mongo or an ORM, allows you to create complex queries much more quickly compared to SQL. You can maybe go into stored procedures and start doing loops and recombining multiple queries in there, but programming languages like javascript etc are typically much nicer than those used in stored procedures. I guess this is where we differ. I've written many SQL queries many hundreds of lines long taking advantage of all kinds of SQL features. I don't see how I could make them "nicer" by writing them in Javascript: SQL has plenty of warts, but well-formatted and organized SQL is hard to beat for expressing exactly what you want without all the cruft associated with how you;re getting it. Once you know what you want, it comes out pretty quick (IME), only your typing speed is the limit. I find you have to think much more carefully about what you're doing in other languages because you have to think more about how to do it without the db abstracting all of that away. IME loops in SQL are a huge code smell - everything should almost always be done using set logic to be clean and performant.
  - 189523954 8y ago
    Yes well it would be ideal if I had code to show you and compare it to the SQL, but all of that is at my old workplace and I will get PTSD if I ever look at it again. I agree that loops in SQL are not great. Loops in programming languages are fine obviously. There are just many more and nicer constructs in a programming language to manipulate data. Maybe you have a root table that is anchoring your query, say a Staff table. The Staff table has a Manager column, which is another row in the Staff table. You then need to do a bunch of aggregate stuff. So in a programming language, you can maybe query the database 3 times, once for the staff you need, and then again for maybe shifts completed and so on. You can then easily put the staff into a dictionary with virtually no code. Then you loop over the non-dictionary staff array, and you have something like: for (var staff in shittyStaff) { processedStaff.add({ manager: staffDic[staff.manager], shiftsCompleted: shifts[staff.id].length, shiftsWithManager: shifts[staff.id].filter(s => s.coworker == staff.manager.id).length }); Or if it is setup with entity framework/c# stuff, it is just: var staff = db.Staff .Include(s => s.Manager) .Include(s => s.Shifts) .Select(s => new { Manager: s.Manager, ShiftsCompleted: s.Shifts.Count(), ShiftsWithManager: s.Shifts.Where(shift => shift.CoWorker == s.Manager).Count() }); Probably a terrible and not particularly complex example because I made it up, but to do that in SQL requires a lot more stuff, a self-join, group by with count etc, etc.
lmm 8y ago
> never experienced any performance problem that was the result of a join, unless you count cross joins with no filters. An unindexed join will have major performance problems, and look exactly like an indexed join. > I have never seen an instance where doing a join was faster in code and I don't see how it could be except perhaps in some unusual edge cases. Faster to do the same thing? No. Easier to see which things are fast and which things are slow? Yes. Also easier to avoid the deadlocks that traditional databases' overzealous application of ACID can easily lead to. > Can you go into more detail? In my experience, the "slow" part of writing any analytic query is deciding exactly what you want to know and making sure you understand that the data means what you think it means. Once you have that, the only thing slowing you down is your typing speed, and I don't think a more compact syntax would really make a difference. I find the pseudo-English syntax of SQL is always very hard to follow - it slips into a kind of uncanny valley - the grammar of what goes where can be backwards from what I'd expect. Tooling is also rather limited compared to a "real" programming language. Just basic things like unit testing your queries are much harder than they should be.
- collyw 8y ago
  >An unindexed join will have major performance problems, and look exactly like an indexed join. Then add an index. Its not exactly difficult in a database. Using a database without indexes is kind of stupid. Why would you do that? And personally I find SQL to be one of the easiest languages to read. I agree that it's kind of back to front in many ways, but its way easier than trying to work out what happening in some nested loops that someone else has written.
  - lmm 8y ago
    > Then add an index. Then you're adding work to your writes, and your database will block your live write transactions until the corresponding index updates are done. > Its not exactly difficult in a database. Using a database without indexes is kind of stupid. Why would you do that? You wouldn't intend to, but you might do it by accident. The failure modes can be pretty bad, since an SQL database will take whatever nonsense query you give it and try to run it, even if doing so impacts your live operations. Whereas in many NoSQL systems if you try to use an index that doesn't exist it'll fail fast.

189523954 8y ago

>I've never understood the "joins are slow" meme or where it came from. Well SQL databases generally don't support joining across a sharded database, which is usually necessary to scale unless you try to scale vertically with high powered machines and your data fits into memory and so on. They are also obviously slow compared to denormalizing and querying without a join. Then there is the other fact I mentioned that they contain redundant data so if the query you need to pull into code is large enough, it is a lot of data that has to get sent over the network. >I'm also having difficulty understanding how writing analytic SQL queries is slower than writing normal code. Can you go into more detail? Yes. A programming language, combined with a database like mongo or an ORM, allows you to create complex queries much more quickly compared to SQL. You can maybe go into stored procedures and start doing loops and recombining multiple queries in there, but programming languages like javascript etc are typically much nicer than those used in stored procedures. I am talking about queries that require joins, self-joins, sub-queries, multiple types of joins, group bys layered on top of each other and so on. They are horseshit and terrible compared to nice programming languages and maybe using a couple of queries instead of one. >In my experience, the "slow" part of writing any analytic query is deciding exactly what you want to know and making sure you understand that the data means what you think it means. This takes a while, but so does writing the query. My non-programming coworker, while good with SQL, spent entire days trying to write the query to a query that he already knew in concept (as in, he knew what he wanted). So I don't agree with your point that understanding what you need is going to take so much time.

Amezarak 8y ago
> Yes. A programming language, combined with a database like mongo or an ORM, allows you to create complex queries much more quickly compared to SQL. You can maybe go into stored procedures and start doing loops and recombining multiple queries in there, but programming languages like javascript etc are typically much nicer than those used in stored procedures. I guess this is where we differ. I've written many SQL queries many hundreds of lines long taking advantage of all kinds of SQL features. I don't see how I could make them "nicer" by writing them in Javascript: SQL has plenty of warts, but well-formatted and organized SQL is hard to beat for expressing exactly what you want without all the cruft associated with how you;re getting it. Once you know what you want, it comes out pretty quick (IME), only your typing speed is the limit. I find you have to think much more carefully about what you're doing in other languages because you have to think more about how to do it without the db abstracting all of that away. IME loops in SQL are a huge code smell - everything should almost always be done using set logic to be clean and performant.
- 189523954 8y ago
  Yes well it would be ideal if I had code to show you and compare it to the SQL, but all of that is at my old workplace and I will get PTSD if I ever look at it again. I agree that loops in SQL are not great. Loops in programming languages are fine obviously. There are just many more and nicer constructs in a programming language to manipulate data. Maybe you have a root table that is anchoring your query, say a Staff table. The Staff table has a Manager column, which is another row in the Staff table. You then need to do a bunch of aggregate stuff. So in a programming language, you can maybe query the database 3 times, once for the staff you need, and then again for maybe shifts completed and so on. You can then easily put the staff into a dictionary with virtually no code. Then you loop over the non-dictionary staff array, and you have something like: for (var staff in shittyStaff) { processedStaff.add({ manager: staffDic[staff.manager], shiftsCompleted: shifts[staff.id].length, shiftsWithManager: shifts[staff.id].filter(s => s.coworker == staff.manager.id).length }); Or if it is setup with entity framework/c# stuff, it is just: var staff = db.Staff .Include(s => s.Manager) .Include(s => s.Shifts) .Select(s => new { Manager: s.Manager, ShiftsCompleted: s.Shifts.Count(), ShiftsWithManager: s.Shifts.Where(shift => shift.CoWorker == s.Manager).Count() }); Probably a terrible and not particularly complex example because I made it up, but to do that in SQL requires a lot more stuff, a self-join, group by with count etc, etc.

lmm 8y ago

> never experienced any performance problem that was the result of a join, unless you count cross joins with no filters. An unindexed join will have major performance problems, and look exactly like an indexed join. > I have never seen an instance where doing a join was faster in code and I don't see how it could be except perhaps in some unusual edge cases. Faster to do the same thing? No. Easier to see which things are fast and which things are slow? Yes. Also easier to avoid the deadlocks that traditional databases' overzealous application of ACID can easily lead to. > Can you go into more detail? In my experience, the "slow" part of writing any analytic query is deciding exactly what you want to know and making sure you understand that the data means what you think it means. Once you have that, the only thing slowing you down is your typing speed, and I don't think a more compact syntax would really make a difference. I find the pseudo-English syntax of SQL is always very hard to follow - it slips into a kind of uncanny valley - the grammar of what goes where can be backwards from what I'd expect. Tooling is also rather limited compared to a "real" programming language. Just basic things like unit testing your queries are much harder than they should be.

collyw 8y ago
>An unindexed join will have major performance problems, and look exactly like an indexed join. Then add an index. Its not exactly difficult in a database. Using a database without indexes is kind of stupid. Why would you do that? And personally I find SQL to be one of the easiest languages to read. I agree that it's kind of back to front in many ways, but its way easier than trying to work out what happening in some nested loops that someone else has written.
- lmm 8y ago
  > Then add an index. Then you're adding work to your writes, and your database will block your live write transactions until the corresponding index updates are done. > Its not exactly difficult in a database. Using a database without indexes is kind of stupid. Why would you do that? You wouldn't intend to, but you might do it by accident. The failure modes can be pretty bad, since an SQL database will take whatever nonsense query you give it and try to run it, even if doing so impacts your live operations. Whereas in many NoSQL systems if you try to use an index that doesn't exist it'll fail fast.