Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CosmosDB: Jack Of All Trades, Master Of Many

CosmosDB: Jack Of All Trades, Master Of Many

This is the presentation deck I used at ESPC in Copenhagen.

Daron Yondem

November 27, 2018
Tweet

More Decks by Daron Yondem

Other Decks in Technology

Transcript

  1. CosmosDB
    Jack of All Trades, Master of Many
    DARON YÖNDEM
    CTO, XOGO

    View Slide

  2. A little history
    2010 – Project Florence
    2015 – DocumentDB
    2017 – CosmosDB

    View Slide

  3. Column-family
    Document
    Graph
    Turnkey global distribution
    Elastic scale out
    of storage & throughput
    Guaranteed low latency at the 99th percentile
    Comprehensive SLAs
    Five well-defined consistency models
    Table API
    Key-value
    A globally distributed, massively scalable, multi-model database service
    Azure Cosmos DB
    MongoDB

    View Slide

  4. News Flash! “It is just JSON”
    https://www.documentdb.com/sql/demo

    View Slide

  5. 1-Click Global Replication
    • Ring 0 Service
    • Priorities for
    regions

    View Slide

  6. Azure Cosmos DB Multi Master
    Every region now writable
    Single-digit latency
    99.999% availability
    Tunable consistency levels
    Flexible conflict resolution
    Unlimited endpoint scalability
    All Azure regions
    All data models
    All SDK’s
    Region A
    Region B
    Region C
    Azure
    Traffic
    Manager
    Master
    (read/write)
    Master
    (read/write)
    Master
    (read/write)
    Master
    (read/write)
    Replica
    (read)
    Replica
    (read)

    View Slide

  7. Adding multi master support
    Create new Cosmos DB
    account
    Enable Multi Master

    View Slide

  8. Configure regions
    Add regions
    Select read or write regions

    View Slide

  9. In your apps
    Connection Policy
    UseMultipleWriteLocations =
    true
    Add regions in preferred order

    View Slide

  10. Flexible conflict management
    Last-Writer Wins
    Default mode
    User Defined Procedure
    Custom – Asynchronous
    Only available for SQL model

    View Slide

  11. Last Writer Wins
    Default
    Use numeric property resolve
    conflicts
    Can be user defined or _ts
    Available for all data models

    View Slide

  12. Custom – User Defined Procedure
    Register stored
    procedure
    Special signature
    Conflict dropped after
    Processing.
    If error then written to
    Conflict feed, handled
    manually.

    View Slide

  13. Custom – Asynchronous
    Select Custom
    Leave Stored procedure blank

    View Slide

  14. 99.99% SLA for Low latency reads + writes
    • Reads and writes served from local region
    • Guaranteed millisecond latency worldwide
    • Write optimized, latch-free database engine
    • Automatically indexed SSD storage
    Reads (1KB) Indexed writes (1KB)
    Read < 2 ms
    Writes < 6 ms
    Read < 10 ms
    Writes < 15 ms
    99%
    50%
    • Synchronous and automatic
    indexing at sustained
    ingestion rates
    • No schema or index
    management needed
    • No schema versioning needed
    • No schema migration needed

    View Slide

  15. 5-9’s availability
    99.999% availability
    SLA
    All reads and writes
    Implicit fault tolerance
    No need for failover

    View Slide

  16. Provisioned
    Throughput

    View Slide

  17. What is RU?
    • Request Unit
    • Not all requests are equal.
    • A normalized quantity of request unit based on
    the amount of computation (CPU, memory, and
    IOPS) required to serve the request.

    View Slide

  18. How to calculate?
    Item Size Reads/secon
    d
    Writes/secon
    d
    Request units
    1 KB 500 100 (500 * 1) + (100 * 5) = 1,000 RU/s
    1 KB 500 500 (500 * 1) + (500 * 5) = 3,000 RU/s
    4 KB 500 100 (500 * 1.3) + (100 * 7) = 1,350 RU/s
    4 KB 500 500 (500 * 1.3) + (500 * 7) = 4,150 RU/s
    64 KB 500 100 (500 * 10) + (100 * 48) = 9,800 RU/s
    64 KB 500 500 (500 * 10) + (500 * 48) = 29,000
    RU/s
    See: https://www.documentdb.com/capacityplanner

    View Slide

  19. For example
    • SELECT * FROM c
    • (2.87 RU)
    • SELECT * FROM c where
    Contains (c.Name, "Sample")
    • (2.45 RU)

    View Slide

  20. DEMO
    Calculating RU On-The-Fly

    View Slide

  21. public static async Task> GetItemsAsync(Expression>
    predicate)
    {
    double queryCost = 0;
    IDocumentQuery query = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseId, CollectionId),
    new FeedOptions { MaxItemCount = -1 })
    .Where(predicate)
    .AsDocumentQuery();
    List results = new List();
    while (query.HasMoreResults)
    {
    var response = await query.ExecuteNextAsync();
    queryCost += response.RequestCharge;
    results.AddRange(response);
    }
    Debug.WriteLine(queryCost.ToString());
    return results;
    }

    View Slide

  22. Request Unit Management
    Single Partition
    Container
    Partitioned Container
    Minimum Throughput 400 RU/sec 1.000 RU/sec
    Maximum Throughput 10.000 RU/sec Unlimited
    Offer offer = client.CreateOfferQuery()
    .Where(r => r.ResourceLink == collection.SelfLink)
    .AsEnumerable().SingleOrDefault();
    offer = new OfferV2(offer, 12000);
    client.ReplaceOfferAsync(offer);
    A partition key is
    required to scale your
    collection's throughput
    beyond 2,500 request
    units in the future

    View Slide

  23. Affecting RUs are;
    • Item size
    • Item property count (Indexing)
    • Data consistency (Strong or Bounded Staleness)
    • Indexed properties (lazy indexing can help)
    • Document indexing (Disable if you don’t need)
    • Query patterns (predicates, UDFs, data source size)
    • Script usage (SPs, triggers)

    View Slide

  24. View Slide

  25. What if you exceed?
    HTTP Status 429 Status Line:
    RequestRateTooLarge x-ms-retry-after-ms :100

    View Slide

  26. Partitioning
    Partition schema is
    immutable

    View Slide

  27. Let’s have a birds eye view

    View Slide

  28. View Slide

  29. View Slide

  30. Reading data with partitions.

    View Slide

  31. Reading data with partitions.

    View Slide

  32. How to detect
    Hot Partitions?

    View Slide

  33. View Slide

  34. View Slide

  35. Choose Your Consistency Level
    01
    Strong
    Bounded
    Staleness
    Session
    Consistent
    Prefix
    Eventual
    Clear Tradeoffs
    • Latency
    • Availability
    • Throughput
    Lower latency, higher availability, better read scalability.

    View Slide

  36. Bounded Staleness
    When choosing bounded
    staleness, the "staleness" can
    be configured in two ways:
    number of versions K of the
    item by which the reads lag
    behind the writes, and the
    time interval t
    01
    Strong
    Bounded
    Staleness
    Session
    Consistent
    Prefix
    Eventual
    Lower latency, higher availability, better read scalability.

    View Slide

  37. Consistent Prefix
    Consistent prefix guarantees
    that reads never see out of
    order writes. If writes were
    performed in the order A, B,
    C, then a client sees either A,
    A,B, or A,B,C, but never out of
    order like A,C or B,A,C.
    01
    Strong
    Bounded
    Staleness
    Session
    Consistent
    Prefix
    Eventual
    Lower latency, higher availability, better read scalability.

    View Slide

  38. Multi-Model API

    View Slide

  39. Native Support for Multiple Data Models
    • Database engine operates on atom-record-sequence (ARS) based type system
    • All data models are efficiently translated to ARS
    • API and wire protocols are supported via extensible modules
    • Instance of a given data model can be materialized as trees
    • Graph, documents, key-value, column-family, … more to come
    KEY-VALUE COLUMN-FAMILY DOCUMENT GRAPH

    View Slide

  40. View Slide

  41. Auto Indexing
    • IndexingMode
    • Consistent (Collection Consistency
    applies)
    • Lazy (ingest now, query later)
    • None (EnableScanInQuery)
    • DataTypes
    • String, Number, Point,
    Polygon
    • Index Types
    • Hash (joins)
    • Range (<, >)
    • Spatial
    • Precision can be defined.

    View Slide

  42. View Slide

  43. Analyzing Query Performance
    • QueryMetrics
    • RetrievedDocumentCount
    • WriteOutputTime
    • DocumentLoadTime
    • IndexLookupTime
    • UserDefinedFunctionExecutionTime
    • SystemFunctionExecutionTime

    View Slide

  44. 4 Axis SLA
    Latency @ 99th
    percentile SLA
    Throughput SLA
    Consistency SLA
    Availability SLA
    2
    4
    3
    1
    Cosmos DB:
    99.99% HA within a single region
    99.999% across regions
    99.99 SLA throughput, latency,
    consistency all at the 99th
    percentile

    View Slide

  45. Security
    • Documents and backups are encrypted at rest
    • IP-based access controls
    • Role-based access controls
    • Automated online backups
    • Attack monitoring
    • Geo-fencing

    View Slide

  46. View Slide

  47. Disclaimer
    • Cosmos DB is not a SQL Database, no complex
    table joins. (you are doing it wrong)
    • Other NoSQL databases are good at doing one or
    two things really well but not native to Cloud.

    View Slide

  48. Summary
    Every region is writable!!!
    <10ms write latency
    99.999% availability
    Flexible consistency levels
    Flexible conflict resolution
    aka.ms/cosmosdb-mm-learn
    aka.ms/cosmosdb-mm-samples
    aka.ms/trycosmosdb

    View Slide

  49. Azure Cosmos DB Workshop
    https://cosmosdb.github.io/labs/

    View Slide

  50. http://drn.fyi/2TUy3u6

    View Slide

  51. http://drn.fyi/2BFF7UF

    View Slide

  52. Free CosmosDB Book
    http://bit.ly/cosmosdbbook

    View Slide

  53. Thanks!
    Slides: http://daron.me/decks
    Daron Yöndem
    http://daron.me | @daronyondem

    View Slide