Overview of the Force.com multitenant architecture, given by Salesforce Chief Software Architect.
Without multi-tenancy
- Customers may not be on the same versions
- Lots of hardware, software versions
Multi-tenancy
- Data-focused platform for building data-focused applications.
- SF is expert at providing virtual database for each tenant.
SF
- Runs 10′s of thousands of tenants on one Oracle instance.
- Small number of database administrators to maintain software, hardware stock.
- All of customers running same version of their vendors and SF’s.
- Generally developers are just developing to current version and next version.
- All of customers are on the exact same schema, which is shared.
Their “Religion”:
- Have successfully avoided maintaining a separate code line for just one customer, e.g., customer doesn’t like upgrade schedule, etc. But they do all the same optimizations for all customers. Have never built a separate stack for any one customer.
Key Architectural Principles:
- Stateless AppServers
- Database system of record
- No DDL at runtime – share tables, do not build tables.
- All tables partitioned by OrgId – all physical tables partitioned on OrgId (tenant identifier). Basic part of query plan.
- Smart PK’s, Polymorphic FK’s – have special pivot tables that can be children of multiple different tables – by looking at first three characters of key.
-
Table Structure
- MetaData tables
- Data Tables
- Data – heap of all of the data in the system.
- This is the real-customer data.
- Field data is stored in the flex columns val1-val500.
- Flex columns store in textual representation
- Small penalty to this, but get great flexibility. - Series of Specialized Pivot Tables – make things work faster.
OK, so how do I query the table? Can’t put Oracle indexes on the val0 column. Table with 500 indexes would be really slow, plus different data types
Pivot Tables
- Indexes table – in addition to storing the data in the Data table, denormalize into Indexes. Each column has a real B-tree.
- Not like a basic index which Oracle optimizes. Have to have sophisticated SQL generation to lead with the Indexes table and join to Data. Report generation, etc. need to know about query optimization. Have built their own optimizer
- Unique pivot table to handle unique relationships.
- Relationships pivot table for foreign keys – forward and backward navigating.
Other Architecture
- On Oracle RAC
- Application tier knows to send queries for particular Org to particular app servers
- Any appserver can service any request for any org.
- But tend to send requests to a small set when everything is up for metadata caching.
Application Framework
- Get bulk processing, recycle bin, full text search, etc. for free.
- Examples:
- Declaratively, can track field history – auditing. Just tick checkbox.
- Formula fields – business analysts can code it.
- Rollup-summary fields – provide for easy cross-object summaries – for each parent, aggregate (sum, min, max) on children; actually synchronously maintain these summary values on the parent.
- Bulk Save Engine: All internal steps are done as bulk operations (bulk insert, etc.) but handle things like calculating sumaries, field tracking, etc. on the fly.
- If something fails on insert #2 from 100, will not rollback everything (but could).
Recycle Bin
- Allows recovery – even after commits have happened in the interim.
Full-text search
- Integrated full-text search.
- Asynchronously maintains indexes for all text fields.
- MRU caches for recently updated objects
- Optimizes ranking of search result records based on current user, mod history, etc.
Query Optimization
- Consistent SQL generation across the application.
- Aware of statistics and deep awareness of pivot table structure.
- No runaway queries allowed
- Deep integration with the sharing model (these users have access to these rows)
Apex Code
- Unit tests have to accompany
- Require 75% code coverage before are allowed to release
- When SF releases new version, they assert that all APEX tests still run.
Tags: architecture, database, force.com, salesforce, salesforce.com
I think I read once someone saying multi-tenancy was a liability that had been “spun” into an asset. From this I’m guessing it’s because the someone thought clients should be able to have something custom for them instead of forcing them to have the exact thing as everyone else.
Does that make sense, or can you see another reason this person might have commented this way?
Perhaps that, but I’m guessing that they mean more that multiple tenants in a single architecture interact with each other and have the potential to bring it down for everybody. E.g., shared Web hosting is “multi-tenant” on a single box.
So, yes, it is “spin”. But if it’s handled right with the right kind of isolation and controls, it can keep costs way down. However, the key is that it needs to be handled right. And this is why all of their indexing and unit testing code coverage requirements are so important.
Does anyone know how many instances in their RAC? Presumably it’s x86 not sparc? They claim it’s supporting 10B transactions a quarter, which if evenly spread across the day is well over 1,000/s. Are there any published figures of actual peaks they experience? I guess 2-3 times that?
It’s posts like this that keep me coming back and checking this site regularly, thanks for the info!
In brief, architects have to be a bunch more than just plain architects.