high_scalability high_scalability-2010 high_scalability-2010-950 knowledge-graph by maker-knowledge-mining
Source: html
Introduction: In many of the recent discussions on the design of large scale systems (a.k.a. Web Scale) it was argued that the right set of tradeoffs for building large scale systems would be to give away C onsistency for A vailability and P artition tolerance. Those arguments relied on the foundation of the CAP theorem developed in early 2000-2002. One of the core principals behind the CAP theorem is that you must choose two out of the three CAP properties. In many of the transactional systems giving away consistency is either impossible or yields a huge complexity in the design of those systems. In this series of posts, I've tried to suggest a different set of tradeoffs in which we could achieve scalability without compromising on consistency. I also argued that rather than choosing only two out of the three CAP properties we could choose various degrees of all three. The degrees would be determined by the most likely availability and partition tolerance scenarios in our specific application.
sentIndex sentText sentNum sentScore
1 In many of the recent discussions on the design of large scale systems (a. [sent-1, score-0.564]
2 Web Scale) it was argued that the right set of tradeoffs for building large scale systems would be to give away C onsistency for A vailability and P artition tolerance. [sent-4, score-0.987]
3 Those arguments relied on the foundation of the CAP theorem developed in early 2000-2002. [sent-5, score-0.57]
4 One of the core principals behind the CAP theorem is that you must choose two out of the three CAP properties. [sent-6, score-0.472]
5 In many of the transactional systems giving away consistency is either impossible or yields a huge complexity in the design of those systems. [sent-7, score-0.853]
6 In this series of posts, I've tried to suggest a different set of tradeoffs in which we could achieve scalability without compromising on consistency. [sent-8, score-0.748]
7 I also argued that rather than choosing only two out of the three CAP properties we could choose various degrees of all three. [sent-9, score-1.078]
8 The degrees would be determined by the most likely availability and partition tolerance scenarios in our specific application. [sent-10, score-0.892]
9 The suggested model was based on the experience we had in GigaSpaces over the course of the past years and was successfully deployed in many mission critical systems today in Finance, Telco and ecommerce business. [sent-11, score-0.928]
10 I hope that through the sharing of this experience we could come up with a broader set of patterns on how to build large scale systems that would fit also to mission critical transactional systems. [sent-12, score-1.488]
wordName wordTfidf (topN-words)
[('cap', 0.358), ('degrees', 0.286), ('argued', 0.28), ('theorem', 0.225), ('tradeoffs', 0.219), ('mission', 0.189), ('transactional', 0.159), ('partition', 0.152), ('telco', 0.147), ('compromising', 0.147), ('choose', 0.146), ('critical', 0.136), ('relied', 0.13), ('systems', 0.128), ('broader', 0.128), ('arguments', 0.118), ('consistency', 0.118), ('determined', 0.117), ('suggested', 0.117), ('yields', 0.115), ('discussions', 0.11), ('finance', 0.108), ('suggest', 0.107), ('set', 0.106), ('ecommerce', 0.106), ('away', 0.102), ('three', 0.101), ('scale', 0.101), ('foundation', 0.097), ('successfully', 0.094), ('gigaspaces', 0.093), ('choosing', 0.092), ('tolerance', 0.09), ('scenarios', 0.089), ('availability', 0.088), ('properties', 0.087), ('could', 0.086), ('large', 0.083), ('tried', 0.083), ('experience', 0.082), ('impossible', 0.081), ('posts', 0.078), ('giving', 0.078), ('deployed', 0.076), ('hope', 0.076), ('sharing', 0.072), ('design', 0.072), ('patterns', 0.072), ('recent', 0.07), ('would', 0.07)]
simIndex simValue blogId blogTitle
same-blog 1 0.99999988 950 high scalability-2010-11-30-NoCAP – Part III – GigaSpaces clustering explained..
Introduction: In many of the recent discussions on the design of large scale systems (a.k.a. Web Scale) it was argued that the right set of tradeoffs for building large scale systems would be to give away C onsistency for A vailability and P artition tolerance. Those arguments relied on the foundation of the CAP theorem developed in early 2000-2002. One of the core principals behind the CAP theorem is that you must choose two out of the three CAP properties. In many of the transactional systems giving away consistency is either impossible or yields a huge complexity in the design of those systems. In this series of posts, I've tried to suggest a different set of tradeoffs in which we could achieve scalability without compromising on consistency. I also argued that rather than choosing only two out of the three CAP properties we could choose various degrees of all three. The degrees would be determined by the most likely availability and partition tolerance scenarios in our specific application.
2 0.20175262 921 high scalability-2010-10-18-NoCAP
Introduction: In this post i wanted to spend sometime on the CAP theorem and clarify some of the confusion that i often see when people associate CAP with scalability without fully understanding the implications that comes with it and the alternative approaches You can read the full article here
3 0.17462878 926 high scalability-2010-10-24-Hot Scalability Links For Oct 24, 2010
Introduction: On a cold and rainy Fall day, a day stolen from winter rather than our usual gorgeous Indian Summers , a day not even the SF Giants winning the pennant can help warm, here are some hot links to read by a digital flame: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server by Yoshinori Matsunobu. Wonderfully detailed post on how you can lookup a row by ID really fast if you bypass all the typical MySQL query parsing overhead. Minecraftwiki.net and minecraftforum.net now serve more traffic than Slashdot and Stackoverflow! 1 million pageviews and 100k uniques per day, per site; 10TB of bandwidth a month; 4+ machines running Varnish, HAProxy, PHP, MySQL, Nginx. Stuff the Internet Says: @ old_sound : Somebody make me a t-shirt that says "I've read the CAP theorem and I liked it" @dscape : How relevant do I think the CAP theorem is? Not at all. I honestly hate conversations where anyone talks about crap.. cap, sorry. @humidbei
4 0.1470719 658 high scalability-2009-07-17-Against all the odds
Introduction: This article not about Mariah Carey, or its song. It's about Storing System, Database. First let's describe what means by odds: In my social network, I found 93% of the mainstream developers sanctify the database, or at least consider it in any data persistence challenge as the ultimate, superhero, and undefeatable solution. I think this problem come from the education, personally, and some companies also I think it's involved in this. To start to fix this bad thinking, we all should agree in the following points: Every challenge have its own solutions, so whatever you want to save/persistent, there are always many solutions. For example the Web search engines, such as: Google, Kngine, Yahoo, Bing don't use database at all instead we use Indexes (Index file) for better performance. The Database in general whatever the vendor it's slow compared with other solutions such as: Key-Value storing system, Index file, DHT. The Database currently employ Relation Data model
5 0.13063748 96 high scalability-2007-09-18-Amazon Architecture
Introduction: This is a wonderfully informative Amazon update based on Joachim Rohde's discovery of an interview with Amazon's CTO. You'll learn about how Amazon organizes their teams around services, the CAP theorem of building scalable systems, how they deploy software, and a lot more. Many new additions from the ACM Queue article have also been included. Amazon grew from a tiny online bookstore to one of the largest stores on earth. They did it while pioneering new and interesting ways to rate, review, and recommend products. Greg Linden shared is version of Amazon's birth pangs in a series of blog articles Site: http://amazon.com Information Sources Early Amazon by Greg Linden How Linux saved Amazon millions Interview Werner Vogels - Amazon's CTO Asynchronous Architectures - a nice summary of Werner Vogels' talk by Chris Loosley Learning from the Amazon technology platform - A Conversation with Werner Vogels Werner Vogels' Weblog - building scalable and robus
6 0.12664498 954 high scalability-2010-12-06-What the heck are you actually using NoSQL for?
7 0.12222917 787 high scalability-2010-03-03-Hot Scalability Links for March 3, 2010
9 0.10434697 625 high scalability-2009-06-10-Managing cross partition transactions in a distributed KV system
10 0.10410367 1450 high scalability-2013-05-01-Myth: Eric Brewer on Why Banks are BASE Not ACID - Availability Is Revenue
11 0.096416511 1031 high scalability-2011-04-28-PaaS on OpenStack - Run Applications on Any Cloud, Any Time Using Any Thing
12 0.096142031 1374 high scalability-2012-12-18-Georeplication: When Bad Things Happen to Good Systems
13 0.095270291 816 high scalability-2010-04-28-Elasticity for the Enterprise -- Ensuring Continuous High Availability in a Disaster Failure Scenario
14 0.093250081 879 high scalability-2010-08-12-Think of Latency as a Pseudo-permanent Network Partition
15 0.092315152 793 high scalability-2010-03-10-Saying Yes to NoSQL; Going Steady with Cassandra at Digg
16 0.08950901 754 high scalability-2009-12-22-Incremental deployment
17 0.087009981 1146 high scalability-2011-11-23-Paper: Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS
18 0.084092632 877 high scalability-2010-08-12-Designing Web Applications for Scalability
19 0.080383971 1180 high scalability-2012-01-24-The State of NoSQL in 2012
20 0.08004301 687 high scalability-2009-08-24-How Google Serves Data from Multiple Datacenters
topicId topicWeight
[(0, 0.129), (1, 0.05), (2, 0.002), (3, 0.064), (4, 0.028), (5, 0.048), (6, -0.033), (7, -0.037), (8, -0.024), (9, -0.012), (10, -0.009), (11, 0.051), (12, -0.067), (13, -0.005), (14, 0.022), (15, 0.015), (16, 0.088), (17, -0.035), (18, 0.023), (19, -0.01), (20, 0.071), (21, 0.032), (22, -0.032), (23, -0.021), (24, -0.057), (25, -0.065), (26, -0.01), (27, -0.014), (28, 0.007), (29, -0.011), (30, 0.052), (31, 0.013), (32, -0.007), (33, 0.06), (34, -0.053), (35, -0.003), (36, -0.036), (37, 0.015), (38, 0.026), (39, 0.033), (40, 0.037), (41, 0.001), (42, 0.022), (43, -0.049), (44, 0.001), (45, 0.016), (46, 0.042), (47, -0.019), (48, -0.009), (49, -0.055)]
simIndex simValue blogId blogTitle
same-blog 1 0.95768338 950 high scalability-2010-11-30-NoCAP – Part III – GigaSpaces clustering explained..
Introduction: In many of the recent discussions on the design of large scale systems (a.k.a. Web Scale) it was argued that the right set of tradeoffs for building large scale systems would be to give away C onsistency for A vailability and P artition tolerance. Those arguments relied on the foundation of the CAP theorem developed in early 2000-2002. One of the core principals behind the CAP theorem is that you must choose two out of the three CAP properties. In many of the transactional systems giving away consistency is either impossible or yields a huge complexity in the design of those systems. In this series of posts, I've tried to suggest a different set of tradeoffs in which we could achieve scalability without compromising on consistency. I also argued that rather than choosing only two out of the three CAP properties we could choose various degrees of all three. The degrees would be determined by the most likely availability and partition tolerance scenarios in our specific application.
2 0.77030241 963 high scalability-2010-12-23-Paper: CRDTs: Consistency without concurrency control
Introduction: For a great Christmas read forget The Night Before Christmas , a heart warming poem written by Clement Moore for his children, that created the modern idea of Santa Clause we all know and anticipate each Christmas eve. Instead, curl up with a some potent eggnog , nog being any drink made with rum, and read CRDTs: Consistency without concurrency control  by Mihai Letia, Nuno Preguiça, and Marc Shapiro, which talks about CRDTs (Commutative Replicated Data Type), a data type whose operations commute when they are concurrent . From the introduction, which also serves as a nice concise overview of distributed consistency issues: Shared read-only data is easy to scale by using well-understood replication techniques. However, sharing mutable data at a large scale is a difficult problem, because of the CAP impossibility result [5]. Two approaches dominate in practice. One ensures scalability by giving up consistency guarantees, for instance using the Last-Writer-Wins (LWW) approach [
3 0.76622665 921 high scalability-2010-10-18-NoCAP
Introduction: In this post i wanted to spend sometime on the CAP theorem and clarify some of the confusion that i often see when people associate CAP with scalability without fully understanding the implications that comes with it and the alternative approaches You can read the full article here
Introduction: Abstract: When designing distributed web services, there are three properties that are commonly desired: consistency, availability, and partition tolerance. It is impossible to achieve all three. In this note, we prove this conjecture in the asynchronous network model, and then discuss solutions to this dilemma in the partially synchronous model.
5 0.76418889 890 high scalability-2010-09-01-Paper: The Case for Determinism in Database Systems
Introduction: Can you have your ACID cake and eat your distributed database too? Yes explains Daniel Abadi, Assistant Professor of Computer Science at Yale University, in an epic post, The problems with ACID, and how to fix them without going NoSQL , coauthored with Alexander Thomson , on their paper The Case for Determinism in Database Systems . We've already seen VoltDB offer the best of both worlds, this sounds like a completely different approach. The solution, they propose, is: ...an architecture and execution model that avoids deadlock, copes with failures without aborting transactions, and achieves high concurrency. The paper contains full details, but the basic idea is to use ordered locking coupled with optimistic lock location prediction, while exploiting deterministic systems' nice replication properties in the case of failures. The problem they are trying to solve is: In our opinion, the NoSQL decision to give up on ACID is the lazy solution to these scala
6 0.74441236 1374 high scalability-2012-12-18-Georeplication: When Bad Things Happen to Good Systems
8 0.73434007 625 high scalability-2009-06-10-Managing cross partition transactions in a distributed KV system
9 0.73359895 507 high scalability-2009-02-03-Paper: Optimistic Replication
10 0.7181021 1450 high scalability-2013-05-01-Myth: Eric Brewer on Why Banks are BASE Not ACID - Availability Is Revenue
11 0.70968354 1459 high scalability-2013-05-16-Paper: Warp: Multi-Key Transactions for Key-Value Stores
12 0.69968021 676 high scalability-2009-08-08-Yahoo!'s PNUTS Database: Too Hot, Too Cold or Just Right?
13 0.69041711 1146 high scalability-2011-11-23-Paper: Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS
14 0.68868202 1273 high scalability-2012-06-27-Paper: Logic and Lattices for Distributed Programming
15 0.68135566 1153 high scalability-2011-12-08-Update on Scalable Causal Consistency For Wide-Area Storage With COPS
16 0.65736765 1463 high scalability-2013-05-23-Paper: Calvin: Fast Distributed Transactions for Partitioned Database Systems
17 0.65442538 1544 high scalability-2013-11-07-Paper: Tempest: Scalable Time-Critical Web Services Platform
18 0.65001577 474 high scalability-2008-12-21-The I.H.S.D.F. Theorem: A Proposed Theorem for the Trade-offs in Horizontally Scalable Systems
19 0.6439026 757 high scalability-2010-01-04-11 Strategies to Rock Your Startup’s Scalability in 2010
20 0.64158779 844 high scalability-2010-06-18-Paper: The Declarative Imperative: Experiences and Conjectures in Distributed Logic
topicId topicWeight
[(1, 0.165), (2, 0.225), (30, 0.056), (47, 0.023), (58, 0.128), (61, 0.168), (79, 0.059), (85, 0.069)]
simIndex simValue blogId blogTitle
same-blog 1 0.93717808 950 high scalability-2010-11-30-NoCAP – Part III – GigaSpaces clustering explained..
Introduction: In many of the recent discussions on the design of large scale systems (a.k.a. Web Scale) it was argued that the right set of tradeoffs for building large scale systems would be to give away C onsistency for A vailability and P artition tolerance. Those arguments relied on the foundation of the CAP theorem developed in early 2000-2002. One of the core principals behind the CAP theorem is that you must choose two out of the three CAP properties. In many of the transactional systems giving away consistency is either impossible or yields a huge complexity in the design of those systems. In this series of posts, I've tried to suggest a different set of tradeoffs in which we could achieve scalability without compromising on consistency. I also argued that rather than choosing only two out of the three CAP properties we could choose various degrees of all three. The degrees would be determined by the most likely availability and partition tolerance scenarios in our specific application.
2 0.92526448 587 high scalability-2009-05-01-FastBit: An Efficient Compressed Bitmap Index Technology
Introduction: Data mining and fast queries are always in that bin of hard to do things where doing something smarter can yield big results. Bloom Filters are one such do it smarter strategy, compressed bitmap indexes are another. In one application "FastBit outruns other search indexes by a factor of 10 to 100 and doesn’t require much more room than the original data size." The data size is an interesting metric. Our old standard b-trees can be two to four times larger than the original data. In a test searching an Enron email database FastBit outran MySQL by 10 to 1,000 times. FastBit is a software tool for searching large read-only datasets. It organizes user data in a column-oriented structure which is efficient for on-line analytical processing (OLAP), and utilizes compressed bitmap indices to further speed up query processing. Analyses have proven the compressed bitmap index used in FastBit to be theoretically optimal for one-dimensional queries. Compared with other optimal indexing me
3 0.91706318 423 high scalability-2008-10-19-Alternatives to Google App Engine
Introduction: One particularly interesting EC2 third party provider is GigaSpaces with their XAP platform that provides in memory transactions backed up to a database. The in memory transactions appear to scale linearly across machines thus providing a distributed in-memory datastore that gets backed up to persistent storage.
4 0.91177326 626 high scalability-2009-06-10-Paper: Graph Databases and the Future of Large-Scale Knowledge Management
Introduction: Relational databases, document databases, and distributed hash tables get most of the hype these days, but there's another option: graph databases. Back to the future it seems. Here's a really interesting paper by Marko A. Rodriguez introducing the graph model and it's extension to representing the world wide web of data. Modern day open source and commercial graph databases can store on the order of 1 billion relationships with some databases reaching the 10 billion mark. These developments are making the graph database practical for applications that require large-scale knowledge structures. Moreover, with the Web of Data standards set forth by the Linked Data community, it is possible to interlink graph databases across the web into a giant global knowledge structure. This talk will discuss graph databases, their underlying data model, their querying mechanisms, and the benefits of the graph data structure for modeling and analysis.
5 0.90968084 998 high scalability-2011-03-03-Stack Overflow Architecture Update - Now at 95 Million Page Views a Month
Introduction: A lot has happened since my first article on the Stack Overflow Architecture . Contrary to the theme of that last article, which lavished attention on Stack Overflow's dedication to a scale-up strategy, Stack Overflow has both grown up and out in the last few years. Stack Overflow has grown up by more then doubling in size to over 16 million users and multiplying its number of page views nearly 6 times to 95 million page views a month. Stack Overflow has grown out by expanding into the Stack Exchange Network , which includes Stack Overflow, Server Fault, and Super User for a grand total of 43 different sites. That's a lot of fruitful multiplying going on. What hasn't changed is Stack Overflow's openness about what they are doing. And that's what prompted this update. A recent series of posts talks a lot about how they've been handling their growth: Stack Exchange’s Architecture in Bullet Points , Stack Overflow’s New York Data Center , Designing For Scalability of Manageme
6 0.90792465 856 high scalability-2010-07-12-Creating Scalable Digital Libraries
7 0.90616077 1089 high scalability-2011-07-29-Stuff The Internet Says On Scalability For July 29, 2011
8 0.90341789 235 high scalability-2008-02-02-The case against ORM Frameworks in High Scalability Architectures
9 0.90084249 931 high scalability-2010-10-28-Notes from A NOSQL Evening in Palo Alto
10 0.90069818 1399 high scalability-2013-02-05-Ask HighScalability: Memcached and Relations
11 0.89924908 1074 high scalability-2011-07-06-11 Common Web Use Cases Solved in Redis
12 0.89908814 685 high scalability-2009-08-20-Dependency Injection and AOP frameworks for .NET
14 0.89767075 1191 high scalability-2012-02-13-Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter
15 0.89707547 1461 high scalability-2013-05-20-The Tumblr Architecture Yahoo Bought for a Cool Billion Dollars
16 0.8970753 1440 high scalability-2013-04-15-Scaling Pinterest - From 0 to 10s of Billions of Page Views a Month in Two Years
17 0.89706111 1031 high scalability-2011-04-28-PaaS on OpenStack - Run Applications on Any Cloud, Any Time Using Any Thing
18 0.89699763 1538 high scalability-2013-10-28-Design Decisions for Scaling Your High Traffic Feeds
19 0.89692765 1609 high scalability-2014-03-11-Building a Social Music Service Using AWS, Scala, Akka, Play, MongoDB, and Elasticsearch
20 0.89673018 150 high scalability-2007-11-12-Slashdot Architecture - How the Old Man of the Internet Learned to Scale