81–90 of 140 posts
Earlier quoted context omitted.
What is a good space to look at when you get write heavy data to the point of streaming?
The filesystem. Ok, that not completely serious, but almost completely.
I love PostgreSQL. But for a personal project I went with MongoDB, because my data set was a perfect match for mongo's design. Now I love mongo too, I'm amazed with how easy it has been to maintain 100% uptime on comodity hardware (one server is literally in a room in my apartment) through all the random server downtimes, upgrades, migrations, etc. And now I have more ideas for some personal projects, and they would…
I love PostgreSQL. But for a personal project I went with MongoDB, because my data set was a perfect match for mongo's design. Now I love mongo too, I'm amazed with how easy it has been to maintain 100% uptime on comodity hardware (one server is literally in a room in my apartment) through all the random server downtimes, upgrades, migrations, etc. And now I have more ideas for some personal projects, and they would…
https://www.compose.io/articles/is-postgresql-your-next-json...
I had a job interview at Zalando a while ago, and apart from the huge bunch of bananas at the entrance to the developer's den, the one thing I remember most about was the fact that apparently they're using stored procedures for basically any database transaction. Which is probably a more unorthodox use of databases these days, at least for Postgres (I've heard it was more common for SQL Server and I once had the ques…
Earlier quoted context omitted.
That's probably the best way of looking at it. PostgreSQL is generally going to be the best solution for 90% of your data, short of having a subset that's write heavy to the point of streaming.
What is a good space to look at when you get write heavy data to the point of streaming?
Earlier quoted context omitted.
The filesystem. Ok, that not completely serious, but almost completely.
Could work dump the incoming steam to disk in some sensibel text format and have an asynchronous queue process the data into the database.
I had a job interview at Zalando a while ago, and apart from the huge bunch of bananas at the entrance to the developer's den, the one thing I remember most about was the fact that apparently they're using stored procedures for basically any database transaction. Which is probably a more unorthodox use of databases these days, at least for Postgres (I've heard it was more common for SQL Server and I once had the ques…
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.
Earlier quoted context omitted.
Ping isn't a CLI, its a single command that expects no further input. A database shell is more like bash than ping. And Ctrl-C does not exit out of bash.
[deleted]
The following things (off the top of my head, and quickly verified) all handle Ctrl-C so that it kills only the current command and not the containing process:
bash, zsh, csh, ksh, mail, gnuplot, gdb, psql, vsql, python (interactive), ghci
While I object to captive user interfaces in general, if you're going to have one then handling ctrl-c inside it is the right thing to do.
Earlier quoted context omitted.
It's quite common for startups to have 1 or 2 sexy (and well-enough engineered) projects involving your favorite technology X, to run up the flagpole at conferences or in job ads, etc. But like as not, 80% of what they do (and of what you'll be doing as a developer there) is the same half-baked, post-"blitzkrieg" mop-up work you'll be doing pretty much anywhere else.
They were pretty straight about that: Java, ExtJS, stored procedures. Not exactly candidates for the sexiest development tools alive. They were pretty honest about that, no "this will look awesome on your resume" tomfoolery. It was a pretty great interview, and I almost took them up on their offer. So don't get me wrong, I neither want to praise their stack nor put it down, I just thought that their ubiquitous use of…
PostgreSQL is great, but I've gone back to MySQL because of the ease of which I can setup replication (which I like to use when possible in addition to automated/periodic backups).
MySQL has some features that I'm really missing in PostgreSQL, like more flexible compression, and batched index writeout.