force.com’s multi t enant architecture

36
Force.com’s Multitenant Architecture Phil Calvin, CTO UI and Mobile,salesforce.com

Upload: stan

Post on 24-Feb-2016

21 views

Category:

Documents


0 download

DESCRIPTION

Force.com’s Multi t enant Architecture. Phil Calvin, CTO UI and Mobile, salesforce.com. Safe Harbor Statement. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Force.com’s  Multi t enant  Architecture

Force.com’s Multitenant ArchitecturePhil Calvin, CTO UI and Mobile,salesforce.com

Page 2: Force.com’s  Multi t enant  Architecture

Safe Harbor Statement

“Safe harbor” statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements including but not limited to statements concerning the potential market for our existing service offerings and future offerings. All of our forward looking statements involve risks, uncertainties and assumptions. If any such risks or uncertainties materialize or if any of the assumptions proves incorrect, our results could differ materially from the results expressed or implied by the forward-looking statements we make.

The risks and uncertainties referred to above include - but are not limited to - risks associated with possible fluctuations in our operating results and cash flows, rate of growth and anticipated revenue run rate, errors, interruptions or delays in our service or our Web hosting, our new business model, our history of operating losses, the possibility that we will not remain profitable, breach of our security measures, the emerging market in which we operate, our relatively limited operating history, our ability to hire, retain and motivate our employees and manage our growth, competition, our ability to continue to release and gain customer acceptance of new and improved versions of our service, customer and partner acceptance of the AppExchange, successful customer deployment and utilization of our services, unanticipated changes in our effective tax rate, fluctuations in the number of shares outstanding, the price of such shares, foreign currency exchange rates and interest rates.

Further information on these and other factors that could affect our financial results is included in the reports on Forms 10-K, 10-Q and 8-K and in other filings we make with the Securities and Exchange Commission from time to time. These documents are available on the SEC Filings section of the Investor Information section of our website at www.salesforce.com/investor. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements, except as required by law.

Page 3: Force.com’s  Multi t enant  Architecture

True Multi-Tenancy is our Religion

Time TechnologyAdvances

BusinessModel

Changes

MajorArchitectural

Shift

Agenda

Our Religion

Virtual Database

App Model

Page 4: Force.com’s  Multi t enant  Architecture

Single tenant applications: lots of waste

App

Db

App

Db

App

Db

App

Db

Page 5: Force.com’s  Multi t enant  Architecture

Multi-tenancy benefits are self-evidentBut isolation is much easier said than done…

App

Db

Page 6: Force.com’s  Multi t enant  Architecture

Our religion: Not all “multi-tenant” designs are created equal

App

DbApp

Db

“Can’t we create a

separate stack for just this

one customer? I promise

it’s just this one…”

Page 7: Force.com’s  Multi t enant  Architecture

Introducing the Force.com metadata-driven, multi-tenant, Internet application platform

Poly-Morphic

Application

Page 8: Force.com’s  Multi t enant  Architecture

Key Architectural Principles

Stateless AppServers Database system of record No DDL All tables partitioned by OrgId Smart PKs, Polymorphic FKs Creative de-normalization and pivoting Use every RDBMS feature/trick

Page 9: Force.com’s  Multi t enant  Architecture

Metadata, data, and pivot table structures store data corresponding to virtual data structures

Page 10: Force.com’s  Multi t enant  Architecture

The Objects table stores metadata about custom objects (tables)

Page 11: Force.com’s  Multi t enant  Architecture

The Fields table stores metadata about custom fields (columns)

Page 12: Force.com’s  Multi t enant  Architecture

The Data heap table stores all structured data corresponding to custom objects

Page 13: Force.com’s  Multi t enant  Architecture

A single slot can store various types of data that originate from different objects

Page 14: Force.com’s  Multi t enant  Architecture

The Indexes pivot table manages tenant-specific selective indexes

Page 15: Force.com’s  Multi t enant  Architecture

The UniqueFields pivot table facilitates uniqueness for custom fields

Page 16: Force.com’s  Multi t enant  Architecture

The Relationships pivot table facilitates referential integrity and optimizes joins

Page 17: Force.com’s  Multi t enant  Architecture

All data & metadata structures are partitioned to improve performance and manageability

Tables hash partitioned by OrgId Separate conn pools point to physical hosts App tier is also dynamically partitioned by OrgId Distributed metadata cache w/transactional

invalidation

Page 18: Force.com’s  Multi t enant  Architecture

Application Framework: a whole lot for free

Native Declarative features Bulk Processing The Recycle Bin Full Text Search Smart Bulk DML Web Services APIs

Page 19: Force.com’s  Multi t enant  Architecture

Force.com’s native Application Framework provides declarative development, no coding

Page 20: Force.com’s  Multi t enant  Architecture

Validation rules and simple formulas:Business analysts can “code” these

Page 21: Force.com’s  Multi t enant  Architecture

Not so simple: Rollup-summary fields provide for easy cross-object summaries

Page 22: Force.com’s  Multi t enant  Architecture

Force.com’s bulk processing optimizations reduce overhead for data loads

Page 23: Force.com’s  Multi t enant  Architecture

Data definition processing is optimized to avoid performance hits or concurrency limits

Examples: Sort all records by primary key before attempting DML Operate on tables in deterministic order Slot reallocation for field datatype change Deferred calculation for new rollup-summary field Background processing of mass changes

Page 24: Force.com’s  Multi t enant  Architecture

The Recycle Bin: Smart Undeletes

Restore

Individual object instances (records)

Related object instances (parent/child records)

Entire fields and objects(dropped columns and tables)

Page 25: Force.com’s  Multi t enant  Architecture

Force.com’s full-text search engine

Asynchronously maintains indexes for all text fields

MRU caches contain recently updated objects

Optimizes ranking of search result records based on current user, modification history, and weighting preferences

Page 26: Force.com’s  Multi t enant  Architecture

Multi-tenant Query Optimization Principles

Consistent SQL generation across the application Deep awareness of pivot table structure

– Flex schema does impose a cost

Tenant, user, object, fields statistics are crucial No runaway queries allowed Deep integration with the sharing model

Page 27: Force.com’s  Multi t enant  Architecture

Force.com’s query optimizer writes optimal queries for internal data access operations

Multi-tenant optimizer statistics

Page 28: Force.com’s  Multi t enant  Architecture

The optimizer considers pre-query selectivity measurements when writing a query

Pre-Query Selectivity

Measurements

… use of index related to filter.HighHigh

… ordered hash join; drive using Data table.LowHigh

… use of index related to filter.HighLow

… nested loops join; drive using view of rows that the user can see.LowLow

Write final database access query, forcing …FilterUser

Page 29: Force.com’s  Multi t enant  Architecture

Apex: Force.com’s procedural frontier

Page 30: Force.com’s  Multi t enant  Architecture

Apex code is stored as metadata, interpreted at runtime, and cached for scalability

Page 31: Force.com’s  Multi t enant  Architecture

Apex is deeply integrated with platform features

Bulk DML Email and messaging Asynchronous processing (Futures) XmlStream / HTTP (RESTful) services classes Declarative exposure as new Web Services

Page 32: Force.com’s  Multi t enant  Architecture

Force.com governs Apex code execution

Limits on: CPU Memory # of DML statements # calculations # web service calls … and more

Page 33: Force.com’s  Multi t enant  Architecture

Unit tests must accompany Apex code

Required 75% code coverage Profiling is built into the platform Run during application install All tests are run before each

platform release by us

Page 34: Force.com’s  Multi t enant  Architecture

Force.com is a proven multi-tenant application platform that performs and scales

0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q20

250

500

750

1,000

1,250

Page Response Time (ms)

Quarterly Transactions

(billions)

2005 2006 2007Fiscal Year

Page 35: Force.com’s  Multi t enant  Architecture

Concluding Remarks

PaaS is a major architectural shiftsPaaS is Application focused, high level of abstractionForce.com is the most mature, proven PaaS offering available todayOptimized for fast, secure, and reliable multi-tenant application development and deployment

Page 36: Force.com’s  Multi t enant  Architecture

We’re hiring→ Software Engineering Architects→ Performance Engineers→ User Interface Designers→ Quality Engineers→ Technical Writers→ Product & Program Managers→ Unix Systems Engineers→ Network Engineers

Visit the #dreamjob loungeLevel 2, Alcove 3

Follow us @salesforcejobs