Several things have changed in SharePoint 2010 Query. Query infrastructure is also componentized so now you only provision what you need. This blog will go through will define the query components, how they work together, and how to provision them.
Special shout-out goes to Jon Waite for his valuable technical input\review…
Query Basics
Just like crawl, Query has been componentized as well and the following goals are met:
Query Flow
4. WFE displays search results to the user
Several Query components can be scaled out as an index\property store grows. A single search service application can have multiples of the following:
Query Component and Property Store DB
I’ll use Query server and Query Component interchangeably throughout the blog. A Query Server is a server that runs one or more Query Components. These servers hold a full or partial of the search index. Query Servers are now the sole owner of storing the index on the file system. As stated from previous post, the indexer crawls content and builds a temporary index. The Indexer propagates portions of the temporary index over to Query Server to be indexed. Query Servers contain a copy of the entire or partial index referred to as an Index Partition. Query components run under the context of an Index partition. Query components are responsible for serving search queries. Query component runs under MSSearch.exe. A query component is mapped to only one Property Store DB. By now, you should’ve noticed that we split up the databases (For Example: Property Store DB and Crawl DB). By separating these databases the following has been accomplished:
Also, by carving out the databases, performance hits like writing crawled data to Crawl Store DB won’t affect tasks like serving Queries “query performance” which heavily depends on the Property Store DB.
It’s possible to provision multiple Property Store databases and Query components for a single Search service application. The reasons for doing this are plentiful and most of the reasoning will be explained throughout this post. Query components can be provisioned to partition an index and\or mirror an index in order to provide fault tolerance. Both of these components can be created by using either Central Administrator or PowerShell. To simplify things a bit I’ll cover how to do it in Central Administrator. In order to make changes to the Search topology, you must access the Search Administration page via the following:
Central Administrator\Application Management\Manage Service Applications\Select Search Service Application and select Manage from Ribbon
Scroll to the bottom of the page and this is where you can view\change the search topology.
Provisioning happens in 3 stages:
Fault tolerance + Performance
Query Component (Fault tolerance)
It’s highly recommended to create fault tolerance with your index. This is accomplished by mirroring a Query component assigned to a different server. Under the Search Application Topology, you can simply select the Query Component and Add mirror:
The end result is a second query component within the same Index Partition.
Note: The Query Processor will distribute requests across both Query Components.
Question: I don’t want Queries being served by one of my mirrored Query Components.
Answer: On the Add mirror query component page, you can check the following option:
This doesn’t eliminate the failover query component from receiving queries. The Query Processor will prefer Query Components not marked as fail over (active). If all active Query Components are down, then Query Processor will submit requests to Query Components flagged as fail over.
Property Store (Fault tolerance)
We fully support SQL mirroring to achieve fault tolerance with Property Store DB’s on the backend.
Query Component (Performance)
In previous builds of SharePoint, every query server stored the entire index. While this achieved fault tolerance it didn’t help with performance. There is a direct correlation between the size of an index and query latency. The size of an index can easily become a bottleneck for query performance.
For Example:
This problem has been solved in SharePoint 2010. Index partition can contain the entire index or a portion of the index. By creating additional query components, a new index partition is created and owns a portion of the index.
If the entire index is 8 GB and contains 20 million documents:
Holds 50%: 4GB of index\10 million documents: Query Server 1 - Index Partition 1
Holds 50%: 4GB of index\10 million documents: Query Server 2 - Index Partition 2
By partitioning large indexes, query times are reduced and a solution to this type of bottleneck can be solved. Partitioning an index is as simple as provisioning new Query Components from the Search Application Topology section in Central Administrator.
Question: If an index is partitioned out with multiple Query Components, how does the crawler distribute the indexed content?
Answer: The crawler evenly distributes crawled content to Index Partitions using a hash algorithm based on Doc ID’s.
Property Store DB (Performance)
Just like Query components, Property Store DB can be scaled out and share the load of the metadata stored in the Property Store DB. If the Property Store DB becomes a bottleneck due to the size of the database and\or strains the disk subsystem with high I/O latency on the back end, a new Property Store DB can be provisioned to share the load. Just like the Crawl DB, the Property Store DB is useless unless it’s mapped to something. In this case, a Property Store DB must be mapped to a Query component. If a decision is made to provision an additional Property Store DB to boost performance, an additional non-mirrored Query Component must be provisioned and mapped to it.
The following is a true statement:
“Creating an additional Property Store DB requires the Index to be partitioned off because provisioning a new Query Component is required”.
Query Processor
Great, so understanding Property Store DB and Query component scale out is only half of the battle. The Query Processor remains and still plays a vital role in Search 2010. The Query processor is responsible for processing a Query and runs under w3wp.exe process. It retrieves results from Property Store DB and the Index\Query Components. Once results are retrieved, they are packaged\security trimmed and delivered back to the requester which is the WFE that initiated the request. The Query Processor will load balance request if more than one Query Component (mirrored) exists within the same Index Partition. The exception to this rule is if one of the Query Component’s is marked as fail over only.
Question: What if I partitioned off my index and I have multiple Query Components provisioned each serving a partition of the index? How does Query Processor know which partition to connect to in order to accurately retrieve results?
Answer: It doesn’t! The Query Processor will connect to every single non-mirrored Query component that contains a partition of the Index to retrieve results.
Question: What if I created multiple Property Store Databases for performance reasons? How does Query Processor know which Property store to connect to in order to accurately retrieve results?
Answer: It doesn’t! The Query Processor will connect to every single Property Store DB to retrieve results.
In SharePoint 2007, the Query Processor ran on any WFE. In SharePoint 2010, any server can run the Query Processor. It’s no longer tied into a server running the Query role. You provision Query Processor role on a server by performing the following steps:
Note: Post provision a new web service is created within IIS on that server.
Query Processor Scale Out
Just like the Query Component and Property Store DB, the Query Processor role can be scaled out to multiple servers. If the Query Processor is a bottleneck, For Example:
· Not able to keep up with inbound requests or perhaps the box and/or associated W3WP.exe process hosting Query Processor is CPU\Memory bound.
In this case, you provision additional Query Processors as needed. By provisioning additional query processors, requests will be load balanced in a round robin fashion to each server hosting a Query Processor.
The same case can be made for achieving fault tolerance. By having two servers hosting Query Processor role, if one goes down, the other will be used.
Query Processor functions in Parent\Child Farm
In a Publishing/Consumer farm scenario, the Query Processor always runs in the farm where the Search Service Application resides. So if Search Service Application resides in Publishing farm, Query Processor only runs in publishing farm. The Consumer farm utilizes the associated Search Service Application proxy to make the connection over WCF to a Query Processor in the publishing farm.
Observe is Step 1 and Taking Action is Step 2
Before arbitrarily provisioning new query components and property store DB’s, observe the current environment\query health so some evidence can be gathered before making this important decision. The obvious reasons of Fault Tolerance and Query Latency are covered in the previous sections so I won’t discuss those further. Observing for System\Hardware bottlenecks is a good first step before considering adding more Query Components\Property Store DB’s.
Monitoring Query Server
Observation: The Query server is almost maxed on CPU and\or is at the peak of available physical memory and query latency has increased as a result.
Action Taken: Provision a new query component
Monitoring SQL Server
Observation: Property Store DB is I/O bound on SQL and disk latency is unexpectedly high.
Action Taken: Provision a new Property Store on same/different SQL server
Important: These are very basic methods on approaching system bottlenecks. For Example, don’t assume from a general observation of a spiked CPU would automatically require provisioning additional query components. More analysis would be required. Such as finding answers to the following questions:
Thanks,
Russ Maxwell, MSFT
Several things have changed in 2010 SharePoint search. Search is now componentized so now you only provision what you need. This blog series will go through what these components are, how they work together, and how to provision them. The first blog we will focus on scaling Crawl. The next blog will be Query and etc...
Basics
No longer is search tied into an SSP. Search consists of a Search Service Application, Search Service Application proxy, web services, search service instance, and the following SQL databases by default:
Search takes advantage of the shared services framework built on SharePoint foundation. For more details on shared services see my previous blog. It’s necessary to define the components that make up search. Each component plays an important role. This blog will focus on the Crawl Component and the SQL Crawl Database.
It’s possible to provision a search service application\proxy in 3 ways.
Crawl Component and Crawl Database
I’ll use indexer and crawler component interchangeably throughout the blog. An indexer is simply a physical server that host one or more crawl components. The huge change in 2010 is the indexer no longer stores a copy of an index. As items are being indexed, they are streamed\propagated to a Query server. Because the indexer no longer holds a physical copy of the index, it’s no longer a single point of failure. By default, when you provision a search service application using Central Administrator or Farm Configuration Wizard, a Crawler component and Crawl database is provisioned for you. For lack of better words, a crawl component’s job is to crawl\index content. The crawl component runs within MSSearch.exe process and the MSSearch.exe process is a windows service “SharePoint Server Search 14”.
It’s possible to provision multiple Crawl databases and Crawler components for a single Search service application. The reasons for doing this are plentiful and some of the reasoning will be explained throughout this post. When a crawler component is provisioned, it requires a mapping to a SQL crawl database. Both of these can be created by using either Central Administrator or PowerShell. To simplify things a bit I’ll cover how to do it in Central Administrator. In order to make changes to the Search topology, you must access the Search Administration page via the following:
To provision a new crawl database within Search Admin Page:
To provision a new crawl component
Note: Server specified will host crawl component. Associated Crawl Database is where you specify which Crawl database this crawl component will be mapped to. In this case, I will map to my newly created one.
4. Select Apply Topology Changes
The end result is a secondary crawl database and crawl component.
Just because an index doesn’t physically reside on the indexer doesn’t mean that you should only have one. For example, if only one crawler component is provisioned and the index server hosting that component fails, a major part of search is broken in that no further crawls will take place. Fault tolerance can be achieved by provisioning a secondary crawl component on a secondary server. A crawl component can only map to one SQL Crawl database. Multiple crawl components can map to the same Crawl database. By having multiple crawl components mapped to the same crawl database, fault tolerance is achieved. If the server hosting crawl component 1 crashes, crawl component 2 picks up the additional load while 1 is down. This achieves fault tolerance for the Indexer but what about fault tolerance for the Crawl DB? We fully support SQL mirroring and the Crawl DB can be mirrored in SQL to achieve fault tolerance.
Performance is improved in this setup because you effectively now have two indexers crawling the content instead of one. If you’re not satisfied with crawl times, simply add an additional crawl component mapped to the same crawl DB. The load is distributed across both index servers.
Question: If I specify two indexers to crawl the same content “two crawl components” map to the same Crawl DB, is it possible that the indexers might both attempt to crawl newly discovered items?
Answer: No overlapping would occur. Items are crawled and “picked up” in batches by both index servers for processing. If Indexer 1 picks up and processes Batch 1, then Index Server 2 will process Batch 2.
Crawl Distribution
Crawl Distribution can be achieved by provisioning the following:
Crawl Component 1 --> Crawl DB 1
Crawl Component2 --> Crawl DB 2
By having multiple crawl components each mapped to a unique Crawl database, each host is assigned to only one Crawl DB at crawl time. A host is simply an address defined in a content source. So if I have two web applications provisioned using Host Headers called Sales.Contoso.Com and TPSReports.Contoso.Com, each one is a unique host. I provision a new Search Service application with the following setup:
Index Server 1 “Crawl Component 1” <--> Crawl DB 1
Index Server 2 “Crawl Component2” <--> Crawl DB 2
When I start a crawl, each host in this example is evenly distributed so it will look like this.
Sales.Contoso.Com --> Index Server 1 “Crawl Component 1” <--> Crawl DB 1
TPSReports.Contoso.Com --> Index Server 2 “Crawl Component2” <--> Crawl DB 2
Indexers “Server hosting a crawl component” associated to that crawl database crawl that host. When multiple crawl databases exist, an attempt is made to distribute these evenly. In this example, I only have two hosts. What if I add a third host after the fact, how does the crawler determine which Crawl DB the host will be assigned to? The decision is based on the # of items\doc id’s are stored in the Crawl DB. From the example above, Sales.Contoso.Com has 300,000 items and assigned to Crawl DB 1 and TPSReports.Contoso.Com has 200 items and assigned to Crawl DB 2. The following hosts are added as content sources:
HR.Contoso.Com has 2,000 items
Facilities.Contoso.Com has 8,000 items
When a crawl is initiated, both hosts will be assigned to Crawl DB 2 based on the fact Crawl DB 2 contains less Doc ID’s than Crawl DB 1. Host Distribution isn’t solely determined by the # of Host but rather the # of items in a particular Crawl DB. By default, a Crawl DB with fewer Doc Id’s will get always get assigned a new host. It’s possible to control this automated behavior using Host distribution rules.
Note: Having more crawl databases than crawl components makes no since and is a waste of disk space/resources on the SQL server.
Question: One Crawl Component\Crawl Database exists and already has crawled all hosts in the farm. A decision is made for various reasons to add an additional Crawl Component\Crawl Database. The SharePoint Administrator would like to forklift half of the host addresses already indexed in original Crawl DB over to the newly created Crawl DB.
Answer: Once a new Crawl Component\Crawl Database is provisioned, a few ways exist on how to move half of the host:
· Option 1: Reset the Index and perform a Full Crawl.
· Option 2: Add Host Distribution Rules for half of the host and redistribute. Once complete, host distribution rule\rules can be removed.
Controlling Host Address Distribution
In some instances, a SharePoint administrator will want greater control on the decision making that goes into assigning host to a specific indexer\crawl DB. This is controlled through the use of host distribution rules. This is accessible as a link on the Search Admin page.
When you add a host and apply, if the host is already distributed to a crawl store, the crawler will be paused and the content will be physically moved and assigned to the crawl DB you select after selecting Redistribute Now button below. This is a resource intensive operation.
Need more control?
You can also control whether or not a crawl DB will be used for only Host specified by a Host Distribution rule. When provisioning a new crawl component the last option at the bottom is the following:
By marking a crawl database available to only hosts stored in Host Distribution rules, the indexer is aware of the change and will not automatically allocate newly discovered Host to this crawl database at crawl time. Only host addresses that are defined in Host Distribution rules mapped to a Crawl DB with this property set will get assigned.
A good example of when a SharePoint administrator might take advantage of this functionality is when a newly added Host consists of several million items. This would provide a dedicated Crawl database for that host assuming Host distribution rule was created prior to crawling. Since the database is dedicated to this host, the database will be exempt from receiving any new host.
Question: Can I combine fault tolerance and shorter crawl times with host that are defined in host distribution rules and are mapped to a crawl database marked as dedicated?
Answer: Sure, it’s as simple as defining another crawl component mapped to the dedicated crawl database. Remember, multiple crawl components can map to the same crawl DB which effectively achieves fault tolerance + performance increase in shorter crawl times.
Question: Wait just a minute! I’m happy with my single crawl component\crawl database. I’m retiring the Indexer “server hosting crawl component” and I want this new shiny Server to become my indexer. Do I need to create a new crawl component?
Answer: Nope, no need to create additional crawl components for migrating to a new index server. It’s as simple as editing the current crawl component via Search Admin Page\Search Application topology and specifying the new server.
Before arbitrarily provisioning new crawler components and crawl DB’s, observe the current environment\crawl health so some evidence can be gathered before making this important decision. The obvious reasons of Fault Tolerance and Decreased crawl times are covered in the previous sections so I won’t discuss those further. Observing for System\Hardware bottlenecks is a good first step before considering adding more Crawl Components\Crawl DB’s.
Monitoring Index Server
Observation: The index server is almost maxed on CPU and\or is at the peak of available physical memory and crawl times have increased as a result.
Action Taken: Provision a new crawl component on a different server mapped to the same crawl DB
Observation: Crawl Database is I/O bound on SQL and disk latency is unexpectedly high.
Action Taken 1: Provision a new Crawl Database on same SQL server “on a different set of spindles” and forklift half of the host over to it via Host Distribution Rules.
or
Action Taken 2: Provision a new Crawl Database on a different SQL server with a more suitable disk subsystem and forklift half of the host over to it via Host Distribution Rules.
Note: Provisioning a crawl DB requires provisioning a new Crawl Component.
Observation: SQL Server Memory\CPU is peaking and is unable to sustain the heavy load during crawl times.
Action Taken: Provision a new SQL server and Crawl DB to reside on the newly created Server. Forklift half of the host over via Host Distribution Rules.
Important: These are very basic methods on approaching system bottlenecks. For Example, don’t assume from a general observation of a spiked CPU would automatically require provisioning additional crawl components. More analysis would be required. Such as finding answers to the following questions:
Part 2 - Configuring Hosting
Configuring hosting requires powershell so the steps are all based off of using it. The following steps take you through the process of setting up Multi-Tenant Hosting. Before starting, create two site collections that reside within the same web application.
1. Create a subscription and assign sites to it:
$sub = new-spsitesubscription
$sub
2. Pulling the site collection or set of site collections you wish to join to the site group:
get-spsite
$site = get-spsite | where {$_.url -eq "http://contoso"}
$site
3. Add the site collection $site, to the newly created site subscription $sub.
set-spsite -identity $site -sitesubscription $sub
Check whether it has been added correctly by doing the following:
get-spsitesubscription
If a database ID exists, then you can type the following
get-spdatabase | where-object {$_.id -match "full or partial guid"}
Will output the results of the associated site collection.
4. Create a secondary subscription and associate a different site collection within same web application for demonstration purposes using the steps above.
5. Create a SubscriptionSettings Service Application and Proxy
A. Start the WSS Subscription Settings Service
B. Create Service Application and Proxy via PowerShell
$appPool = New-SPServiceApplicationPool -Name SettingsServiceApppool -Account domain\username
$sa = new-spsubscriptionsettingsserviceapplication –Name SubscriptionSettingsServiceApplication –Databasename SubscriptionSettingsServiceApplicationDB –applicationpool appPool
$sap = new-SPSubscriptionSettingsSericeApplicationProxy –ServiceApplication $sa
6. Creating the Tenant Admin Site for each site group
$sub = get-spsitesubscription –identity “http://server”
$tasite = new-spsite –url “http://Contoso/sites/tasite1” –template “tenantadmin#0” –owneralias domain\username –sitesubscription $sub -AdministrationSiteType tenantadministration
7. Provision a search service application in hosting mode. Please see the Provisioning Search Service application using Powershell blog.
Note: You must append the –Paritioned parameter to the following cmdlets.
From Powershell, run “get-help cmd-let –full” for more details.
8. Feature's and hosting
Once a feature has been installed into the farm, it's available to all sites and can be activated through manage features pages. Simply stated, all installed\deployed features to a specified web application will be available to all sites that reside under the associated web application. This applies to both non-hosted sites “sites that don’t belong to a site group” and hosted sites “Sites that are associated and are members of a particular site group. A farm administrator is highly unlikely going to want all custom features to be available to every site group. For Example, a custom feature might need to be deployed to sites under Site Group 1 and another custom feature must be deployed to sites under Site Group 2. In a hosting scenario, if a feature is catered to a particular site group, a Farm Administrator will not want to expose those features to other site groups.
The way to control this in a hosting scenario is you only provide the features available to a given site group through a series of PowerShell commands. Any features not listed are excluded and not available for all site collections that belong to the corresponding site group.
In order control or restrict what features are available to an associated site group "site subscription", you can create what are called Feature packs.
So the flow is the following:
1. Create a feature pack 2. Add features you want to be available for the associated site group 3. Assign the feature pack to the site group
Steps are the following:
A) Create a new site subscirption feature pack which creates a feature set limited to the specified site subscription.
$FP = new-spsitesubscriptionfeaturepack
B) Add the features you would like to add to the newly created subscription feature pack.
Get-spsitefeature
Copy the iD or id's of the features you want.
For example: 830b81f9-e008-41f4-b3c3-9946b7eb3578
Drop it in a variable now:
$feature = get-spsitefeature 830b81f9-e008-41f4-b3c3-9946b7eb3578
C) Add the feature has a member of the featurepack you created in step 1.
Add-SPSiteSubscriptionFeaturePackMember -Identity $fp -FeatureDefinition $feature
To confirm it took run $fp
D) Assign the featurepack to the site group "SiteSubscription"
Set-SPSiteSubscriptionConfig -identity $sub1 -featurepack $fp
Note: Be careful what features you decide to leave out. Some features are required in order to successfully create sites. For Example, if a featurepack only contains one custom feature and that feature pack is assigned to a site group, The tenant administrator will be unable to create sites via the Tenant Administration web site associated to that paritcular site group. Also, any owners of sites that reside under the site group will be unable to create subsites. The following error will persists within the ULS logs:
04/05/2010 10:42:02.75 w3wp.exe (0x12FC) 0x02C0 SharePoint Foundation Runtime tkau Unexpected System.InvalidOperationException: Failed to activate feature 'BasicWebParts' (id: '00bfea71-1c5e-4a24-b310-ba51c3eb7a57'). The feature is not a member of the associated site subscription feature pack. at Microsoft.SharePoint.SPFeatureCollection.AddInternal(SPFeatureDefinition featdef, Version version, SPFeaturePropertyCollection properties, Boolean force, Boolean fMarkOnly) at Microsoft.SharePoint.SPFeatureCollection.AddInternalWithName(Guid featureId, String featureName, Version version, SPFeaturePropertyCollection properties, Boolean force, Boolean fMarkOnly, SPFeatureDefinitionScope featdefScope) at Microsoft.SharePoint.SPFeatureManager.EnsureFeaturesActivatedCore(SPSite site, SPWeb web, String sFeatures, Boolean fMarkOnly) at Microsoft.SharePoint.SPFeatureManager.<>c__DisplayClassa.<EnsureFeaturesActivatedAtSite>b__9() at Microsoft.SharePoint.SPSecurity.RunAsUser(SPUserToken userToken, Boolean bResetContext, WaitCallback code, Object param) at Microsoft.SharePoint.SPFeatureManager.EnsureFeaturesActivatedAtSite(Byte[]& userToken, Guid& tranLockerId, Int32 nZone, Guid databaseid, Guid siteid, String sFeatures) at Microsoft.SharePoint.Library.SPRequestInternalClass.ApplyWebTemplate(String bstrUrl, String bstrWebTemplateContent, Int32 fWebTemplateContentFromSubweb, Int32 fDeleteGlobalListsWithWebTemplateContent, String& bstrWebTemplate, Int32& plWebTemplateId) at Microsoft.SharePoint.Library.SPRequest.ApplyWebTemplate(String bstrUrl, String bstrWebTemplateContent, Int32 fWebTemplateContentFromSubweb, Int32 fDeleteGlobalListsWithWebTemplateContent, String& bstrWebTemplate, Int32& plWebTemplateId) at Microsoft.SharePoint.SPWeb.ApplyWebTemplate(String strWebTemplate) at Microsoft.SharePoint.ApplicationPages.TA_CreateSiteCollection.BtnCreateSite_Click(Object sender, EventArgs e) at System.Web.UI.WebControls.Button.OnClick(EventArgs e) at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) c3b97351-e0bf-4351-a1bf-2e71c57fe2eb
Hosting 101 Part 1
Before providing the steps of setting up hosting, it's important to understand the main concepts behind O14 hosting.
SharePoint 2010 has a rich set of hosting features which triumph over the previous version in many ways. It's now simple to setup hosting on the site collection level.
Each tenant would only have full administrator rights on his/her assigned site collection. Customer 2 and users accessing site collection 2 wouldn't be able to access Customer 1's site.
Also, service applications that are in hosting mode would keep each tenants data separate from another tenants. For example, one shared search service application could service customer 1\site collection 1's data and customer 2/site collection 2's data while keeping them separate from each other.
For Example: Users searching in site collection 1 will not be able to search and find content that resides in site collection 2. Users searching in site collection 2 will not be able to search and find content that resides in site collection 1. They will be able to search and locate data within the site collection they are searching from.
Site Groups
The segmentation is possible through the use of site groups also known as site subscriptions. In the example above, customer 1's site collection belongs to site group 1 and customer 2's site collection belongs to site group 2.
Things to know about site groups:
1. Sites can belong to only one site group at a time.
2. Sites cannot join a site group that contains sites that exists on a different web application.
3. A site group can span across more than one content database
4. No GUI interface for managing site groups. PowerShell is required to create/manage/remove site groups.
Tenant Admin Site
A hosted customer is referred to as a tenant. You can provision a tenant admin site which gives the tenant full administrator rights over the site collection. The tenant admin site can be used to create additional sites for example after self service site creation is enabled.
Service Applications and Hosting
Be default, a service application is consumed at the web application level. So all sites, under a web application would consume from the same service application and data would be shared. In hosting mode, a shared service application partitions data where every site group has its own partition. The partition isn't shared meaning other site groups wouldn't be able to see this data even though all sitegroups are using the same service application. Configuring hosted service applications may differ based on the type of service application that is being deployed.
For Example: Deploying a Shared search service application requires you to use PowerShell with addition of -partitioned switch
Features
It's also possible to deploy features in an "a la carte" manner to site groups. So one site group can have more features available than another. This is configurable from PowerShell.
Hosting Part 2 provides a step by step walk though using PowerShell
-Russ Maxwell, MSFT