4 ms·
Problem with this article is they're not considering whether their write load is justifiable. Why are they writing 15x as much data as they read? Anand wrote
by lusr 15y ago
Problem with this article is they're not considering whether their write load is justifiable. Why are they writing 15x as much data as they read?
Anand wrote this in response to the question: "Statistics are pretty beefy (they are one of our enterprise workloads after all) as we're tracking requests to all articles published. Couple a few hundred thousand readers per day with multiple article requests per reader and that's a lot of traffic to keep track of."
Sure it's a lot of traffic but why do you need to write it to an SSD? That's something you can easily offload to a slow database and/or file server. And once you do, what does your write load look like? If it's dramatically lower then it means your conclusions need to be revisited.
- jonknee 15y agoNot to mention storing page view data in a RDBS.
- misterbwong 15y agoWhat is a better solution for a high traffic site than tracking page view data into an RDB? Log files other than the built in server logs? NoSql? I'm genuinely curious because my work site is currently tracking into Sql.
- jonknee 15y agoNoSQL would be what I would go for since this is the type of thing that Redis and similar excel at. Any way you can prevent writes per page view the better off you'll be. Redis gets you speeds similar to memcached but with some stuff you'd expect from a RDBS (durability, replication, etc). It's great for logging/analytics. "Each drive in the first DB server has seen around 570GB of writes in 9 days, or roughly 63GB/day. The drives in the second DB server have gone through 1.03TB of writes in the same period of time or 114GB/day." They're writing an incredible amount of data for what amounts to a fairly standard article/comment/forum site (which are typically very read heavy).