5 ms·
> As a new grad I often times find myself frustrated with setting up postgres or other rdbms so I usually opt for easier systems like amazon RDS, firebase or mo
by brandur 9y ago
> As a new grad I often times find myself frustrated with setting up postgres or other rdbms so I usually opt for easier systems like amazon RDS, firebase or mongo.
Yeah, I know exactly what you mean. Everything in Postgres is supremely well documented, but there's just so much documentation, that getting the basics down is pretty hard. I definitely went through a period of building muscle that was a tad frustrating to say the least.
Unfortunately, I don't know a particularly succinct resource that I recommend right now, but I will suggest taking a look at official docs. Maybe the section on managing databases in particular [1]. In general, you should just get good at using createdb, dropdb, and psql (which is mostly just generic SQL).
If you're on a Mac, installation and setup might looks as easy as:
brew install postgresql
brew services start postgresql
createdb my-test-db
psql my-test-db
dropdb my-test-db
(There's obviously far more there than just that, but at a basic level, most of the commands are reasonably easy to use.)
[1] https://www.postgresql.org/docs/9.6/static/managing-databases.html https://www.postgresql.org/docs/9.6/static/managing-database...
- tracker1 9y agoNow setup 3-5 replica nodes with at least automatic master election and failover.
- qaq 9y agoand you need that because ...?
- closeparen 9y agoYou shouldn't go down when one box or VPS falls over?
- oblio 9y agoFor 99% of the situations you just need 2 boxes.
- mbesto 9y agoAnd if you do need more, there's commercial solutions: https://aws.amazon.com/rds/postgresql/ https://aws.amazon.com/rds/postgresql/ https://www.citusdata.com/ https://www.citusdata.com/
- qaq 9y agoRDS is very far from optimal for high load PG
- tracker1 9y agoAnd, I've worked in a few that needed more... million+ simultaneous users, and over 380k requests per second, and 5 nines. There really are times you need more than an SQL server can keep up with. Another, it was the shape of the data, all keyed off a single record, but ancillary tables with additional queries or joins meant over 30 joins, or 15 additional queries to render one resource, which fit into a single "nosql" record and mongo supported the additional indexes needed, it was a good fit for the use case. I'm not advocating nosql for everything... I've seen a few that went mongo that would have been better served with sql. But that isn't to say that a document or column-store database is never a better fit from the start.
- qaq 9y agoYou shouldn't and that is trivial to setup.