3 ms·
Yes because finding ways to not insert a new row for each tweet is a classic sign of someone not thinking. From the UI Twitter only shows tweets to the minute
by taligent 14y ago
Yes because finding ways to not insert a new row for each tweet is a classic sign of someone not thinking.
From the UI Twitter only shows tweets to the minute so you could imagine that there is an optimisation there for merging retweets with the same text within a 60 second period.
- deleted 14y ago[deleted]
- pyre 14y agoAssume they normalized the timestamp, and only stored something on the level of "these people tweeted/retweeted this message sometime during this 60 second interval." The only way to avoid adding a new row per account that tweeted/retweeted would be to store the list of account in a single row, and keep updating it on every re-tweet. This seems like it would be a less than optimal solution.
- andrewcooke 14y agoit certainly seems like you would need to aggregate keys somewhere (if it's not the typo i assumed). that might just be possible in postgres these days (update: a quick google suggests it's in development for 9.3), but i am pretty sure not in mysql. on the other hand, for all i know, at this scale, they may be treating mysql as some kind of distributed hashtable and doing a lot more work in higher layers... [update: I completely screwed up the maths; looks like this is not rows per tweet, but support data.]
- pyre 14y ago> for all i know, at this scale, they may be treating > mysql as some kind of distributed hashtable and doing > a lot more work in higher layers... If MySQL is just used as hash table, and all of the interesting stuff happens at higher layers, then talking about the number of rows isn't that meaningful.