It really irks me when a big company like Meta tries to describe a new project as a startup created by a "nimble team of engineers". In the blog post they link to [1] >Threads was developed in an environment more akin to a startup. OK sure, a small group of people broke the model of development and did something new from the ground up? >Threads scaled successfully to 100 million users without any major downtime thank…
How meta built the infrastructure for Threads
171–180 of 184 posts
Re: How meta built the infrastructure for Threads
#172Earlier quoted context omitted.
It's a bot prevention measure (allegedly). It also conveniently blocks out people that are more likely to not want to share all of their personal information with them. No skin off my back, the less toxic social media garbage I'm allowed to use, the better for my sanity, good riddance.
TO BE FAIR (and I'm still on the fence how I feel about this)... the less personal information you share, the more bot-like you appear to be.
As I also value freedom of association, I am perfectly alright with them refusing to "do business" with me because I do not find the denomination and terms of the transaction acceptable.
I do not really have any inclination to want to compel them to serve me by force of gun, either.
I think both they and myself are better off in this scenario where we just choose to not do business with each other and I find some other business that has more acceptable terms - or I just go without, these services aren't as essential as some people think.
Re: How meta built the infrastructure for Threads
#173Never heard of ZippyDB. Shame it is not open source.
Re: How meta built the infrastructure for Threads
#174Earlier quoted context omitted.
They are common but not majority opinion. The average Indian is more supportive of Israel for example. That's the most populous country in the world and you definitely see them on X as well. The average Chinese doesn't care about either and doesn't use any foreign social media apps. Many of us have a very selective view of the world. When you have a platform that allows most speech from anyone on the planet, such an…
The Chinese are overwhelmingly opposed to US foreign policy. Outright pro-Israel and pro-NATO views are virtually non-existent on Chinese social media. Some Hindu-supremacist Indians support Israel because of shared Islamophobia, more or less. There is not much rabid Islamophobia outside of the West + India. >They are common but not majority opinion. To suggest that the (powerless) majority of 8 billion humans are no…
Re: How meta built the infrastructure for Threads
#175Earlier quoted context omitted.
Thank you for sharing your experience and expertise. I'm a big fan of MySQL's scaling properties and some of the tooling (Vitess). Do you see any emergent general purpose RDBMS achieving similar popularity of MySQL and/or PostgreSQL in the near future? I heard good things about Clickhouse but it's a different tool (column based) from my understanding.
I am not a good judge of popularity, given that I still post a lot about MySQL on HN in the year 2024 :) In all seriousness though, as a bootstrapped founder I'm not usually able to devote time to tinkering with emergent databases, sorry! From what I've heard, Clickhouse is excellent, but it is OLAP focused rather than OLTP.
Keep it up!
Re: How meta built the infrastructure for Threads
#176Earlier quoted context omitted.
From having talked to Facebook engineers (I suspect Instagram/Threads is a very different beast for historical reasons), Facebook is only built on "PHP and MySQL" in the sense that the statement is technically correct but not helpful. The way Facebook apparently uses MySQL is not "MySQL + k/v store" but "MySQL is the k/v store". Forget SQL, they treat it as a key-value lookup and it's good enough for that. This also…
This is not correct. Facebook has a large number of distinct MySQL tiers, which serve different purposes and have wildly different workloads. None of them are traditional "key-value lookup" workloads, not even the core user database (entities/associations); this k/v claim is often repeated here, but has never been an accurate representation of the architecture. The TAO graph access pattern absolutely requires range s…
Do they still use TAO?
Just wondering if they will ever open source TAO.
Re: How meta built the infrastructure for Threads
#177Earlier quoted context omitted.
Thank you for sharing your experience and expertise. I'm a big fan of MySQL's scaling properties and some of the tooling (Vitess). Do you see any emergent general purpose RDBMS achieving similar popularity of MySQL and/or PostgreSQL in the near future? I heard good things about Clickhouse but it's a different tool (column based) from my understanding.
I am not a good judge of popularity, given that I still post a lot about MySQL on HN in the year 2024 :) In all seriousness though, as a bootstrapped founder I'm not usually able to devote time to tinkering with emergent databases, sorry! From what I've heard, Clickhouse is excellent, but it is OLAP focused rather than OLTP.
Not nearly enough So please do that more often :)
Seriously I dont want HN to be one sided about RMDBS and I constantly submit a lot of MySQL related content and release notes. And there is still a whole world using MySQL for a lot of different reasons.
Especially now Oracle has finally updated MySQL release schedule.
Re: How meta built the infrastructure for Threads
#178Re: How meta built the infrastructure for Threads
#179What a nice way to say we don't respect our engineers. They should hide in the woods with their planning skills and not post about it
Re: How meta built the infrastructure for Threads
#180Earlier quoted context omitted.
Can you share your take on why MySQL and not Postgres?
For me it's mostly about known-knowns. I've been responsible for pretty large/company-critical MySQL clusters and have managed to sleep soundly at night. I tend to be the "database guy" at every startup, and those startups tended to use MySQL. I have to say, I do love PostGIS. But for "this data absolutely cannot be lost or its game-over", I'd go MySQL every time. I can and have debugged MySQL replication on zero hou…
* undetected hard disk in array fails
* battery in array controller fails
* disk fills up
* dubious backups, with no point-in-time recovery
* extremely poorly written SQL queries
* poory configured MySQL (in oh-so-many ways)
The top three (at least) would lastly cause replication lag, which would eventually trigger an alert. ... And yet we never lost a cluster. (And we far a lot of them!)
My team sweated blood improving processes and tooling, and then I spent a 6 month stint on database clusters (switching to GTID based replication and rewriting the ops config code so that they were all consistently configured and monitored).
Occasionally we'd get a new senior hire insist that PostgreSQL was a necessity, so we'd stand back and let them produce a proof of concept that stood up to the types of failures our MySQL clusters dealt with regularly, without waking oncall up at night. And it was always a bit of a joke by comparison.