3 ms·
I don’t like it either, but apparently semi-structured data is the future. It’s proving easier to build systems that tolerate bad data and broken references tha
by t8sr 3y ago
I don’t like it either, but apparently semi-structured data is the future. It’s proving easier to build systems that tolerate bad data and broken references than it is to get our data normalized and cleaned.
I’m the guy on most teams pontificating about SQL and data-oriented code, but even I’ll concede that large scale live systems probably shouldn’t serve from an SQL database.
- koliber 3y agoDo they have only one huge table in the db that contains all of their entities? From the key structure that seems reasonable: shard id, type, object id. If that is the case, is a relational db still the right place to keep such data? It seems that if the goal is to store this kind of data in one or a few huge sharded tables, a different tool could be optimizing to do the job better. It seems that I’m missing something…
- rwultsch 3y agoA pin was a 1.2 KB json blob. There were other tables but pins was the big one. Why MySQL? It did not destroy data like the alternatives. how storage became efficient https://medium.com/pinterest-engineering/evolving-mysql-compression-part-1-7f8b09666589 https://medium.com/pinterest-engineering/evolving-mysql-comp... https://medium.com/pinterest-engineering/evolving-mysql-compression-part-2-2c3eb0101205 https://medium.com/pinterest-engineering/evolving-mysql-comp...