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

“Fashion Is Hard. PostgreSQL Is Easy” [video]

tech.zalando.com

Post reply on HN
Print view View original

131–140 of 140 posts

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#131

Post by dk8996 »

StavrosK wrote: post #14

PosgreSQL is pretty much my default. Any other database has to have compelling arguments for how it fits my use case if I'm going to use it over Postgres, and even then, it usually gets used for a subset of the data, while Postgres gets everything else. I think it's better to default to the tried-and-true piece of software than the new and shiny, rather than the other way around and have to argue why Postgres is a go…

We used PostgreSQL at my old startup and switch away from MYSQL. Some of the things I liked about PostgreSQL; that you can do schema updates without rewriting and locking the table. The one thing we ran into, because of the way MVCC works, when you update a column the whole row gets rewritten. For example; if you have large rows and you update a Boolean column in a bunch of them - you will get a large write load. We ran on AWS and basically maxed out the PIOPs when updating a Boolean column on ~2m record table. Moreover, this would effect our read speeds causing our web site to be super slow. There was no easy way to throttle the MVCC writes.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#132

Post by spacecowboy_lon »

gdulli wrote: post #87
spacecowboy_lon wrote: post #84

Earlier quoted context omitted.

Isn't That how your supposed to do it using Sprocs is more time consuming but it does have several advantages from security and performance.

There's no way you're "supposed to" do it. There are tradeoffs and you pick the approach you like most given those tradeoffs.

Not sure id agree 100% with you for standard LOB CRUD applications the use of Sprocs is best practice.

Obviously if your just writing a tool that will be used 2 or 3 times that - you can make trade offs - but you should never use $sql = "SELECT * FROM tblBobbins"

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#133

Post by collyw »

semi-extrinsic wrote: post #107
collyw wrote: post #100

Earlier quoted context omitted.

Eclipse isn't great in that respect, but choosing something from a menu is definitely more intuitive than remembering the cryptic commands in emacs.

"The only intuitive interface is the nipple, after that it's all learned." - Bruce Ediger

Sure but a menu is still more intuitive than C-c.

(I even had to check the fact that C- is the ctrl key when looking up this command. I noticed commands listed as M-w - I have no idea what keys that represents).

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#134

Post by dllthomas »

collyw wrote: post #133
semi-extrinsic wrote: post #107

Earlier quoted context omitted.

"The only intuitive interface is the nipple, after that it's all learned." - Bruce Ediger

Sure but a menu is still more intuitive than C-c. (I even had to check the fact that C- is the ctrl key when looking up this command. I noticed commands listed as M-w - I have no idea what keys that represents).

M is short for Meta, and usually means "Alt".

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#135

Post by kaolinite »

WorldWideWayne wrote: post #73
marcosdumay wrote: post #66

Earlier quoted context omitted.

Count another vote for the pgadmin. I hate the backslash commands of postgres, about as much as I hate the show commands of mysql (what's not nearly as much as I hate the oracle introspection tools). Why couldn't SQL standardize database introspection?

This whole thread makes me happy to be a SQL Server user, where the UI tools are standard and robust. 90% of the time, I don't need to remember any special commands for introspecting and since it's on Windows - I can use the keyboard to navigate the entire UI with ease. When I write SQL, I get glorious Intellisense (that's autocomplete to you) for every single object ( edit: and command ) in the db.

I have no idea how they compare but the open-source databases has proprietary database tools too, such as Navicat, which have auto-complete, a good UI (Navicat is hardly beautiful but it works well), etc. There are a few other options too.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#136

Post by whisdol »

spython wrote: post #108
kaufland wrote: post #8

Hmm, looking a bit at their site[1]: Addidas jogging pants -- 59,95 € Volcom T-shirt print -- 17,45 € Under Armour T-shirt -- 39.95 € Like really now -- who needs this stuff? Especially when you can just go to Aldi or Tchibo (or any of a number of other discount retailers readily visible at nearly every shopping mall in Germany) and buy essentially same stuff (minus the logos, of course) for 1/10th of the price. So p…

Please don't buy from discount retailers - support your local tailors and fashion designers. For a bit more than what it offered at zalando, you can get higher quality unique products from fashion design students.

Honest question: How do I find those? Online, local brick-and-mortar stores?

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#137

Post by angrybits »

takeda wrote: post #126
angrybits wrote: post #122

Earlier quoted context omitted.

RDS makes it trivial to have high availability if you can't afford a DBA worth their salt. You don't need 10x replication to beat the uptime of your shitty web app.

I thought so too, until I decided to use RDS for storing zabbix. It looks great on paper, but unless you're doing development I would discourage its use. That said your original point about the replication is true, but there are shortcomings that come together with it. Some things that you will learn if you use RDS: - if you decide to increase volume size, change type to SSD or use provisioned IOPS, you might have da…

First off, thanks for sharing your experiences. I am standing up a system right now that will use PostgreSQL RDS and it's good to know what kinds of bumps in the road to expect.

I think I am fine with most of those, since I am saving on labor costs. Periodically taking an app down for maintenance is par for most courses. And even on the last bullet, I've seen really talented database guys make mistakes and have small amounts of downtime. Perhaps what I should have said was "high enough availability". If I needed 5 9's, I agree that RDS is probably not the tree I want to be barking up.

Cheers!

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#138

Post by angrybits »

emilburzo wrote: post #128
angrybits wrote: post #120

Earlier quoted context omitted.

If it's running on a desktop in your apartment, you don't need replica sets.

Why not? It is a desktop (as-in, it has normal desktop components, although used headless like a server), but it's got plenty of RAM, good CPU, RAID1 on WD Re hard drives, 100mbit connection and hooked up to a UPS. In the last year it has been more stable than some of the cheaper hosting I was using. Besides, it's not running the whole replica set, just one member (out of 3).

Because it can and will fail in odd ways, and that has one of two outcomes:

1) It doesn't matter, which means the time, energy and money spent setting it up was squandered when it could have been spent on marketing or product dev.

or

2) It does matter, which means now you have to blow even more time, energy and money recovering it and standing it back up. Hope you've rehearsed your DR plan!

I'm not trying to preach, I apologize if it's coming off that way. But this highly resembles tinkering, and tinkering doesn't generally pay the bills. Usually the opposite.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#139

Post by emilburzo »

angrybits wrote: post #138
emilburzo wrote: post #128

Earlier quoted context omitted.

Why not? It is a desktop (as-in, it has normal desktop components, although used headless like a server), but it's got plenty of RAM, good CPU, RAID1 on WD Re hard drives, 100mbit connection and hooked up to a UPS. In the last year it has been more stable than some of the cheaper hosting I was using. Besides, it's not running the whole replica set, just one member (out of 3).

Because it can and will fail in odd ways, and that has one of two outcomes: 1) It doesn't matter, which means the time, energy and money spent setting it up was squandered when it could have been spent on marketing or product dev. or 2) It does matter, which means now you have to blow even more time, energy and money recovering it and standing it back up. Hope you've rehearsed your DR plan! I'm not trying to preach,…

> Because it can and will fail in odd ways, and that has one of two outcomes:

Can't that happen anywhere? Regardless of the type of hardware.

> But this highly resembles tinkering

Guilty pleasure.

> [...], and tinkering doesn't generally pay the bills.

Thankfully, I was aware that it most likely won't be paying the bills, and considering I've made 35€ from it in the past year and a half, I guess I was right :-)

I've made it for myself (and opened it for the rest of the world if they need it), but I'm my most demanding customer, that's probably why I expected nothing less than 100% uptime since I launched it.

And I've managed to do that, without breaking the bank.

I don't know how my tone sounds (I'm not native), I'm just trying to emphasize that with the right tools, you don't need a shiny cloud for really good uptime.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#140

Post by takeda »

angrybits wrote: post #137
takeda wrote: post #126

Earlier quoted context omitted.

I thought so too, until I decided to use RDS for storing zabbix. It looks great on paper, but unless you're doing development I would discourage its use. That said your original point about the replication is true, but there are shortcomings that come together with it. Some things that you will learn if you use RDS: - if you decide to increase volume size, change type to SSD or use provisioned IOPS, you might have da…

First off, thanks for sharing your experiences. I am standing up a system right now that will use PostgreSQL RDS and it's good to know what kinds of bumps in the road to expect. I think I am fine with most of those, since I am saving on labor costs. Periodically taking an app down for maintenance is par for most courses. And even on the last bullet, I've seen really talented database guys make mistakes and have small…

Yeah RDS is ok as long as you are ok with the limitation.

I was more concerned about relying on it for 24/7 operation. Such as for transactions on a webpage. The zabbix scenario in our case also requires 24/7 uptime, but if it goes down our site is still up we just won't be alerted when something else breaks at the same time.

Post reply on HN