I just came across this: "Scaling Pinterest and adventures in
database sharding" (http://gigaom.com/data/scaling-pinterest-and-adventures-in-database-sharding/)
"Pinterest has learned about scaling the way most popular sites
do — the architecture works until one day it doesn’t"Pinterest
found out that "the architecture" is not scalable and they turned
to development of a Scale Out mechanism also called
Sharding.
I find it amazing that sharding, or in other words, the idea of
"scale out by splitting and parallelizing data across
shared-nothing commodity-hardware" is not supplied "out of the
box" by "the architecture" (such as database, load-balancer, any
other IT stuff). I'm wondering who was the one that
decided that an IT issue like scale-out should
be outsourced from the database to the …
Oh I love these things: http://techcrunch.com/2012/08/22/how-big-is-facebooks-data-2-5-billion-pieces-of-content-and-500-terabytes-ingested-every-day/
Every day there are 2.5B content items shares, and 2.7B "Like"s.
I care less about GiGo content itself, but metadata, connections,
relations are kept transactionally in a relational database. The
above 2 use-cases generate 5.2B transactions on the database, and
since there are only 86400 seconds a day, we get over 60000 write
transactions per second on the database, from these 2 use-cases
alone, not to mention all other use-cases, such as new profiles,
emails, queries...
And what's the size of new data, on top of all the existing …
On the 8/16 I conducted a webinar titled: "Scale Up vs. Scale
Out" (http://www.slideshare.net/ScaleBase/scalebase-webinar-816-scaleup-vs-scaleout):
ScaleBase Webinar 8.16: ScaleUp vs.
ScaleOut from ScaleBase
The webinar was successful, we had many attendees and
great participation in questions and
answers throughout the session and in the
end. Only after the webinar it only occurred to me
that one specific graphic was missing from the webinar deck. It
was occurred to me after answering
several audience questions about "the difference
between …