Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons after five years of professional programming

siavoshb.tumblr.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Lessons after five years of professional programming

#11

Post by rombdn »

billN wrote: post #8

1. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. I disagree. RDBMS are highly optimized for this kind of operations (including MS SQL…

1. I disagree, on many ERP the DB is totally overloaded and the middleware is sleeping (and/or easier to scale). I think this is the kind of case where the ideal architecture paradigm has to be bent.

Your others points are really informative thanks.

Re: Lessons after five years of professional programming

#12

Post by _glass »

"7. When in doubt, over communicate all concerns with your team." I hope someone would have given and stressed this advice right in the beginning of my career. Every time I communicated for my taste too much, it was overly helpful. I know some individuals were they are really communicating too much, but even daily newsletter of your current state to other people in the process chain seem to work just fine.

Re: Lessons after five years of professional programming

#13

Post by np422 »

markokocic wrote: post #3

First advice is horrible. One shouldn't do in application things that are meant to be done in (relational) database, like ordering, grouping, joining... I guess 66% of my application performance tuning was removing iteration over large result sets in application code with a few lines of SQL. The other 30% being making sure the database is not hit with redundant queries. I have rarely seen the case where minimizing th…

If your performance bottleneck is at the database layer it's a difficult problem to solve, scaling relational databases requires all kinds of witchcraft and magic such as read-only replicas, sharding, result-caching ...

But it is very simple to add another application server and update your load-balancers configuration.

Some large (internet) applications have moved operations such as joins to the application and only use the database for simple storage.

I think it's a reasonable advice.

Re: Lessons after five years of professional programming

#14

Post by vidarh »

markokocic wrote: post #3

First advice is horrible. One shouldn't do in application things that are meant to be done in (relational) database, like ordering, grouping, joining... I guess 66% of my application performance tuning was removing iteration over large result sets in application code with a few lines of SQL. The other 30% being making sure the database is not hit with redundant queries. I have rarely seen the case where minimizing th…

It is not horrible advice once your system hits hard limits of the database system. Depending on your database system you can hit those fairly quickly.

It is often far cheaper to scale an application over many boxes by extracting data from your canonical database into a set of in-memory read-only search structures, for example, and delta-index and merge changes regularly.

It is similarly often far cheaper to sort and group large dataset outside the database because sorting and grouping are simple to parallelise over multiple machines working on in memory subsets and doing cheap merges at the end.

If your system can run at reasonable speed in your RDBMS, sure, do that rather than reinvent the wheel.

But when you find yourself maintaining complex trees of replicas, it is often worth testing if you can do better with specialised middleware that can selectively throw out guarantees your RDBMS can't because it would violate guarantees it is meant to provide and that can otherwise make use of specialized characteristics of your data.

E.g. you don't see people running large search engines out of RDBMS's. For a simple reason: while many RDBMS's provide full text search, you can do it far faster when you realize that your full text index is "always" going to be catching up, and so once you exceed the threshold where a single RDBMS doesn't serve your needs anymore (and often before that) you can save massive amount of resources by building small, frequent deltas of changes, distributing them to however many app servers you need, and gradually merging the deltas into larger chunks to keep the number manageable.

There are a lot of scenarios like that where moving the logic out of your data store makes sense.

Re: Lessons after five years of professional programming

#15

Post by vidarh »

hackerboos wrote: post #4
markokocic wrote: post #3

First advice is horrible. One shouldn't do in application things that are meant to be done in (relational) database, like ordering, grouping, joining... I guess 66% of my application performance tuning was removing iteration over large result sets in application code with a few lines of SQL. The other 30% being making sure the database is not hit with redundant queries. I have rarely seen the case where minimizing th…

I agree. Why would you sort in memory? RDBMS have been heavily optimised to do these things.

You would sort in memory when your dataset and/or number of clients is large enough that you would need to distribute your dataset over many servers and the overhead of replication with your preferred RDBMS is too high. E.g. large sorts can be reasonably well parallelized (split the dataset into chunks, sort each chunk, and zipper merge the sorted subsets on a machine collecting the result), and similarly caching the dataset on however many app servers you need in order to do sorts often makes it worthwhile even for much smaller datasets.

If you can run everything on one machine, or your RDBMS handles sharing and replication efficiently and easily, then by all means try that first. But you can often beat the pants of RDBMS' for specialized scenarios.

Re: Lessons after five years of professional programming

#16

Post by facorreia »

rombdn wrote: post #11
billN wrote: post #8

1. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. I disagree. RDBMS are highly optimized for this kind of operations (including MS SQL…

1. I disagree, on many ERP the DB is totally overloaded and the middleware is sleeping (and/or easier to scale). I think this is the kind of case where the ideal architecture paradigm has to be bent. Your others points are really informative thanks.

I concur. Exadatas ain't cheap and they're selling like hot cakes. It's cheaper and quicker to scale horizontally than vertically and that is particularly true when the database becomes a huge performance bottleneck taking several DBAs' full attention trying to deal with I/O contention.

Re: Lessons after five years of professional programming

#17

Post by mfenniak »

markokocic wrote: post #3

First advice is horrible. One shouldn't do in application things that are meant to be done in (relational) database, like ordering, grouping, joining... I guess 66% of my application performance tuning was removing iteration over large result sets in application code with a few lines of SQL. The other 30% being making sure the database is not hit with redundant queries. I have rarely seen the case where minimizing th…

I think the advice in point #1 only makes sense with a caveat: When performance is an issue, if you can calculate or process it at the application layer _without adding load to the database layer_, then take it out of the database layer.

For example, order-by w/ limit/offset? If you do that at the application layer, you've increased the I/O usage on the database server, and clearly this advice doesn't make sense.

On the other hand, group-by (assuming no HAVING)? If you do that at the application layer, you've reduced the load on the database server, increased the load on the network, and you've probably made a justifiable performance vs. scalability trade-off. If you measure it and back it up with data.

I think the advice here in the article is too broad, but I can see a kernel of wisdom in it that is non-intuitive.

Re: Lessons after five years of professional programming

#18

Post by markokocic »

mfenniak wrote: post #17
markokocic wrote: post #3

First advice is horrible. One shouldn't do in application things that are meant to be done in (relational) database, like ordering, grouping, joining... I guess 66% of my application performance tuning was removing iteration over large result sets in application code with a few lines of SQL. The other 30% being making sure the database is not hit with redundant queries. I have rarely seen the case where minimizing th…

I think the advice in point #1 only makes sense with a caveat: When performance is an issue, if you can calculate or process it at the application layer _without adding load to the database layer_, then take it out of the database layer. For example, order-by w/ limit/offset? If you do that at the application layer, you've increased the I/O usage on the database server, and clearly this advice doesn't make sense. On…

Well, without a caveat the advice is plain wrong in 99% cases, since that caveat changes the advice completely.

Re: Lessons after five years of professional programming

#19

Post by pyre »

billN wrote: post #8

1. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. I disagree. RDBMS are highly optimized for this kind of operations (including MS SQL…

  > Code should be self readable, and if you get
  > to the point where it isn’t, then you may have
  > to rewrite few bits. This is not always
  > possible though, especially for temporary
  > hotfixes or hacks. In this case, comments are
  > a must.
* Sometimes business decisions may not make logical sense, but someone says "do it this way." It makes sense to comment this in the code.

* The code might tell you what it's doing, but not necessarily why it's doing it.

* You may be making use of legacy components that you are unable to rewrite. It may make sense to comment on their use within newer code that interfaces with them, making it possible for people to bugfix the interface without needing to delve all the way into the legacy component.

Re: Lessons after five years of professional programming

#20

Post by sageikosa »

rombdn wrote: post #11
billN wrote: post #8

1. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. I disagree. RDBMS are highly optimized for this kind of operations (including MS SQL…

1. I disagree, on many ERP the DB is totally overloaded and the middleware is sleeping (and/or easier to scale). I think this is the kind of case where the ideal architecture paradigm has to be bent. Your others points are really informative thanks.

I'll make a qualified concur with you. Order by and group by are often best lest to the database, where (proper) indexing can provide streamed access to large sets of data. Relatively static lookup value substitution and security checks (via permissions/user tables) are best moved closer to the user.

I'm also a big fan of building transactional updates in "service-space" and using transactional coordination to ensure ACID, rather than making bulky stored procedures to churn over bits of procedural data.

Post reply on HN