How your very large databases can work in the cloud computing world?

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Initial setup of a u-Page from toolbar 14M users today 20M users 2009Q1 600K downloads per day Moving from 1:N templates to 10-15% users that updates the page (from 1:1000 templates/users ratio to 1:7 templates/users) Statistics: user changes: 1 per week, upload: 2 times a day Wants to use the default if the user did not modified the template. However, wants to support pushed changes from templates to users pages, even if those were changed Have the same situation now, but now it’s saved on the users desktop Current applicative cache: - int: toolbar_id, list of int: widget_id[] - int: widget_id, object: widget - int: user_id, object: user Table design: - User id, tab id and user_tab_id are GUID – meaning that they can be distributed between databases - Other are not (may be needed to support?) - Expected XML scheme size: 45KB (up to 500KB) Why migration to MySQL will be problematic (they are already using the current SQL Server SP features): - Maximal row size * http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html * The maximum row length, except for VARBINARY , VARCHAR , BLOB and TEXT columns, is slightly less than half of a database page. That is, the maximum row length is about 8000 bytes - Scope identity - For XML - Bulk Insert from XML - Rollback/Transaction - BEGIN TRY Applicative changes by the user: - Move - Delete - Add - Minimize - Change internal parameters Options to be considered: - SQL Server based large machine - Sharding based on MySQL, SQL Server - Gigaspaces solution: felt that it’s a large machine, and they prefer the database way Other options - Saving only XML in the current way - Save the summed page configuration in an XML, so little read should be done from the DB (Tab based) - Write 20K files of 40KB each on the my laptop HD: 149s - Read XML: 109.5s - Write to DB: 1789s Use serialization of .Net - Save the XML on the disk in order to avoid variable length fields - Use memcached to hold the hash of users? Things to be considered: - What horizontal sharding algorithm should be selected - Hibernate Shards – provided by Google. Still beta-testing phase - What vertical sharding tables should be spitted to different databases - How do you manage so many databases (distribute data and so on) - There is not really an option to do that - Defining optimal table sizes - Retrieval of data from the disk vs. Getting data from the tables: Tab (1 per displayed page), Zone (3 per displayed page), Widget instance (10-300 per displayed page + should be extracted with/out zones) - OLAP solution to merge data OLAP solution Toolbar design: - Saving

    1 Favorite

    How your very large databases can work in the cloud computing world? - Presentation Transcript

    1. Database and the Cloud IGT Cloud Computing WG 20/4/2009 [email_address] http://top-performance.blogspot.com
    2. RockeTier Methodology
      • RockeTier specializes in analyzing and boosting existing software performance and developing efficient high-load systems with a unique methodology:
      • Detect
      • Rate
      • Immediate Effective Relief
      • Roadmap
      • Scale up and Scale out
    3. Assumptions
      • Cloud Computing  Virtualization
      • Virtualization  Low end servers
      • Very large databases  High end servers
      • Therefore:
        • Very large databases ≠ Cloud Computing
    4. Assumptions…
    5. Major Options
    6. Presentation Objectives
      • Who is using MySQL?
      • MySQL Limitations
      • How to get over this?
        • Move to another DB and scale up…
        • Vertical Sharding
        • Horizontal Sharding
      • Sharding test case
    7. Who is Using MySQL?
    8. MySQL Limitations
      • Table sizes: 50-100M records per table
      • Reads: 50 queries/second
    9. Why Do I Care?
      • From 0 to 100 (US mass adaptation)
        • Phone: 100 yrs
        • Radio: 40 yrs
        • TV: 30 yrs
        • Mobile: 20 yrs
        • Internet: 10 yrs
        • Facebook: 2 yrs
    10. 100K New Users/Week
    11. The Network Effect
    12. What Should I Do?
      • Oracle
      • SQL Server
      • $$$
    13. Sharding
    14. Vertical Sharding
    15. Horizontal Sharding
      • Static Hashing
        • Complex growth
        • Simple
      Mod 10 = 0 Mod 10 = 1 Mod 10 = 2 Mod 10 = 3 Mod 10 = 4 Mod 10 = 5 Mod 10 = 6 Mod 10 = 7 Mod 10 = 8 Mod 10 = 9
      • Key locations are defined in a directory
        • Simple growth
        • Directory is SPOF
      Horizontal Sharding
    16. Horizontal Sharding
      • Static hashing with directory mapping
        • Simple growth
        • Small Directory still SPOF
      Mod 1000 = 4
    17. Horizontal Sharding
      • Each key signed by DB# generated on creation
        • Simple growth
        • New key generation is SPOF
    18. Sharding Management
      • No mature tools in the market
      • Hibernate Shards – not recommended
        • Hibernate…
        • Beta
      • Required Mechanisms
        • Distribution of changes in DB schema
    19. Reporting
    20. Best Practices
      • $connection = new_db_connection (" customer :// 1234 ") ;
      • $statement = $connection->prepare( $sql_statement, $params );
      • $result = $statement->execute();
    21. Lessons
      • Vertical Sharding:
        • User Actions, Users, Comments, Items
      • Horizontal Sharding
      • Denormalization
      • MySQL Replication
    22. Lessons
      • Vertical Sharding:
        • User Actions, Users, Comments, Items
      • Horizontal Sharding
      • Denormalization
      • MySQL Replication
    23. Lessons
      • 100M views per day
      • The path to Sharding:
        • Single server
        • Single master with multiple read slaves
        • Partitioned
        • Sharding
    24. Lessons
      • Master-Master replication
      • Each Shard is 50% loaded
      • 40K queries/second
    25. Ad Network Reference Architecture
    26. The Bottom Line: Grow ∞
    27. Startup your Engines Thank you [email_address] http://top-performance.blogspot.com Our Methodology Performance problems are extremely complex and due to the diferent technologies deployed, each case is unique. A “typical” performance problem requires delving into databases, application servers, client technology, code in difering programming languages and system and software architectures. RockeTier implements a unique methodology in order to simplify the problem and evaluate each performance bottleneck, providing both an immediate efective relief and when necessary, design a gradual roadmap to speed up your software system and make it scalable and robust. Our 5 steps methodology : 1. Detect: Pinpoint your performance bottlenecks using various tools including load and stress tools, code profiling, database profiling, network sniffing and code review to detect performance bottlenecks in specific components. 2. Rate: Grade each bottleneck by importance and provide immediate practical recommendations and performance boost estimations. 3. Immediate effective relief: Provide immediate fixes and workarounds in a short time frame helping you meet your urgent business needs. 4. Roadmap Planning: When necessary, redesign next generation Solutions, using proven robust and scalable solutions such as grid and in memory databases. 5. Scale up and Scale out: In cases where redesign is necessary - RockeTier provides implementation or software design description (SDD), and guidance for in house programmers for the implementation of the next generation scalable system, which will meet your growing business needs. Your Value Business: Achieve your business performance requirements. GreenIT: Protect the environment and reduce CO2 emissions. Bottom Line: Reducing hardware and 3rd party software cost. The Performance Experts Success Stories The Finance Sector: An international insurance company managing over 20 Billion US dollars in assets was facing poor performance in its core life insurance policy software system. The RockeTier team detected bottlenecks originating from several software infrastructure modules. A practical solution was implemented. The customer’s success criteria was a 20% decrease in insurance policy creation run time, Our solution provided a 40% decrease in run time! Telecom: A VC backed start-up company was facing critical installation problems in the leading Israeli cellular operator. Knowing that existing system performance would not meet client requirements, the company asked RockeTier to help it boost its performance. RockeTier evaluated the system and implemented a workaround to the system database architecture, boosting the overall system performance by 30%. Following that. the RockeTier team designed the company’s next generation architecture, meeting a throughput of 3000Mbps by design. RockeTier at a Glance RockeTier is a software solutions company, which utilizes its knowledge and skills to help companies from both the enterprise sector and the start-up industry. RockeTier has numerous success stories in solving customers’ system performance bottlenecks and scale out limitations, providing immediate improvements and workarounds in a short time frame and, when necessary, redesign and implementation of the next generation solutions employing grid and/or in- memory databases in the Web 2.0, Telecom and finance markets. Web 2.0: a start-up company providing an innovative electronic advertising and billing system was facing its technological limits. The RockeTier team evaluated and redesigned its system architecture and is currently implementing a scale out grid mechanism and caching algorithms. The solution supports 20 times the original capacity using the same hardware. Moreover it supports semi-linear growth (by simple scale out) and high availability requirements. “ 20% reduction in transaction time within 3 months” “ Boost Performance by a factor of 200” “ 200 million events per day”

    + Moshe KaplanMoshe Kaplan, 7 months ago

    custom

    842 views, 1 favs, 2 embeds more stats

    How your very large databases can work in the cloud more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 842
      • 807 on SlideShare
      • 35 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 0
    Most viewed embeds
    • 34 views on http://top-performance.blogspot.com
    • 1 views on http://top-performance.blogspot.com:80

    more

    All embeds
    • 34 views on http://top-performance.blogspot.com
    • 1 views on http://top-performance.blogspot.com:80

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories