Re:A Look at Enterprise Performance of Intel SSDs
by jonknee on Monday February 13, 2012 @01:11PM
(#3586661)
Not to mention storing page view data in a RDBS.
Re:A Look at Enterprise Performance of Intel SSDs
by misterbwong on Monday February 13, 2012 @02:18PM
(#3586942)
What 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.
Re:A Look at Enterprise Performance of Intel SSDs
by jonknee on Monday February 13, 2012 @03:54PM
(#3587296)
NoSQL 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).
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.