Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Cnam azure 2015 storage
Similar to Cnam azure 2015 storage (20)
More from Aymeric Weinbach
More from Aymeric Weinbach (20)
Recently uploaded
Recently uploaded (20)
Cnam azure 2015 storage
- 2. SQL Azure. Une ou plusieurs bases. Database Database Database Application Application Database SQL Azure Database
- 3. Implémentation Application Internet LBTDS (tcp) TDS (tcp) TDS (tcp) Les applications utilisent les librairies standards d’accès SQL : ODBC, ADO.Net, PHP, … Les load balancer répartissent la charge sur les passerelles TDS en tenant compte des affinités de session Gateway Gateway Gateway Gateway Gateway Gateway Scalability and Availability: Fabric, Failover, Replication, and Load balancing SQL SQL SQL SQL SQLSQL Gateway: TDS protocol gateway, enforces AUTHN/AUTHZ policy; proxy to backend SQL
- 4. Sql Server dans les nuages avec ses avantages : Provisioning simple Via le portail Via l’API REST Haute disponibilité Load Balancing Protocole TDS (le même que SQL Server) pour tout le reste sur SSL (crypté) Sql Azure
- 5. Vous n’avez pas accès à tout ce qui est physique (filegroup …) Pas de CLR Pas de transactions distribuées Pas de service Broker Les différences avec Sql Server
- 6. Implémenter une politique de Retry Facturation de la bande passante donc utiliser dés que possible : Lazy loading Cache Développer avec Sql Azure
- 7. SQL on IaaS
- 8. Run SQL onVM •Run any SQL product on cloudVM •Support for SQL Server, Oracle, MySql •Ready to goVM images available in Gallery •Persistent storage using attached disk in blob storage 8 MicrosoftAzure
- 9. SQL Database vs SQL IaaS Comparison 9 MicrosoftAzure
- 10. Windows Azure Storage • Cloud Storage - Anywhere and anytime access • Blobs, Disks,Tables and Queues • Highly Durable, Available and Massively Scalable • Easily build “internet scale” applications • 8.5 trillion stored objects • 900K request/sec on average (2.3+ trillion per month) • Pay for what you use • Exposed via easy and open REST APIs • Client libraries in .NET, Java, Node.js, Python, PHP, Ruby
- 11. Abstractions – Blobs and Disks • • • • • • •
- 12. TwoTypes of Blobs Under the Hood
- 14. Pour stocker vos fichiers petits ou très grands Les blocks blobs pour les fichiers image, vidéo etc.. 200 GB max Les page blobs optimisé pour la lecture écriture rapide 1Tb Max Les Azure Drives : un disque NTFS que vous pouvez « monter » dans votre rôle et qui est sauvegardé automatiquement dans un page blob Blob Storage
- 15. CDN avec smooth streaming pour les vidéos Les blobs sont dans des containers Accès public, ou privé Snapshot Shared access signature Lease
- 16. Blob Details
- 17. Blob Details
- 18. Blob Details
- 19. Enumerating Blobs • Prefix • Delimiter • Include= (snapshots, metadata etc…)
- 20. Pagination • Either set maxresults or; • Exceed default value for maxresults (5000)
- 21. Abstractions –Tables and Queues • • • • • • • • •
- 22. Table Storage 1 seul index le couple PartitionKey/RowKey Transactions possibles au sein d’une même partition ODATA + authentification Sdk .net opensource https://github.com/WindowsAzure/azure-sdk-for-net API REST Table non relationnelle Schéma flexible ( plusieurs versions de schéma peuvent cohabiter dans la même table)
- 23. Queue typical usage Queue Web Role ASP.NET, WCF, etc. Worker Role main() { … } 1) Receive work 2) Put message in queue 3) Get message from queue 4) Do work 5) Delete message from queue
- 24. Datacenters
- 25. Windows Azure Data Storage Concepts Account Container Blobs Table Entities Queue Messages https://<account>.blob.core.windows.net/<container> https://<account>.table.core.windows.net/<table> https://<account>.queue.core.windows.net/<queue>
- 26. How is Azure Storage used by Microsoft?
- 27. NoSQL on Azure • AzureTables service is NoSQL row store • MongoDB is a document (JSON) store • Cassandra is a columnar store with excellent replication • HBase is a Big Data (Hadoop) NoSQL store available in HDInsight 27 MicrosoftAzure
- 28. Internals
- 29. Design Goals Highly Available with Strong Consistency • Provide access to data in face of failures/partitioning Durability • Replicate data several times within and across regions Scalability • Need to scale to zettabytes • Provide a global namespace to access data around the world • Automatically scale out and load balance data to meet peak traffic demands • Additional details can be found in the SOSP paper: • “Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency”, ACM Symposium on Operating System Principals (SOSP), Oct. 2011
- 30. Windows Azure Storage Stamps Storage Stamp LB Storage Location Service Access blob storage via the URL: http://<account>.blob.core.windows.net/ Data access Partition Layer Front-Ends DFS Layer Intra-stamp replication Storage Stamp LB Partition Layer Front-Ends DFS Layer Intra-stamp replication Inter-stamp (Geo) replication
- 31. Index Architecture Layers inside Stamps • • • • • • • • • • • • • Partition Layer
- 32. • All writes are appends to the end of a log, which is an append to the last extent in the log • Write Consistency across all replicas for an extent: • Appends are ordered the same across all 3 replicas for an extent (file) • Only return success if all 3 replica appends are committed to storage • When extent gets to a certain size or on write failure/LB, seal the extent’s replica set and never append anymore data to it • Write Availability:To handle failures during write • Seal extent’s replica set • Append immediately to a new extent (replica set) on 3 other available nodes • Add this new extent to the end of the partition’s log (stream) Availability with Consistency forWriting Partition Layer
- 33. •Read Consistency: Can read from any replica, since data in each replica for an extent is bit- wise identical •Read Availability: Send out parallel read requests if first read is taking higher than 95% latency Availability with Consistency for Reading Partition Layer
- 34. • Spreads index/transaction processing across partition servers • Master monitors traffic load/resource utilization on partition servers • Dynamically load balance partitions across servers to achieve better performance/availability • Does not move data around, only reassigns what part of the index a partition server is responsible for Dynamic Load Balancing – Partition Layer Partition Layer Index
- 35. • DFS Read load balancing across replicas • Monitor latency/load on each node/replica; dynamically select what replica to read from and start additional reads in parallel based on 95% latency • • • • • Dynamic Load Balancing – DFS Layer Partition Layer
- 36. Architecture Summary • Durability: All data stored with at least 3 replicas • Consistency: All committed data across all 3 replicas are identical • Availability: Can read from any 3 replicas; If any issues writing seal extent and continue appending to new extent • Performance/Scale: Retry based on 95% latencies; Auto scale out and load balance based on load/capacity • Additional details can be found in the SOSP paper: • “Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency”, ACM Symposium on Operating System Principals (SOSP), Oct. 2011
- 37. What’s Coming
- 38. What’s Coming by end of 2013 • Geo-Replication • Queue Geo-Replication • Secondary Read-Only Access • WindowsAzure Import/Export • Real-Time Metrics for Blobs,Tables and Queues • CORS for Azure Blobs,Tables and Queues • JSON for AzureTables • New .NET 2.1 Library
- 39. TwoTypes of Durability Offered Local Redundant Storage Accounts • Maintain 3 copies of data within a given region • ~ 2/3 price of Geo Redundant Storage Geo Redundant Storage Accounts • Maintain 6 copies of data spread over 2 regions at least 400 miles apart from each other (3 copies are kept at each region)
- 40. Geo Redundant Storage Data geo-replicated across regions 400+ miles apart • Provide data durability in face of potential major regional disasters • Provided for Blob,Tables and Queues (NEW) User chooses primary region during account creation • Each primary region has a predefined secondary region Asynchronous geo-replication • Off critical path of live requests Europe West North Europe Geo-replication South Central US North Central US Geo-replication East Asia South East Asia Geo-replication West US East US Geo-replication
- 41. East US West US Azure DNS http://account.blob.core.windows.net/ DNS lookup Data access Hostname IP Address account.blob.core.windows.net West US Failover Update DNS East US Geo-Rep & Geo-Failover • Existing URL works after failover • Failover Trigger – failover would only be used by MS if primary could not be recovered • Asynchronous Geo-replication – may lose recent updates during failover • Typically geo-replicate data within minutes, though no SLA for how long it will take Geo-replication
- 42. Geo Redundant Storage Roadmap • Customer Controlled Failover (Future) • Provide APIs to allow clients to switch the primary and secondary regions for a storage account • Queue Geo-Replication (Done) • Secondary Read Only Access (by end of CY13)
- 43. Secondary Read-Only Access – Scenarios Read-only access to data even if primary is unavailable • Access to an eventually consistent copy of the data in the other region Provides another read source for geographically distributed applications/customers • Allows lower latency access to data in secondary region • Have compute at both primary and secondary region and use the storage stored in that region • For these, the application semantics need to allow for eventually consistent reads
- 44. Secondary RO Access – How itWorks Customers using Geo Redundant Storage can opt to have read-only access to the eventually consistent copy of the data on Secondary tenant • Customer choose primary region, and the secondary region is fixed Get two endpoints for accessing your storage account • Primary endpoint • accountname.<service>.core.windows.net • Secondary endpoint • accountname-secondary.<service>.core.windows.net Same storage keys work for both endpoints Consistency • All Writes go to the Primary • Reads to Primary are Strongly Consistent • Reads to Secondary are Eventually Consistent
- 45. Secondary RO Access – Capabilities Application will be able to control which location they read data from • Use one of the two endpoints • Primary: accountname.<service>.core.windows.net • Secondary: accountname-secondary.<service>.core.windows.net • Our client library SDK will provide features for reading from the secondary • PrimaryOnly, SecondaryOnly, PrimaryThenSecondary, etc Application will be able to query the current max geo-replication delay for each service (blob, table, queue) for a storage account There will be separate storage account metrics for primary and secondary locations
- 46. Windows Azure Import/Export• MoveTBs of data into and out ofWindows Azure Blobs by shipping disks Windows Azure Storage
- 49. Import/Export Features • Accessible via REST with Portal integration • Each Job imports/exports data for a single storage account • Each Job can be up to 10 disks • Support 3.5” SATA HDDs • All Disks must be encrypted with BitLocker
- 50. • • • • • • $MetricsRealtimeTransactionsBlob, $MetricsRealtimeTransactionsTable and $MetricsRealtimeTransactionsQueue • • • • •
- 53. • <RealtimeMetrics> • <Version>1.0</Version> • <Enabled>true</Enabled> • <IncludeAPIs>true</IncludeAPIs> • <RetentionPolicy> • <Enabled>true</Enabled> • <Days>7</Days> • </RetentionPolicy> • </RealtimeMetrics>
- 54. CORS (Cross Origin Resource Sharing) • What? • Browser by default prevents scripts from accessing resources from different origin • CORS is a mechanism that enables cross origin access for scripts • Set CORS rules via SetServiceProperties for Blobs,Tables and Queues • Can control the origins that can access resources • Can control the headers that can be accessed • Why? • Do not require running a proxy service for web apps to access storage service
- 55. CORS Settings • <Cors> • <CorsRule> <AllowedMethods>GET,PUT</AllowedMethods> • <AllowedOrigins>*</AllowedOrigins> • <AllowedHeaders>*</AllowedHeaders> • <ExposedHeaders>*</ExposedHeaders> • <MaxAgeInSeconds>180</MaxAgeInSeconds> • </CorsRule> • </Cors>
- 56. JSON (JavaScript Object Notation)• What? • A popular concise format for REST protocols • OData supports two formats •ATOMPub: We currently support this but is too verbose •JSON: OData has released multiple flavors of JSON • Why? • Improves COGS for applications •Lower bandwidth consumption (approx. 70% savings), lower cpu utilization and hence better responsiveness • Many applications use JSON to represent object model •Efficient object data model to wire protocol
- 57. 2.1 .NET Library • New Features • AsyncTask methods with support for cancellation • Byte Array,Text, File upload / download APIs for blobs • IQueryable provider forTables • Compiled Expressions forTable Entities • Performance Improvements • Buffer Pooling • Multi-Buffer Memory Stream for consistent performance when buffering unknown length data • .NET MD5 now default (~20% faster than invoking native one) • Available Soon @ http://www.nuget.org/packages/WindowsAzure.Storage
- 58. Demo – CORS, JSON and Realtime Metrics
- 59. Best Practices – Account, Blobs,Tables and Queues
- 60. General .NET Best Practices For Azure• Disable Nagle for small messages (< 1400 b) • ServicePointManager.UseNagleAlgorithm = false; • Disable Expect 100-Continue* • ServicePointManager.Expect100Continue = false; • Increase default connection limit • ServicePointManager.DefaultConnectionLimit = 100; (Or More) • Take advantage of .Net 4.5 GC • GC performance is greatly improved • Background GC: http://msdn.microsoft.com/en-us/magazine/hh882452.aspx
- 61. General Best Practices • Locate Storage accounts close to compute/users • Understand Account Scalability targets • Use multiple storage accounts to get more • Distribute your storage accounts across regions • Cache critical data sets • As a Backup data set to fall back on • To get more request/sec than the account/partition targets • Distribute load over many partitions and avoid spikes
- 62. General Best Practices (cont.) • Use HTTPS • Optimize what you send & receive • Blobs: Range reads, Metadata, Head Requests • Tables: Upsert, Merge, Projection, Point Queries • Queues: Update Message, Batch size • Control Parallelism at the application layer • Unbounded Parallelism can lead to slow latencies and throttling
- 63. General Best Practices (cont.) • Enable Logging & Metrics on each storage service • Can be done via REST, Client API, or Portal • Enables clients to self diagnose issues, including performance related ones • Data can be automatically GC’d according to a user specified retention interval • For example, have longer retention for hourly metrics and shorter retention for realtime metrics
- 64. Blob Best Practice • Try to match your read size with your write size • Avoid reading small ranges on blobs with large blocks • CloudBlockBlob.StreamMinimumReadSizeInBytes/ StreamWriteSizeInBytes • How do I upload a folder the fastest? • Upload multiple blobs simultaneously • How do I upload a blob the fastest? • Use parallel block upload • Concurrency (C)- Multiple workers upload different blobs • Parallelism (P) – Multiple workers upload different blocks for same blob
- 65. ConcurrencyVs. Blob ParallelismXLVM Uploading 512, 256MB Blobs (Total upload size = 128GB) • C=1, P=1 => Averaged ~ 13. 2 MB/s • C=1, P=30 => Averaged ~ 50.72 MB/s • C=30, P=1 => Averaged ~ 96.64 MB/s • SingleTCP connection is bound byTCP • rate control & RTT • P=30 vs. C=30:Test completed almost • twice as fast! • Single Blob is bound by the limits of a • single partition • Accessing multiple blobs concurrently • scales P=1, C=1 P=30, C =1 P=1… 0 2000 4000 6000 8000 10000 Time(s)
- 66. Blob Download •XLVM Downloading 50, 256MB Blobs (Total download size = 12.5GB) • C=1, P=1 =>Averaged ~ 96 MB/s • C=30, P=1 => Averaged ~ 130 MB/s 0 20 40 60 80 100 120 140 C=1, P=1 C=30, P=1Time(s)
- 67. Table Best Practice • Critical Queries: Select PartitionKey, RowKey to avoid hotspots • Table Scans are expensive – avoid them at all costs for latency sensitive scenarios • Batch: Same PartitionKey for entities that need to be updated together • Schema-less: Store multiple types in same table • Single Index – {PartitionKey, RowKey}: If needed, concatenate columns to form composite keys • Entity Locality: {PartitionKey, RowKey} determines sort order • Store related entites together to reduce IO and improve performance • Table Service Client Layer in 2.1: Dramatic performance improvements and better NoSQL interface
- 68. Queue Best Practice• Make message processing idempotent: Messages become visible if client worker fails to delete message • Benefit from Update Message: Extend visibility time based on message or save intermittent state • Message Count: Use this to scale workers • Dequeue Count: Use it to identify poison messages or validity of invisibility time used • Blobs to store large messages: Increase throughput by having larger batches • Multiple Queues:To get more than a single queue (partition) target
- 69. Resources • Windows Azure Developer Website • http://www.windowsazure.com/en-us/develop/net/ • Windows Azure Storage Blog • http://blogs.msdn.com/b/windowsazurestorage/ • SOSP Paper/Talk • http://blogs.msdn.com/b/windowsazurestorage/archive/2011/11/20/windows-azure-storage-a-highly- available-cloud-storage-service-with-strong-consistency.aspx
Editor's Notes
- Slide Objective Understand different blob types Speaker Notes Block blobs are comprised of blocks, each of which is identified by a block ID. You create or modify a block blob by uploading a set of blocks and committing them by their block IDs. If you are uploading a block blob that is no more than 64 MB in size, you can also upload it in its entirety with a single Put Blob operation. When you upload a block to Microsoft Azure using the Put Block operation, it is associated with the specified block blob, but it does not become part of the blob until you call the Put Block List operation and include the block's ID. The block remains in an uncommitted state until it is specifically committed. Writing to a block blob is thus always a two-step process. Each block can be a maximum of 4 MB in size. The maximum size for a block blob in version 2009-09-19 is 200 GB, or up to 50,000 blocks. Page blobs are a collection of pages. A page is a range of data that is identified by its offset from the start of the blob. To create a page blob, you initialize the page blob by calling Put Blob and specifying its maximum size. To add content to or update a page blob, you call the Put Page operation to modify a page or range of pages by specifying an offset and range. All pages must align 512-byte page boundaries. Unlike writes to block blobs, writes to page blobs happen in-place and are immediately committed to the blob. The maximum size for a page blob is 1 TB. A page written to a page blob may be up to 1 TB in size but will typically be much smaller Notes http://msdn.microsoft.com/en-us/library/dd135734.aspx
- Block blobs : Adapté au "streaming" de données Page Blobs : Adapté aux données en lecture/écriture aléatoire
- Slide Objectives Understand the hierarchy of Blob storage Speaker Notes Put Blob - Creates a new blob or replaces an existing blob within a container. Get Blob - Reads or downloads a blob from the system, including its metadata and properties. Delete Blob - Deletes a blob Copy Blob - Copies a source blob to a destination blob within the same storage account. SnapShot Blob - The Snapshot Blob operation creates a read-only snapshot of a blob. Lease Blob - Establishes an exclusive one-minute write lock on a blob. To write to a locked blob, a client must provide a lease ID. Using the REST API for the Blob service, developers can create a hierarchical namespace similar to a file system. Blob names may encode a hierarchy by using a configurable path separator. For example, the blob names MyGroup/MyBlob1 and MyGroup/MyBlob2 imply a virtual level of organization for blobs. The enumeration operation for blobs supports traversing the virtual hierarchy in a manner similar to that of a file system, so that you can return a set of blobs that are organized beneath a group. For example, you can enumerate all blobs organized under MyGroup/. Notes The Blob service provides storage for entities, such as binary files and text files. The REST API for the Blob service exposes two resources: containers and blobs. A container is a set of blobs; every blob must belong to a container. The Blob service defines two types of blobs: Block blobs, which are optimized for streaming. This type of blob is the only blob type available with versions prior to 2009-09-19. Page blobs, which are optimized for random read/write operations and which provide the ability to write to a range of bytes in a blob. Page blobs are available only with version 2009-09-19. Containers and blobs support user-defined metadata in the form of name-value pairs specified as headers on a request operation. Using the REST API for the Blob service, developers can create a hierarchical namespace similar to a file system. Blob names may encode a hierarchy by using a configurable path separator. For example, the blob names MyGroup/MyBlob1 and MyGroup/MyBlob2 imply a virtual level of organization for blobs. The enumeration operation for blobs supports traversing the virtual hierarchy in a manner similar to that of a file system, so that you can return a set of blobs that are organized beneath a group. For example, you can enumerate all blobs organized under MyGroup/. A block blob may be created in one of two ways. Block blobs less than or equal to 64 MB in size can be uploaded by calling the Put Blob operation. Block blobs larger than 64 MB must be uploaded as a set of blocks, each of which must be less than or equal to 4 MB in size. A set of successfully uploaded blocks can be assembled in a specified order into a single contiguous blob by calling Put Block List. The maximum size currently supported for a block blob is 200 GB. Page blobs are created and initialized with a maximum size with a call to Put Blob. To write content to a page blob, you call the Put Page operation. The maximum size currently supported for a page blob is 1 TB. Blobs support conditional update operations that may be useful for concurrency control and efficient uploading. Blobs can be read by calling the Get Blob operation. A client may read the entire blob, or an arbitrary range of bytes. For the Blob service API reference, see Blob Service API.
- Slide Objectives Understand the hierarchy of Blob storage Speaker Notes Put Blob - Creates a new blob or replaces an existing blob within a container. Get Blob - Reads or downloads a blob from the system, including its metadata and properties. Delete Blob - Deletes a blob Copy Blob - Copies a source blob to a destination blob within the same storage account. SnapShot Blob - The Snapshot Blob operation creates a read-only snapshot of a blob. Lease Blob - Establishes an exclusive one-minute write lock on a blob. To write to a locked blob, a client must provide a lease ID. Using the REST API for the Blob service, developers can create a hierarchical namespace similar to a file system. Blob names may encode a hierarchy by using a configurable path separator. For example, the blob names MyGroup/MyBlob1 and MyGroup/MyBlob2 imply a virtual level of organization for blobs. The enumeration operation for blobs supports traversing the virtual hierarchy in a manner similar to that of a file system, so that you can return a set of blobs that are organized beneath a group. For example, you can enumerate all blobs organized under MyGroup/. Notes The Blob service provides storage for entities, such as binary files and text files. The REST API for the Blob service exposes two resources: containers and blobs. A container is a set of blobs; every blob must belong to a container. The Blob service defines two types of blobs: Block blobs, which are optimized for streaming. This type of blob is the only blob type available with versions prior to 2009-09-19. Page blobs, which are optimized for random read/write operations and which provide the ability to write to a range of bytes in a blob. Page blobs are available only with version 2009-09-19. Containers and blobs support user-defined metadata in the form of name-value pairs specified as headers on a request operation. Using the REST API for the Blob service, developers can create a hierarchical namespace similar to a file system. Blob names may encode a hierarchy by using a configurable path separator. For example, the blob names MyGroup/MyBlob1 and MyGroup/MyBlob2 imply a virtual level of organization for blobs. The enumeration operation for blobs supports traversing the virtual hierarchy in a manner similar to that of a file system, so that you can return a set of blobs that are organized beneath a group. For example, you can enumerate all blobs organized under MyGroup/. A block blob may be created in one of two ways. Block blobs less than or equal to 64 MB in size can be uploaded by calling the Put Blob operation. Block blobs larger than 64 MB must be uploaded as a set of blocks, each of which must be less than or equal to 4 MB in size. A set of successfully uploaded blocks can be assembled in a specified order into a single contiguous blob by calling Put Block List. The maximum size currently supported for a block blob is 200 GB. Page blobs are created and initialized with a maximum size with a call to Put Blob. To write content to a page blob, you call the Put Page operation. The maximum size currently supported for a page blob is 1 TB. Blobs support conditional update operations that may be useful for concurrency control and efficient uploading. Blobs can be read by calling the Get Blob operation. A client may read the entire blob, or an arbitrary range of bytes. For the Blob service API reference, see Blob Service API.
- Slide Objectives Understand the hierarchy of Blob storage Speaker Notes Put Blob - Creates a new blob or replaces an existing blob within a container. Get Blob - Reads or downloads a blob from the system, including its metadata and properties. Delete Blob - Deletes a blob Copy Blob - Copies a source blob to a destination blob within the same storage account. SnapShot Blob - The Snapshot Blob operation creates a read-only snapshot of a blob. Lease Blob - Establishes an exclusive one-minute write lock on a blob. To write to a locked blob, a client must provide a lease ID. Using the REST API for the Blob service, developers can create a hierarchical namespace similar to a file system. Blob names may encode a hierarchy by using a configurable path separator. For example, the blob names MyGroup/MyBlob1 and MyGroup/MyBlob2 imply a virtual level of organization for blobs. The enumeration operation for blobs supports traversing the virtual hierarchy in a manner similar to that of a file system, so that you can return a set of blobs that are organized beneath a group. For example, you can enumerate all blobs organized under MyGroup/. Notes The Blob service provides storage for entities, such as binary files and text files. The REST API for the Blob service exposes two resources: containers and blobs. A container is a set of blobs; every blob must belong to a container. The Blob service defines two types of blobs: Block blobs, which are optimized for streaming. This type of blob is the only blob type available with versions prior to 2009-09-19. Page blobs, which are optimized for random read/write operations and which provide the ability to write to a range of bytes in a blob. Page blobs are available only with version 2009-09-19. Containers and blobs support user-defined metadata in the form of name-value pairs specified as headers on a request operation. Using the REST API for the Blob service, developers can create a hierarchical namespace similar to a file system. Blob names may encode a hierarchy by using a configurable path separator. For example, the blob names MyGroup/MyBlob1 and MyGroup/MyBlob2 imply a virtual level of organization for blobs. The enumeration operation for blobs supports traversing the virtual hierarchy in a manner similar to that of a file system, so that you can return a set of blobs that are organized beneath a group. For example, you can enumerate all blobs organized under MyGroup/. A block blob may be created in one of two ways. Block blobs less than or equal to 64 MB in size can be uploaded by calling the Put Blob operation. Block blobs larger than 64 MB must be uploaded as a set of blocks, each of which must be less than or equal to 4 MB in size. A set of successfully uploaded blocks can be assembled in a specified order into a single contiguous blob by calling Put Block List. The maximum size currently supported for a block blob is 200 GB. Page blobs are created and initialized with a maximum size with a call to Put Blob. To write content to a page blob, you call the Put Page operation. The maximum size currently supported for a page blob is 1 TB. Blobs support conditional update operations that may be useful for concurrency control and efficient uploading. Blobs can be read by calling the Get Blob operation. A client may read the entire blob, or an arbitrary range of bytes. For the Blob service API reference, see Blob Service API.
- Slide Objective Understand basics of listing blobs in a container Speaker Notes The List Blobs operation enumerates the list of blobs under the specified container. Can include uncommitted Blobs- see discussion on Blocks and Block Lists Can include snapshots Notes http://msdn.microsoft.com/en-us/library/dd135734.aspx
- Slide Objective Understand pagination when listing blobs Speaker Notes Reponses over multiple pages return a marker value This marker is sent to get subsequent page Notes http://msdn.microsoft.com/en-us/library/dd135734.aspx