On 22 Jun 2016, at 10:20, Jason Smith <[email protected]> wrote:
On Wed, Jun 22, 2016 at 3:29 AM, Alexander Harm <[email protected]> wrote:
I especially love the quote of Laurie Voss:
"One of the big things that everybody who's spent a lot of time with
databases knows is that you should never put your binaries in the database.
It's a terrible idea. It always goes wrong. I have never met a database in
15 years of which it is not true, and it's definitely not true of CouchDB.
You are taking this thing which is meant to sort and organize data, and
you're giving it binary data, which it can neither sort nor organize. It
can't do anything with that data, other than get really fat.”
This is a pet peeve of mine.
"Do not store files in the database."
That simplistic mantra is up there with "[about regular expressions], now
you have two problems." It is so simple, so naïve. It can be over-done, or
under-analyzed.
Some thoughts.
1. All large systems experience growing pains from off-the-shelf tools. All
large projects must become custom. Twitter's growth is not an indictment of
Ruby on Rails. Google's growth is not an indictment of the ext filesystem.
2. Attachments in CouchDB are very simple. Simple is easy to ship. Simple
is easy to maintain. Simple projects allow you to focus on other problems.
3. Attachments in CouchDB make less sense as a project matures. Yes, I said
it. But just be careful not to prematurely optimize.
Once you really grow, you will be investigating CDNs, and caching tools,
and all sorts of alternatives. But how did you become that successful? How
did you come to this "good problem"? Because you shipped, and you
delivered, and you scaled. And at long last, you have earned the privilege
of building something large and complex.
Laurie Voss joined npm and made that quote some years after npm came
online. It had been growing exponentially for a few years. I remember
clearly: npm was already processing 1,000 requests per second, all on
plain-Jane CouchDB, with a very simple design.
"You didn't build that," as the man says. In my opinion, attachments played
a part in npm's early success, and moving away from them played a part in
npm's latter success. Both were wise decisions.
