 All right. Now I'm on the mic. Do I need to start all over? No. OK. So let's talk about this. I'm sure all of you have to make decisions about data, about the semantics of your queries and your ability and scalability, right? These are questions that you typically have to answer at an architectural level. And we talk about, I don't say ease of audio integration rule. You could put any cloud in there. You put on-prem. It doesn't really matter. You still have to think about strengths and limitations. And we always had to make this decision. And for decades, it was SQL. And now with this NoSQL trend, people will find out about a new database type. And they gravitate toward that database type. And that's what they end up using. So everything gets mapped to this database, which means we make concomiters. And this is an issue with big systems. We talk about schema flexibility. Well, if you're in SQL, you don't have much flexibility. You have to create multiple schemas. If you are in MongoDB, maybe you don't have the rich reporting that you're used to in the SQL reporting services. There's different decisions and different trade-offs you make. And these trade-offs happen all the time. Third-party tools, the ecosystem, high availability, disaster recovery. I'm sure you all have DR plans, well-documented. But as you change to different databases, the DR strategy changes. And so we're always making compromises. At least that's what I've seen. Anyone seen this as well? You pick a database. It becomes the golden hammer anti-pattern, right? So this idea of polyglot persistence is to stop thinking about just one data, kind of open our mind up to multiple database types. That doesn't mean you have to pick every database under the sun. It doesn't mean you have to adapt six or seven. But as an example, let's say we're building a shopping site. This is a relatively simple and contrived example. But you have a cart, you have orders. You have a catalog of reviews. You have a suggestion or recommendation engine. We all see this when we shop. Maybe that doesn't all fit in a SQL database. Maybe we want our cart in a simple key value store. Maybe our orders will be stored in a relational database where we can use our reporting tools. Our catalog might have to be flexible. We have widgets. We have clothing. We have products that have totally different descriptions, very seamless. And then a graph database might fit our suggestion engines. They're doing multiple joins in a SQL table. And then there's a new group of databases. We call it new SQL SAP HANA, SQL Hecatron, where you're getting in-memory SQL. So you take a table in a SQL database, and now you get the performance characteristics of a new SQL database. So this is kind of the idea of polyglot persistence. It's just a slightly different way of thinking. To say, can I combine a couple of different data stores to accomplish my goals? Of course, there's challenges with this. You now have to know about more than one database. You have to have an expanded skill set, if you will, or hire maybe an expert in each area, or something that really focuses on learning these different database types. So we know, as far as the landscape, we have structured and unstructured data. We really talk, we'll focus today, not on big data, but just some of the basic new SQL types. And so you can get your head around that, and we'll see a couple in action, and get an idea. But if you look at the big scheme, you've seen some buzzwords and different names. They all tend to fit into the SQL versus no SQL camp. SQL is our typical MySQL, SQL Server. We have Oracle, DB2, and all that. Recognize any buzzwords, any brand names? So pretty popular stuff. And there's, I don't know, every day there's another one coming out. I can't keep track. Can you get the Azure one now? Which one? Oh, Azure Tables? No. Azure SQL. Oh, it's actually Azure. It's Windows Azure SQL Database. I forgot my name. But it wouldn't fit in the square. I know. I know. I know. Wased. Wased, yeah. So this is basically your SQL role. You still have to deal with the cap theorem and pick any two, right? I mean, you still have all the challenges with data. You think about high availability. It's traditionally a clustering model in the no SQL world. You usually scale out. If you are familiar with things like model DB, you see that you're able to shard your database, but you scale out. You can scale up as well. But typically, the no SQL engines support the scale out ability. And we expect failures. All these databases have, they all fail, right? You're going to get an insert that fails. You're going to get a data store that fails. So you want to think about replication. You want to think about high availability. None of these things necessarily come for free. But these are just things that we have to think about. Any questions on that? Makes sense? All right. So let's look at the types. Because you'll hear these buzzwords, people will implement some database. They'll have key value that is a no SQL type. Very good for a key-based lookup. If you think about Windows Azure tables or any other type of tables where you're looking up by a key, that's a key value store. And they're going to be very high speed. They will be very large databases. DynamoDB is another example. You have a key. You get a value. If it's a discrete lookup, it's going to be extremely fast. So maybe that's your movie titles. That's not very good for metadata. But that would return my titles extremely fast if I had to look it up. And it doesn't really matter in the case of Azure tables what the format of the value is. It could be anything. Separate properties. It could be JSON objects or XML errors, no matter. That's your domain. So we get into document. This tends to be the most popular. This is the one I hear about the most. This is the one when I work with ISVs, I hear they've converted their database to the most. And all of those are just picked a couple of popular ones. ModelDB, RavenDB, CouchDB, there's a couple of others. This is really great because it matches closely with object-oriented work. They're JSON documents, typically. And it fits well in a programming model. If you're working with node, very simple integration because of the key value way of representing the data. And folks that use document stores will also see the similarities with searching. Like when you look at SQL engines. Very powerful search capabilities. You could have multiple indexes and search documents within documents. It's really powerful. Anyone use any of these? Or something different, a different document store that's not up here? Any issues that you've run into? Or scale, performance, backup, reporting? This is a typical document. And I do have the greatest movie of all time, Fletch, on the screen. But that's just me. Column Family, we'll work with Column like Cassandra. We hear a lot about the Column store. And really, it's a way of clustering a bunch of frequently used content together. So it's highly optimized for pulling the same type of data which is stored together physically. So it's meant for extremely high ingestion and very fast lookup. Things like Cassandra are massively scalable and are designed to scale over geographies. So this is a super powerful scalable engine. Anyone use Column store in a database? We have Graph. This one, Graph databases, I think, are up and coming. I haven't seen too many Graph engines. I'm picking on Neo4j today just because they tend to be very popular, especially in the open source community. It's all about nodes and relationships. And it's not that you can't do this stuff in a SQL database with joins and joins of joins. You could do this. But the Graph database is designed from the ground up to navigate nodes and relationships. So if you have a product catalog and you want to traverse product daily, and then if you bought product daily, there's a recommendation to product B. Or if you want to find out between two people who know each other, or traverse that friendship graph, this is really, really easy. So just take a quick look at Windows Azure Storage just because I did call this Paragot, for instance, in Windows Azure. Feel free to take this knowledge and apply it to other things. But the idea is we have storage in the cloud. And each storage account can have up to 200 terabytes of storage. And you can create multiple storage accounts. And it's key value. You have what's called a partition key and a row key. So if you specify the two keys together, it's like almost instant lookup. So if you are storing, I don't know, your tweets of the day or items of our product shopping cart, extremely fast lookup. It's all REST-based. All of the storage in Windows Azure is REST-based. And then we put SDKs on top of it. So we have .NET, PHP, Python, Node, and Ruby came out recently as well. And what's nice is you could choose to replicate across GEOs. And it's really for a DR plan. So that's an option you have available to you. So if you're in US West data center, your data gets geo-replicated to US East. So it stays on the same continent. Any questions on that? Do people tend to use key value stores in their application? Maybe we'll build that in. So I just wanted to show you what Azure tables look like because they're pretty amorphous. And I'm using a tool from Cerebrata. Again, everything's REST-based, but this is a very simple tool. So in this case, I have a task database and just zoom in a little bit. I have partition key, I have a row key, a timestamp, and then random data. So in that table storage, it's designed for very high speed when you have the partition key and row key. You can put all your data in one partition if you so chose, but that might not be the most optimal solution because if you ever needed to pull an entire partition and look at all the rows, then you're talking about potentially millions and millions of data entities. So you can specify a different partition key for every single item. Typically, I do this, like I use maybe a timestamp for my partition key or I use a day of the week or maybe if it's a product, I use the product ID as a partition key. And then maybe for the row key, I use a specific attribute of the product, maybe the general information or the description or whatever. So a very fast lookup. And again, the schema is really up to you. Here's a case where I have a game data in a table. And in this case, my partition key is my game player. The row key is the type of data, whether it's map or inventory. And then the data itself, instead of storing a set of properties, I actually put JSON documents right inside the data. So it all depends on how you wanna look it up. It's a very flexible type of storage mechanism. So that is a table storage. All right, so document databases. Who uses MongoDB? I've tried it. You've tried it. Is that a good thing or a bad thing? I guess I did it for a benchmark. So MongoDB tends to be extremely popular. And again, I'm just picking on this one. There are other NoSQL document database types. What I find interesting about MongoDB though is the support in the community. And the fact that you can integrate with practically every language on the planet. I mean, they have like dozens and dozens of language SDKs. They have great support from their organization. So if you're comparing vendors at breakfast, somebody brought up the question of will this vendor be here next month or next year? I don't know. I mean, TenGen makes it, I don't work for TenGen. But the fact that they have such a rich community, I think that's really important. So you have a powerful language, a query language built in. You could have documents. You could have sub-documents. And you could do MapReduce. They have like an aggregation framework, which is in line. You could do like sums of averages and you could roll up your data just very simply in real time versus doing more of a heavy weight MapReduce, which you can do. It's built right into the engine, but it takes a little bit more time. You can replicate your data. You could shard it. You can replicate your shards. You could store across geos. So it's pretty powerful. This might be in SQL, what a movie review looks like. And that's your typical SQL query. Fletch comes up again. And this is what it would look like in document database. One thing to think about, who wears architect hats? Okay, so as the architect, we think about how we organize data. In this case, I put my reviews inside my document. So it's a sub-document inside a document. That's really great for lightweight capped collections where you know that you only have a hundred or a couple of hundred and will fit because there's a finite space inside the document. If this was my blog and I get one comment a month, I'm safe. I can put my comments underneath the blog post. If you're somebody very popular that has thousands of comments for every blog post, sub-document is no longer so practical because it's an unbounded set. So these are the types of things as you work with the different database types. There are subtleties that you have to learn. So in the MongoDB case, or in any document store where you have sub-document, you have to know how large or maximum document space is. In this case, it's 16 megs in MongoDB. And so you have to think, am I storing 10 items, 100 items, infinite items? If you're doing infinite, now you might want to look at two collections. In this case, I'd have a movie collection and then maybe a movie review collection. And then I have a foreign key reference between the two. Just food for thought as you work with these different databases. Nice thing about MongoDB is it runs on Linux or Windows, easy to install in Azure. We also have a couple of hosters. Not everybody likes to install or maintain their own database. The trend I see especially in the ISV community is I want a service. I want X as a service. I don't want to install databases. I just want to build my app. So in this case, we have MongoLab and MongoHQ, which run MongoDB as a service. You sign up, you ask for a URL, or you ask for a database and it hands you a URL connection string and you're up and running. It's as simple as that. If you're installing on Azure, I just built a little link. MongoDB on Azure, they have an entire portal on their site for how to install it. Just curious, do people run MongoDB in the cloud or run on-prem? How do you run it on-prem? So it's nice running it in the cloud because you can specify your virtual machine sizes and you have a lot of flexibility. Now on-prem, you get to buy the hardware, custom hardware, do your SSDs, do as much RAM as you want. This tends to be a RAM-hungry type of database. How do you run time? I have no concept. So I have a little bit more time. That's good. So if we take a look at... Let me see if I have a window open here. So this is an example. I have a product database and I did a find on a particular ID. How I knew that ID, I'll show you. This is the Ninja BL-660 Blender. That's all the product name, product description. And then I have a couple of reviews as sub-documents. Again, it's unbounded, but for demo purposes, I just wanted to show what that would look like. And the database itself is running. See if I have the site. So there's my Blender. This is at cm2p-web.cloudup.net. So it's just, I'm looking at this Blender data. And I put the description and I have my various ratings. And so it's very easy to query. I just say I want to look at the, whoops, got to reconnect. And if I just want to look at all data in here, it gets a little, you know, just show me all the products in the database and start to scroll them through. But it's very, very simple to query in MongoDB. It's very easy to set up, very easy to use. And again, there's lots of ways to do aggregation. You can, if you take a look at the fact that I had reviews, reviews is a sub-document. So you could very easily take a sub-document and then unwind it and denormalize and say I'm gonna take this document and roll up. So I have a product name and review. The product name and review, product name and review. And then I can do an aggregate function and take the average of the review value. So it could look, you know, if we took a look at, just show you what an aggregate might look like. Here's an example in my movie database where I group on Java. So let's see if we can connect to that database just cautious of the time here. Hopefully I can connect. Again, this is one of our posters. So if we take a look at our various databases, so I should have some movie reviews in here. So you take a look at our movie database. It's the, just a bunch of movie reviews. And so we can do something, dv dot, whoops. You know what? We're gonna go ahead and connect to this. Let's see if this works. Create a user here called, where we got no SQL. Let's connect to our database. Create an original password, right? And yes, I'm gonna delete this user after we're done, okay? Right, so you have a bunch of that. And then if we wanted to take a look at something like if we wanted to aggregate by genre, I'll paste that, right? So what that did is it's aggregating, it's grouping by the property called genre. And every time it finds one, it just adds one to the value. So this is an example where in line, I'm able to do this type of aggregation. And this is one of the advantages of the MongoDB engine is it has this type of functionality. So I know there's 13 action movies and one animation and six comedies. Now, typically we would do MapReduce in a much bigger dataset with millions or hundreds of millions of rows. But for very simple things, this is a really nice type of engine built in. Okay, so let's continue. So let's talk about graphs a little bit. So Neo4j tends to be a very popular graph database. And I know that there are a couple of others. I'm just picking on one in particular. And you could run this in standalone, which is their community edition, or you could run it in an HA mode, where you could have two or three or more nodes running together. They do have Java, Neo4j, it's a good thing they support Java, but they also support .NET and Ruby and Node. And they have a custom query language called Cypher. And then there's also this Grumman query framework, which happens to support Neo4j. They could support other graph databases as well. And this is your typical friends of friend pattern, where you have one-to-many relationship. We've done this in SQL databases for years. And there's a benchmark that was done in an upcoming book where they basically took a look at what it would take to traverse a million records and find friends of friends. And so imagine you do a join of a million times a million times a million or whatever. That would be the query in Neo4j. And when they ran the benchmark, once you start doing three or four joins in a row of a full dataset, this is a complete dataset. So again, a little contrived example, because you typically don't smash together millions of records, but they just watch an exponential growth in the SQL performance, whereas Neo4j is keeping a relatively small node traversal time. And it does install Windows and Linux where you have your choice. And if you go to bit.ly slash Neo4j on Azure, they have an entire portal for how to install it in case you're working in the cloud there. And they have full walkthroughs and all that. Has anyone seen Neo4j in action? Anyone not seen? Never seen a graph database, what it looks like? Let me just show you that real quick. So the way Neo4j works is they kind of make it really convenient to work with it because one, they build an engine that runs on some server, but then they also slap a web interface on top of it which makes it pretty easy to get to it. So you have a full server. I'm just running this local right now to show you. And what they do is anytime you install Neo4j, it's so easy to get up and running because they put the portal right into the server. And in this case, I was doing just some very simple queries. Like I was doing, it's kind of an interesting language where you draw what you want to say. So in this case, what I'm saying is I'm starting with any node, everything is a node or a relationship. So I'm saying I'm starting with any node in the whole database, which is this right here. This right here, start n equals any node, asterisk, I'm not giving you an ID. And I'm gonna say I'm gonna match going from some node m to another node m with a relationship called friend. Now notice I'm drawing this like on the screen. I'm like drawing an arrow going that way. I mean, that's how the query language works. It's like you paint your query. So I'm saying as long as there's this relationship going that way between two people, that's what I want to see. I want to see this friend relationship. And I could just say return n dot name and m dot name. And what that does is it goes through the entire database and gives me this list of people who are friends with somebody else. And that's just traversing the tree. Now let's say that you're not interested in friends, you're interested in friends of friends. So in that case, again, we can say let's start with any node and let's match friend where the level is from, you know, it's too deep and we return the names. So what this is doing, it traverses the database and says, okay, so Emil is friends with Thomas or friends with somebody and that somebody is then friends with Thomas. So again, the syntax is very simple to follow. But then you can also get into things where relationships have properties. So we know that nodes can have properties. So a person has a name. Well, what about a relationship? They're friends. So maybe we only want to know people who have known each other for a certain amount of time. So start with any node and let us match, again, their friend relationship. But in this case, we're gonna say where the number of years they've known each other is greater than one. So we'll say return m.name and f.years. And so now, not every single node in the database or not every relationship called friend has a year's property. But if the ones that do have a year's property and they're greater than one, because we don't want people that just met, show us those people. So this is the kind of thing that you can do with Neo4j and the graph database. The syntax is very easy. The query is very easy. It's right on that laptop. So not exactly the highest performer here, but someone noticed right before I started speaking that I had Java running. That's, this is, there's your Java. Any questions on that? This is sort of the heart of graph database. Looks like I have a few minutes left, 15 minutes, so let's keep going. All right, so we took a little look at a graph database. I'm not gonna demo Cassandra, but I just wanted to point out that it's highly partitioned storage. You get to select how consistent the data is, whether it's media consistent, eventual consistent. You get to choose how available it is, the size of the clusters. You could do MapReduce with the Cassandra file system, CFS, very high write throughput. This is really for high ingestion. A lot of SDKs and they have their own custom query language. I often get asked the question, what can I run in Azure? Well, some of the stuff is supported directly. Like we have database as a service, Azure tables, okay, that's a built-in service. But we also have providers giving us MongoDB. Cloud Int has CouchDB. And then for the others, you can install these on your own, very simply. Neo4j, we already saw they have an entire website that says here's how to run in an Azure. Same thing with MongoDB from Tengen. If you're running HBase, you can install HBase. We have a lot of flexibility. With Windows Azure Virtual Machines, we have both Windows and Linux Virtual Machines, where it doesn't take much to spin one up. You just choose whether you're using Ubuntu or CentOS or whatever, you just choose your image and fire it up. And so you can install any of these. Any questions on that? Okay, I do have a couple of links, but before I jump there, I want to show you a reference application that hopefully will benefit you. We already took one little peek at it. And this reference application, it's the whole idea of this application. My team got together one day and we've been talking about polyglot persistence and working with our ISVs around the world. And we said, well, let's build an app that actually uses multiple databases. And that way people can take a look at it, they can look through the code, they can try it online, and get an idea of what might an application look like. And I showed you a picture before of the shopping cart diagram, where we drew that diagram. We thought it was really cool, and we were like, oh, let's just build that app. And so you have a CN2P cloud ninja polyglot persistence. Why is it called cloud ninja? Because a couple of years ago, we started calling all of our projects and our team cloud ninja something. And we have t-shirts and really cool cloud ninja t-shirts but they don't cost $50 for real. Okay, a t-shirt. Well, we have different products in the catalog and the catalog was driven by MyWDB because we have different types of products. We have toys, electronics, appliances, and you can imagine that this type of data is not consistent across product type. For electronics, I don't know, we might have a UL listing or we might have certain certifications for what countries it can be sold. There's books, which will have an ISBN and have an author. You don't have an author for a blender unless you write software called Blender and then you will be an author. So the whole idea is you have this catalog in your document store. And as you're looking at this professional blender, you also have recommended products. And you don't want to guess where the recommendations come from. Log grafted with Neo4j, yes. And it's really neat, all it does is it has a traversal graph that goes from one product to the next and there's a weight attribute on the relationship. So here's something to think about as you're getting into the polyglot persistence thought process and you're trying to impress your friends and colleagues. How much metadata do you think is in my Neo4j database? Like what kind of data do you think is in that recommendation engine? Or what data would you recommend being in that database? What do you think? Maybe a product ID, right? Each node has to have a product ID. They have a product name, you put that there. So it turns out that all that is in those nodes is a product ID, that's it. And all that's on the recommendation traversal is a weight, it's a single number. Now you can put other things to help decide on recommendation. But for us it was like, we did the work somewhere else. We had an engine somewhere that figured out the best product to recommend. Based on purchase history, views, how many people looked at the Master Prep Pro after looking at the Blender? Or how many people looked at the Blender and purchased the Master Prep Pro? So we did some homework and that's how the recommendation engine got built. But the metadata itself is scarce. It really is an ID. And I had that up on the screen earlier. That's it. Right there. It's just showing pretty much the entire database. That is all that's in the recommendation engine, is an ID, a weight, and another ID. Well in this case we're here. We're planning on having 67 trillion products. It's called Grids R.S. It could be just one. It's actually everything is the same string of one product. So the idea is maybe Neo4j, the way I see it, it's really a scale up kind of database. It doesn't have sharding built in. So I was thinking, as we walk through this, can we really put all of the metadata in Neo4j? Yes we can. We could have loaded every single node up with not only the product ID, but the name. And we could have put the category type. We could have done anything we want. But the problem is, there's a lot of data. So we kept it in MongoDB and every time we have a recommendation, we pull the top 30 or 10 recommendation IDs and then we query the document database and we pull the metadata. Yes it's two queries, but you saw it's pretty quick. It's quick enough for our application. In your application maybe you decide that it's not quick enough. So you pop the product name in here. Good, do that. That's a decision you'll have to make because now it's faster and the data is only one query away. But eventually you might run out of storage space. And I go, what do we do now? I don't know, delete the product name. So, and then we have also in there, there's a shopping cart with all the products that I started adding. So that's not stored in the document database, not stored in the graph database, that's stored somewhere else. Maybe a key store, good place for it. When I place my order, goes into SQL. So we built this and it's one thing to show you that. It's another thing to show you that there's real code like for the recommendation engine. This is .NET, you know, for JClient. There's also the product catalog where it's pulling from all the data going to the database. But then you might want to look at the source code online. Oops. So the source code is at cn2p.codeplex.com. So we published this a couple of weeks ago. This went live. Feel free to download and take a look. And there's several databases that are covered in here. There's our little architecture diagram, but we have different repositories. You'll see different codes with SQL. You'll see code Redis and CouchDB. We started playing around with the different databases. I don't think it's currently running with CouchDB. I think it's MongoDB, but at least you can look at the code base. And the other thing I wanted to offer up is the patterns and practices team at Microsoft has been working on guidance. And so we'll put a link to that. So they've been working on this data access guidance on how you would choose a particular database type and things to think about. And it goes a lot deeper than what I've introduced today. And so you could download, I think it's a PDF, you could download from here. And so I think this is a good reference source for you. So that leaves me with about five minutes. That was the basic talk I had and the information I wanted to share today. I hope this gives an idea of not only where our polyglot persistence is going, but how you would start to make these decisions. And you can take a look through that sample app, where we did make some decisions on where we want to store the data. So questions, yeah? What's the application you can apply to the database that Azure provides on pre-packaged version of the database? So the question is that Azure will, Microsoft provides some type of pre-packaged databases, if you will. So a couple of things to that. One is, as we take a look, this is the Azure portal. And so you could go to our Windows Azure store. And so we have partners such as MongoLab and folks that do MySQL right there, they're integrating their databases here. Here is MongoLab. So we're finding different service providers are hooking right into the portal. Yeah, so nobody was offering, as far as I know, in Azure today, Neo4j as a service. There's a couple of service providers that are just coming out with Neo. But what we also have, when we take a look at our virtual machines, this is my virtual machine hub, and we have images, and you can browse in something called the VM Depot. And I just clicked on the link in the bottom here. And so we have vendors that are building something similar to an AMI, they take a Linux image, and they bake it with all software pre-installed. And then we may choose any of these. Like if you're interested in Neo, you mentioned. So here's Neo Community 1.82, published by Yuri Bakhan, who's from Neo Technology. So he put this up. You'll see a version two come out as soon as they go live. Version two is in last on four right now, so it's still pre-production. And so as that comes out, they'll update the image with a two-oh image. And you can literally take the image, download it, and run it. Yeah. Is it free to publish? It is free to publish. The question was, is it free to publish? Any of you can build VM, VM Depot, or people download it. They choose what data center to deploy it in. Yep. Oh, okay. The question was, can we add something here? So when Yuri published it, he used his name, he didn't use the company name. Typically, you will see a company name. Like the... That's interesting, have a verified account. So the other Neo4j image, and that hypnosis, there are a consultancy SI in India. Having another folks there. I mean, I can vouch for them, but. So it's the verified one. You don't know that that's actually them. Right. So the idea is you should be able to enter a review, you should be able to enter a review, you know, like rate the image. Yeah, hopefully this, you know, it will start seeing it. Why? Yeah. So the plan, so to answer your question on Microsoft's plan, we have Microsoft Open Technologies, which is a HoloLens subsidiary of Microsoft. They are working with companies to onboard technology and enable us into Windows Azure. Right, so whether it's the normal labs of the world or some other companies, you know, bringing Redis to Azure, whatever it is, that group is really building those types of relationships. So, any other questions? I have a do-be-stuff for that too. Have the what? A do-be-stuff. Oh, yeah, yeah, so I really didn't get into big data, that's how there's HD Insight, which we just launched as a preview what a month or two ago, something. You could sign up, work with that. If you scroll through these different VMs, you'll see a lot of different options. But yeah, there's big data as well. But if we start getting into big data, that's another... Why is it considered to have SQL? It is, and you're absolutely right, whether you're talking about Hadoop or anything else and having all that stuff. But I think there's a session this week on that. So, any other questions? I think I'm down to like a minute and 10% battery. What's the good place for information on HD Insight and anything good rather than with what they're doing? What's a good place for information on HD Insight? If you go to windowsazure.com, there's an entire learning portal there. Yeah, and there's two things actually. So if you go to windowsazure.com, there's documentation which is like the learning portal and here's HD Insight where you specifically were asking. So it talks about how to set up the preview, talks about the service overview and then there's tutorials. There's also a windows azure training kit. This gets updated almost monthly and every month we're adding additional downloadable content and demos and you know, you install it and it has not only dotnet demos but other languages as well are included. And then if you're interested in the APIs to the actual platform, there's a windows azure rest API references in MSDN where you can look through like here's our storage service APIs if you wanted to build a layer on top of some other language that we don't support, for instance, you know, here's the table service rest API, right? But chances are you're gonna use a language like Merida, Python, a php.net or Ruby or Java. If you go to github.com slash windows azure everything we do with the languages is open sourced. Whoops. And so you can take a look at any particular language you want. You know, here's the SDK for Java. I know we were talking about Java earlier. And you can take a look at the support we have for things like table storage and all other facilities. So and if you find any problems, feel free to do it, you know, work it, fix it, do a pull request. We have people doing that all the time. Any other questions? I thank everybody for attending. I'll make the slides and links available. I'll go tweet out as soon as I blog it. I appreciate you spending your morning with me. Thank you. Okay. Thank you.