Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Finding Your Place in the Cosmos - Azure Cosmos DB
Similaire à Finding Your Place in the Cosmos - Azure Cosmos DB (20)
Plus de Eric Potter
Dernier
Dernier (20)
Finding Your Place in the Cosmos - Azure Cosmos DB
- 4. What
- 8. Why
- 15. Performance
- 20. Storage
- 29. Model
- 30. Model
- 31. Model
- 32. Insert
- 33. Insert
- 34. Insert
- 35. Query ● LINQ to SQL API ● Stored Procedures in JavaScript ● JavaScript for ○ Store Procedures ○ Triggers ○ User Defined Functions ● (future) Entity Framework
- 36. KeyValue
- 38. Model
- 39. Model
- 40. Insert
- 41. Insert
- 43. • All values are retrieved by their keys. • Data is structured so there is little need to join records together. • These limitations make the data retrieval times incredibly fast. Query
- 44. Graph
- 46. Model
- 47. Insert - Vertices g.addV('person').property('id', ‘coryHouse') g.addV('person').property('id', 'jeremyClark') g.addV('person').property('id', 'arthurDoler') g.addV('podcast').property('id', 'crossCuttingConcerns') g.addV('podcast').property('id', 'developerOnFire').property('Name', 'Developer On Fire') g.addV('podcast').property('id', 'dotnetrocks').property('Name’, ‘.Net Rocks') g.addV('conference').property('id', 'kcdc-2018') g.addV('conference').property('id', 'devUp-2018') g.addV('conference').property('id', ‘codeMash-2019')
- 57. Model
- 58. Insert
- 59. SELECT * FROM podcasts.episodes WHERE shownum = 38 Query
- 60. Questions?
- 61. Integration
- 62. Integrations • Logic Apps / Microsoft Flow • Azure Functions • Azure Change Feed Processor
- 63. Conslusion
- 65. “ Thank You. Let’s Chat Later. @pottereric HumbleToolsmith.com
Notes de l'éditeur
- Open C:\Projects\SpeakerNetwork\SpeakerNetwork.sln TODO – better graphic explaining partition keys TODO – better graphic for database \ container \ document
- Open C:\Projects\SpeakerNetwork\SpeakerNetwork.sln
- Integration with Logic Apps
- Global Distribution: You can distribute your data to any number of Azure regions, with the click of a button. Elastic Scale Out: Scale storage size transparently and automatically to handle your size requirements now and forever. Multi-Model: Low Latency: 5 Consistency Models: Comprehensive SLAs: Money back guarantees https://www.youtube.com/watch?v=L_PPKyAsR3w&feature=youtu.be – Leslie Lamport {Turing Award Winner} “CosmosDB is a database system in which the data can be replicated and copies distributed throughout the world. This permits the application to be configured so that every user is near a copy of the data without the application programmer having to worry about how many copies there are or where they are located.”
- Azure Cosmos DB had its beginnings in 2010 as “Project Florence”.
- This is the video clip of creating a new CosmosDB instance
- SQL Server has worked well for many years. When we have SQL Server, MySQL, Postgres, and others, why do we need anything else? Why do we need new storage solutions? It is because we have new storage problems. New kinds of problems require new kinds of solutions
- Not all apps are 2 boxes and a cylinder If this is what you need, by all means use it. Relational databases were developed at a time when minimizing total storage was an effective way to provide business value. For many years, many organizations tried to consolidate all of the storage into a database or a group of databases on a single server. This made reporting much easier. Relational database systems are the most broadly useful databases. So for most applications they will still be the database of choice. Especially if your application only has one database.
- Microservices… If you are always using SQL databases, there will be times when you are trying to fit a square peg in a round hole. Or you might be trying to fit a square peg in a hexagon hole. Or you might be trying to put a large square peg into four small square holes. Many microservice proponents advocate for having one database per service. If we have more and more specialized databases, there are many more opportunities to use a different data model. In these cases, the CosmosDB or other NoSQL databases follow the Unix Philosophy of tools. They do one specialized thing and do it well. In a scenario where you needed multiple NoSQL databases, you could either stand them all up yourself, or you could just use Cosmos.
- NoSQL is beyond just a fad. It isn’t a popular as it once was, but it has proven itself to be productive in the right scenarios.
- Thoughtworks Technology Radar
- By far the biggest differentiator of CosmosDB over it’s competition is in performance at a global scale.
- Global Scale If this is what you need, CosmosDB is a no brainer It is ridiculously easy to replicate data to other regions in the world.
- Horizontal Scale out This is why there are limited join capabilities This is why stored procedures can only hit one partition key This is why partition keys are particularly important
- Replicate Data Globally
- 5 Consistency Models “Implementing any distributed system involves a tradeoff between on the one hand degree of consistency it provides to the users and on the other hand it’s availability and response time.” – Leslie Lamport {Turning Award Winnder} Most systems choose either strong consistency or eventual consistency. Strong - The reads are guaranteed to return the most recent committed version of an item. Bounded Stateless – can configure how out of date readable data can be Session – Session consistency is scoped to a client session. Consistent Prefix - guarantees that reads never see out-of-order writes Eventual - There's no ordering guarantee for reads. In the absence of any further writes, the replicas eventually converge.
- It is kind of like a data storage mullet – Gremlin in the front, atom-record-sequence in the back. The internals are where the real wizardry happens. And as a Potter, I love wizardry. The underlying data model is projected onto the selected API. The atom-record-sequence model is what Cosmos uses internally to replicate data around the world. But as a developer, you never have to think about that. The developer only has to be concerned with knowing on of the straight forward APIs. All of the API are hitting the same kind of datastore behind the scenes. But the data is projected into a familiar format.
- The M87 black hole
- Mongo DocDB SQL has a whole language just for defining tables (Data Definition Language or DDL) Working with a document database is structurally similar to working with a dictionary because you request data with a key and a value is returned to you. In practice it is more like a library because you look something up and get a whole book back. It is kind of like a hip new restaurant that has great stuff, but you won’t find a table.
- There is some irony in the fact that mongoDB was designed to run on commodity hardware and now you can run it on one of the most powerful cloud instances in the world.
- Mars
- I believe the big benefit is performance. Is that correct?
- Mercury
- If you have long skinny tables with no relationships, a key-value store might be what you are looking for.
- Uses the TableStorage NuGet package
- Working with graph databases is like talking to that one family member than has an astonishing ability to know how everyone in the family is related to everyone else. Not only that, the know random details about everyone. Graph databases have also been compared to social networks. So I guess it is kind of like Facebook without all the adds, fake news, and posts from the one guys from high school who now shares pictures of his kids once every 47 minutes. Could be very valuable in a manufacturing scenario. Can work with Gremlin.Net or the new .NET SDK.
- Neptune
- If you have a database with lots of linking tables, you might want to use a graph database.
- Query embedded in C# as strings
- Cassandra as a service Cassandra Query Language
- Good for sparse data. Good for data with varying structures. Data is retrieved by row and column, almost like looking something up in an excel spreadsheet. Created by Facebook The biggest use case is to service users that already have an investment in Cassandra and they want it to run on Azure hardware.
- Saturn – because the data is sparse
- Cassandra is wide column store, and, as such, essentially a hybrid between a key-value and a tabular database management system. Its data model is a partitioned row store with tunable consistency. The data model makes more sense when you understand that it is designed to run in a distributed environment. Keyspace Table -- Partition (not represented in CQL) ---- Row
- Data in Cassandra is often arranged as one query per table, and data is repeated amongst many tables, a process known as denormalization.
- Cassandra cannot do joins or subqueries. Rather, Cassandra emphasizes denormalization through features like collections. CQL v4 with some restrictions Selects in CQL look very similar to their SQL equivilant
- As we move towards systems with more sophisticated architectures, it will be increasingly important to use the right tools in the right places. CosmosDB’s capabilities put it in a position to solve interesting problems for businesses and applications. Hopefully you have are now better prepared to identify when your application could benefit from using CosmosDB.