91–100 of 427 posts
I haven't tried it yet, and there are some limitations at the moment, but I find it extremely promising.
I never got around to using Mongo as my main doc db because it was incredibly hard to find a management tool. I now use json supported functions in SQL Server and do not have the need for a different type of database. SQL Server handles my small 'documents db' implementation with the infrastructure of a RDMS. Win win for me. To me Mongo just got popular by mistake way too early. It's like having a celebrity retweet y…
Earlier quoted context omitted.
Well, we're kind of comparing MongoDB of ~2011 (when The Guardian started using them) with Postgres of today. One major change is that in 2010 you couldn't always run your whole DB in RAM, so there were some real performance benefits with MongoDB. Another difference is that MongoDB was early with great JSON-support. Something that Postgres has since gained. I think there are pros and cons with both. If I'd chose one…
Oh! From The Guardian write up I had the impression they were using it until mid 2018..
While we are here. I know HN hates mongo. But lemme ask this question, what are the things in which mongo is better than postgres?
Document DBs are like blockchain projects - overhyped and worse than existing solutions for nearly every use case. Why do ostensibly smart engineers keep falling for this stuff?
Well, we're kind of comparing MongoDB of ~2011 (when The Guardian started using them) with Postgres of today. One major change is that in 2010 you couldn't always run your whole DB in RAM, so there were some real performance benefits with MongoDB. Another difference is that MongoDB was early with great JSON-support. Something that Postgres has since gained. I think there are pros and cons with both. If I'd chose one…
I worked with databases that only had table level locks(not row level) and there were more than enough occasions I cursed the creators.
Instance level(& indeed DB level) is insanity unless your DB is a read only DB.
Specific technology choices aside, this was an incredible write-up of their migration process: thorough, organized, readable prose about a technical topic. It is helpful to read how other teams handle these types of processes in real production systems. Perhaps most refreshing is the description of choices made for the various infrastructure pieces, because it is reasonable and real-world. Blog posts so often describ…
Part of my duties at work require me to deal with "large" issues. While a solution to them is usually necessary and quick and high quality, I've seen the analyses that come after them vary in quality.
Good writeups tend to stick around in people's memories and become company culture, and drive everyone to do better. Bad writeups are forgotten, and thus the lessons learned from them are forgotten as well.
This particular article stands out for me. English is not my first language, and I've spent most of my life dealing with very fundamental technical details, so most of my writeups aren't the best. I'm going to bookmark this one and come back to it to learn how to write accessible technical narratives.
Earlier quoted context omitted.
It's amazing how many insurmountable SQL performance problems can be surmounted by putting things in 3rd normal form.
But denormalization is one strategy to improve the performance of a rdbms.
It is true that for some narrow class of analytical workloads 20-25 years ago (behold BW of 199x) the denormalized case performance was better compare with straight non-optimized running of the same queries over normalized schema. Since then, the exponential availability of RAM and huge increase in streaming speed of HDD with stagnating IOPS (the main mistake in analytical workloads on HDD in the last 10-15 years - using nested loop join with indexed lookup into the large facts tables :) have made denormalization obsolete and harmful. If anything, the emergence of SSD and the huge RAMs moved things even further toward and beyond normalization, by making the "super-normalization", i.e. columnar tables, a viable everyday thing.
1. Stop. Trying. To. Build. Your. Own. Cloud. A pizza shop doesn't build their own cars to deliver pizzas.
2. There's no such thing as hassle-free anything, unless you are paying someone else to deal with the hassle. Sales teams lie.
3. Justifying an untested idea with "but it's modern technology" is going to backfire. Follow established patterns with good track records.
4. Writing your own in-house behemoth product, of which there are already many kinds available, results in long-term expensive engineering projects necessary to to get around the high costs you didn't know were coming.
5. Don't write business logic, or your primary software product, in a way that talks directly to a database. Just... No.
6. Magic new technologies that remove the problems of old technology also introduce the problems of new technology.