231–240 of 427 posts
Earlier quoted context omitted.
Define unique? My company does bespoke software development for large enterprises. If they're on AWS having all your services within a VPC you control is something of table stakes for a lot of large company engineering and security teams.
Well, guess I'm mostly talking about startups.
Anecdotes like this are just that, anecdotes, there are no numbers in this article to show a trend away from Mongo, Mongo is actually continuing to gain adoption. See https://db-engines.com/en/ranking
Earlier quoted context omitted.
This was what was particularly interesting to me - that they went to the effort of writing a purely technical article on the particulars of how parts of their environment operate, and to publish it on their platform even when that's not the sort of content they're known for.
It's not their main platform though: > Digital Blog > A blog by the Guardian's internal Digital team. We build the Guardian website, mobile apps, Editorial tools, revenue products, support our infrastructure and manage all things tech around the Guardian
Guess it makes sense to reuse the platform that already has the templates than use another platform and reimplement the design.
Good read. Although I don’t quite understand why every few years media companies keep rewriting their content management layer which generally has no impact on company’s top line or bottom line whatsoever. How can these type of investments are justified when all you are doing is recreating exactly same APIs with same data. Am I missing something here?
Why would you delete the MongoDB's so soon after the migration? What if things look great for a few hours/days, but then things go horribly wrong? I suppose they still had Mongo backups too? Just unsure why you wouldn't leave those around for awhile.
Earlier quoted context omitted.
I think you're asking the wrong question. The question should be: How did MongoDB become so successful? IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. MongoDB was the natural choice because they excelled at being accessible to devs who were already familiar with Javascript and JSON. Not only that, their marketing/outreach efforts were also…
> IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. The thing I dislike about this type of comment – although I now notice yours doesn't explicitly say this – is the implication that devs don't like SQL because they're lazy or stupid. Well, sometimes that is probably true! But there are some tasks where you need to build the query dynamically…
# Query all rows in the "users" table, filtering for users whose age is > 18, and selecting their name
"users"
|> where([u], u.age > 18)
|> select([u], u.name)
# Build a dynamic query fragment based on some parameters
dynamic = false
dynamic =
if params["is_public"] do
dynamic([p], p.is_public or ^dynamic)
else
dynamic
end
dynamic =
if params["allow_reviewers"] do
dynamic([p, a], a.reviewer == true or ^dynamic)
else
dynamic
end
from "posts", where: ^dynamic
My main point, though, is that you don't need to reach for NoSQL if all you need is a way to compose queries without string interpolation.
I'm not sure why a database is required at all. Surely the main advantage is to support tables and joins. If you just want a key-value store surely S3 or similar would be simplest. Do they search the data? Surely Cassandra is designed for this. Any ideas?
Cassandra isn't designed for this. Been there, done that. postgres all the way. THe FT use(d) cassandra to store their membership details (6 million rows of largely static, read-only well structured data) The cluster was massive (12+nodes in at least two regions, from memory) slow and was impossible to upgrade reliably. The support from datastax is shite. Backups are not reliable. imports even less so, and you are be…
Datastax builds a graph layer on top, or you can use something like JanusGraph, but it's never as good as using a real graph database with natively designed storage system.
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…
Old versions of mongo were very bad. We accured lots of downtime due to mongo. But later versions were rock solid and I've matainer mongo installations at many startup and SMEs once you setup alertd for disk/memory usage, off you go. Works like charm 99% of the times.
Unfortunately the number of my customers who would sign off on just "two nines" is approximately zero...
Earlier quoted context omitted.
This is what I'm talking about. You think that some feature that makes performance unpredictable is that important. While it's the last thing you should care about.
The only way for query performance to be truly predictable is for your data to be static. If that's not your situation then a query optimizer is incredibly helpful because it means that you don't have to rewrite your queries every time you add an index.
That means that 18 months after you implemented a feature you've long since forgotten about, you don't have to come back and figure out what the new plan should be. And that's huuuuge.
You can find accounts of the db changing the plan from a good one to a bad one, but I'll go out on not that far of a limb and say that those are < 1% of the cases. Nobody complains about the queries they didn't have to come back and change. And the better the optimizer, the better that trade off will be.