High Scalability

Build your own twitter like real time analytics - a step by step guide

Nati Shalom — Thu, 24 May 2012 16:15:31 +0000

Major social networking platforms like Facebook and Twitter have developed their own architectures for handling the need for real-time analytics on huge amounts of data. However, not every company has the need or resources to build their own Twitter-like solution.

In this example we have taken the same Twitter/Facebook-like blueprint, and made it simple enough for developers to implement. We have taken the following approach in our implementation:

Use In Memory Data Grid (XAP) for handling the real time stream data-processing.
BigData data-base (Cassandra) for storing the historical data and manage the trend analytics
Use Cloudify (cloudifysource.org) for managing and automating the deployment on private or pubic cloud

The example demonstrate a simple case of word count analytics. It uses Spring Social to plug-in to real twitter feeds. The solution is designed to efficiently cope with getting and processing the large volume of tweets. First, we partition the tweets so that we can process them in parallel, but we have to decide on how to partition them efficiently. Partitioning by user might not be sufficiently balanced, therefore we decided to partition by the tweet ID, which we assume to be globally unique. Then we need persist and process the data with low latency, and for this we store the tweets in memory.

Averages, web performance data, and how your analytics product is lying to you

Todd Hoff — Wed, 23 May 2012 16:15:46 +0000

This guest post is written by Josh Fraser, co-founder and CEO of Torbit. Torbit creates tools for measuring, analyzing and optimizing web performance.

Did you know that 5% of the pageviews on Walmart.com take over 20 seconds to load? Walmart discovered this recently after adding real user measurement (RUM) to analyze their web performance for every single visitor to their site. Walmart used JavaScript to measure their median load time as well as key metrics like their 95th percentile. While 20 seconds is a long time to wait for a website to load, the Walmart story is actually not that uncommon. Remember, this is the worst 5% of their pageviews, not the typical experience.

Pinterest Architecture Update - 18 Million Visitors, 10x Growth,12 Employees, 410 TB of Data

Todd Hoff — Mon, 21 May 2012 16:15:05 +0000

There has been an update on Pinterest: Pinterest growth driven by Amazon cloud scalability since our last post: A Short on the Pinterest Stack for Handling 3+ Million Users.

With Pinterest we see a story very similar to that of Instagram. Huge growth, lots of users, lots of data, with remarkably few employees, all on the cloud.

While it's true that both Pinterest and Instagram are not making great advances in science and technology, that is more indicator of the easy power of today's commodity environments rather than a sign of Silicon Valley's lack of innovation. The numbers are so huge and the valuations are so high we naturally want some sort of fundamental technological revolution to underlie their growth. The revolution is more subtle. It really is just that easy to attain such growth these days, if you can execute on the right idea. Get used to it. This is the new normal.

Here's what Pinterest looks like today:

Stuff The Internet Says On Scalability For May 18, 2012

Todd Hoff — Fri, 18 May 2012 16:15:15 +0000

It's HighScalability Time:

42 Billion: Netflix API Requests/Month
Quotable quotes:
- @commonlisp: Ideas from the talk: In Haskell laziness + thunks + garbage collection (GC) impede multicore scalability. Parallel GC is crucial.
- @Bulldozer0: Global state is the enemy of scalability; not only in software, but in governance.
If you've ever, as I have, felt the terror of a misplaced "rm -rf /", you'll love this story: Did Pixar accidentally delete Toy Story 2 during production? It did, the reconstruction was heroic, and parts of Toy Story 2 were lost forever.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...

Big List of 20 Common Bottlenecks

Todd Hoff — Wed, 16 May 2012 16:15:51 +0000

In Zen And The Art Of Scaling - A Koan And Epigram Approach, Russell Sullivan offered an interesting conjecture: there are 20 classic bottlenecks. This sounds suspiciously like the idea that there only 20 basic story plots. And depending on how you chunkify things, it may be true, but in practice we all know bottlenecks come in infinite flavors, all tasting of sour and ash.

One day Aurelien Broszniowski from Terracotta emailed me his list of bottlenecks, we cc’ed Russell in on the conversation, he gave me his list, I have a list, and here’s the resulting stone soup.

Russell said this is his “I wish I knew when I was younger" list and I think that’s an enriching way to look at it. The more experience you have, the more different types of projects you tackle, the more lessons you’ll be able add to a list like this. So when you read this list, and when you make your own, you are stepping through years of accumulated experience and more than a little frustration, but in each there is a story worth grokking.

Database:

DynamoDB Talk Notes and the SSD Hot S3 Cold Pattern

Todd Hoff — Mon, 14 May 2012 16:15:42 +0000

My impression of DynamoDB before attending a Amazon DynamoDB for Developers talk is that it’s the usual quality service produced by Amazon: simple, fast, scalable, geographically redundant, expensive enough to make you think twice about using it, and delightfully NoOp.

After the talk my impression has become more nuanced. The quality impression still stands. Look at the forums and you’ll see the typical issues every product has, but no real surprises. And as a SimpleDB++, DynamoDB seems to have avoided second system syndrome and produced a more elegant design.

What was surprising is how un-cloudy DynamoDB appears to be. The cloud pillars of pay for what you use and quick elastic response to bursty traffic have been abandoned, for some understandable reasons, but the result is you really have to consider your use cases before making DynamoDB the default choice.

Here are some of my impressions from the talk...

Stuff The Internet Says On Scalability For May 11, 2012

Todd Hoff — Fri, 11 May 2012 16:15:01 +0000

It's HighScalability Time:

2.5M : Erlang Concurrent Connections; 20 Billion : Urban Airship Push Notifications.
@agentdero: "You go to production with the code you have, not the code you wish you had" - Devops Rumsfeld
@PatrickMcFadin: After talking to a lot of big #aws customers tonight, the big non-secret is we'll be seeing #ssd instances soon.
Goodbye, CouchDB. Steven Hazel shares his experience report with CouchDB. Like many relationships it all started great, but reliability, performance, and maintenance problems drove him into the arms of Percona MySQL. They use MySQL in NoSQL mode and in return they get better performance and a love that never fails.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...

Paper: Paxos Made Moderately Complex

Todd Hoff — Thu, 10 May 2012 16:15:41 +0000

If you are a normal human being and find the Paxos protocol confusing, then this paper, Paxos Made Moderately Complex, is a great find. Robbert van Renesse from Cornell University has written a clear and well written paper with excellent explanations.

The Abstract:

For anybody who has ever tried to implement it, Paxos is by no means a simple protocol, even though it is based on relatively simple invariants. This paper provides imperative pseudo-code for the full Paxos (or Multi-Paxos) protocol without shying away from discussing various implementation details. The initial description avoids optimizations that complicate comprehension. Next we discuss liveness, and list various optimizations that make the protocol practical.

Cell Architectures

Todd Hoff — Wed, 09 May 2012 16:15:37 +0000

A consequence of Service Oriented Architectures is the burning need to provide services at scale. The architecture that has evolved to satisfy these requirements is a little known technique called the Cell Architecture.

A Cell Architecture is based on the idea that massive scale requires parallelization and parallelization requires components be isolated from each other. These islands of isolation are called cells. A cell is a self-contained installation that can satisfy all the operations for a shard. A shard is a subset of a much larger dataset, typically a range of users, for example.

Cell Architectures have several advantages:

Cells provide a unit of parallelization that can be adjusted to any size as the user base grows.
Cell are added in an incremental fashion as more capacity is required.
Cells isolate failures. One cell failure does not impact other cells.
Cells provide isolation as the storage and application horsepower to process requests is independent of other cells.
Cells enable nice capabilities like the ability to test upgrades, implement rolling upgrades, and test different versions of software.
Cells can fail, be upgraded, and distributed across datacenters independent of other cells.

A number of startups make use of Cell Architectures:

Tumblr: Users are mapped into cells and many cells exist per data center. Each cell has an HBase cluster, service cluster, and Redis caching cluster. Users are homed to a cell and all cells consume all posts via firehose updates. Background tasks consume from the firehose to populate tables and process requests. Each cell stores a single copy of all posts.
Flickr: Uses a federated approach where all a user’s data is stored on a shard which is a cluster of different services.
Facebook: The Messages service has as the basic building block of their system a cluster of machines and services called a cell. A cell consists of ZooKeeper controllers, an application server cluster, and a metadata store.
Salesforce: Salesforce is architected in terms of pods. Pods are self-contained sets of functionality consisting of 50 nodes, Oracle RAC servers, and Java application servers. Each pod supports many thousands of customers. If a pod fails only the users on that pod are impacted.

The key to the cell is you are creating a scalable and robust MTBF friendly service. A service than can be used as a bedrock component in a system of other services coordinated by a programmable orchestration layer. It works just as well in a data center as in a cloud. If you are looking for a higher level organization pattern, the Cell Architecture is a solid choice.

Startups Are Creating A New System Of The World For IT

High Scalability

Build your own twitter like real time analytics - a step by step guide

Averages, web performance data, and how your analytics product is lying to you

Sponsored Post: Torbit, Infragistics, Velocity, Reality Check Network, Gigaspaces, AiCache, Logic Monitor, Attribution Modeling, New Relic, AppDynamics, CloudSigma, ManageEnine, Site24x7

Who's Hiring?

Fun and Informative Events

Cool Products and Services