5 ms·

Caching could be the last thing you want to do

25 points by desigooner 16y ago

knieveltech 16y ago
Sorry, I stopped reading at six sigma.
- JoachimSchipper 16y ago
  In this particular case, he could have written "reliably good performance is important". Which is a sensible idea, buzzword or no.
- tzs 16y ago
  You should go to reddit and do an AMA. I'm sure many would be interested in such an unusual learning disability.
boyter 16y ago
He does have a good point which is that caching when you are running many unoptimised queries is hiding the underlying problem. That said there isnt too much to see here other then dont rely on cache to save you and optimise other stuff first since cache might end up hiding the underlying problem making it hard to fix when you do need to.
gaius 16y ago
Do your queries SELECT, only to use subset of columns? Or do you extract many rows, only to use a subset? All the database optimization in the world won't help you if your developers only know how to do SELECT * FROM MYTABLE;
- morgo 16y ago
  If they understand how to use memcached, but they can't do: SELECT col1, col2 FROM mytable; .. then something is seriously wrong with the world.
- spudlyo 16y ago
  Sometimes it's not that big of a deal. The idea is if you specify only the columns you need, sometimes those columns can be satisfied directly from the index (what's known as a covering index) and you don't need to seek around to the various data pages to pull the rest of the columns. InnoDB though uses a clustered indexing scheme, where the rest of the columns are stored in the leaf nodes, so if you query by primary key, all the data is right there -- no extra seeking. Anyway, obviously it's better to only ask for what you need, but it's not the stupidest thing in the world to SELECT with wildcard.
  - gaius 16y ago
    Well, also that you're not physically moving data you don't need across the connection. I have literally seen "programmers" simply select like that and filter out the rows they want, or sort the entire table (and then filter out the rows), in their own code. Madness.
mmt 16y ago
In terms of future-proofing design, many applications are better off keeping it simple and (at least initially) refusing the temptation to try and solve some problems “like the big guys do”. To me, this is the most important argument against knee-jerk reliance on memcache, sharding, (ironically) MySQL, NoSQL, or what happens to be the new fashion[1]. Understandably, buckling down and squeezing more out of the existing, tried and true, technology, is neither sexy nor exciting. However, you're no"big guy" yet, and, once you are, you'll kow that a bit of early tedium[2] can pay off. [1] Like with clothing fashion, novelty is periodic, rather than monotonic. [2] e.g. Google's early "cork board" servers could only be sexy in retrospect

25 points by desigooner 16y ago

knieveltech 16y ago

Sorry, I stopped reading at six sigma.

JoachimSchipper 16y ago
In this particular case, he could have written "reliably good performance is important". Which is a sensible idea, buzzword or no.
tzs 16y ago
You should go to reddit and do an AMA. I'm sure many would be interested in such an unusual learning disability.

boyter 16y ago

He does have a good point which is that caching when you are running many unoptimised queries is hiding the underlying problem. That said there isnt too much to see here other then dont rely on cache to save you and optimise other stuff first since cache might end up hiding the underlying problem making it hard to fix when you do need to.

gaius 16y ago

Do your queries SELECT, only to use subset of columns? Or do you extract many rows, only to use a subset? All the database optimization in the world won't help you if your developers only know how to do SELECT * FROM MYTABLE;

morgo 16y ago
If they understand how to use memcached, but they can't do: SELECT col1, col2 FROM mytable; .. then something is seriously wrong with the world.
spudlyo 16y ago
Sometimes it's not that big of a deal. The idea is if you specify only the columns you need, sometimes those columns can be satisfied directly from the index (what's known as a covering index) and you don't need to seek around to the various data pages to pull the rest of the columns. InnoDB though uses a clustered indexing scheme, where the rest of the columns are stored in the leaf nodes, so if you query by primary key, all the data is right there -- no extra seeking. Anyway, obviously it's better to only ask for what you need, but it's not the stupidest thing in the world to SELECT with wildcard.
- gaius 16y ago
  Well, also that you're not physically moving data you don't need across the connection. I have literally seen "programmers" simply select like that and filter out the rows they want, or sort the entire table (and then filter out the rows), in their own code. Madness.

mmt 16y ago

In terms of future-proofing design, many applications are better off keeping it simple and (at least initially) refusing the temptation to try and solve some problems “like the big guys do”. To me, this is the most important argument against knee-jerk reliance on memcache, sharding, (ironically) MySQL, NoSQL, or what happens to be the new fashion[1]. Understandably, buckling down and squeezing more out of the existing, tried and true, technology, is neither sexy nor exciting. However, you're no"big guy" yet, and, once you are, you'll kow that a bit of early tedium[2] can pay off. [1] Like with clothing fashion, novelty is periodic, rather than monotonic. [2] e.g. Google's early "cork board" servers could only be sexy in retrospect