 Here at NoSQL now 2013. The focus of our panel today is going to be on Enterprise NoSQL, getting NoSQL into the enterprise. What's it going to take? So we'll look at that. We'll look at what's next in the environment. I'm William McKnight from McKnight Consulting Group. I'll be your moderator and I'm loud, so I'll move that down. We have three panelists here today. I'm going to let them introduce themselves. Dave, you want to introduce yourself? Use the microphone, please. Rosenthal. Dave Rosenthal, one of the co-founders and engineers at FoundationDB. Which launched this week? Which launched yesterday in this room? My name's Dave Rubin and I'm the director of development for the Oracle NoSQL database group. I'm Pete Avan. I'm a senior engineer at MarkLogic. Great. OK, so I'm going to ask them some questions. We're going to try to get answers from all of them on the questions and as we get towards the end, I'll ask you all if you have some questions for them. So I'll be thinking of your questions as well. But I'll start with something really simple. Cloudera CEO, Mike Olson, made some bold comments recently, Dindi, about Hadoop replacing ETL in the data warehouse. So my question for the panelists, start with Dave here. Do you agree? I guess absolutely I do agree. I don't know how bold the statement that is. I think Hadoop is definitely replacing the traditional data warehouse. And I talk to people every day who are thinking about replacing their data warehouse with a Hadoop cluster. I was talking with somebody earlier who said there was sort of an air of inevitability about Hadoop. And I said, I think you said it just right. Nobody's using it yet. But when you ask somebody if they think they're probably going to be using it, they all say yes. In terms of ETL tools, I think there'll still be ETL tools. ETL is a batch processing function. I see somebody building that on top of Hadoop. Sort of is a piece on top of the Hadoop stack. I don't know if Hadoop replaces ETL tools. But that's my quick take. Dave? So I disagree a bit. So I think there's a really interesting place in the space for Hadoop. And in my view, it's all about scale. And so prior Oracle, I actually built a big data system in online advertising. And when you're asked to run a simple query, like select count distinct group by month over 400, 500, 700 terabytes of data, Hadoop is your only answer. But there are other requirements that the business asks you to do. Can I get real-time reporting for our users? They want to know revenue. They want to know how campaigns are performing. They want to know what audience segments are performing and not. Hadoop cannot do interactive reporting today. So down the road, maybe interactive query at scale, ad hoc query at scale with the advent of maybe Impala, Dremel, those things look interesting. But today, I believe Hadoop has an interesting place but not replacing the data warehouse. Yeah, I think it's a place with ETL, maybe, and flexibility with the information with Hadoop. And maybe that's the vision for Hadoop. But you're going to need a database to manage millions and billions of objects. And when you're working with a more operational store, you're going to want a database. You're going to be able to drill down and look at that information and validate what data is driving the decisions you're making. Hadoop's not there, right? It's a distributed file system with a compute layer. There's some flexibility, but I'm not quite sure. It's a bold statement, but it's a bold vision, and maybe it'll get there, but it's not there yet. There you go. OK, so guys, we've been through data revolutions before Walmart had their first terabyte database 20 years ago, first one. So why is NoSQL any different from these revolutions, Dave? From Oracle? Oracle, Dave? Hello? There's an eventual consistency problem. I don't think it is different. Like many other technologies, some things are driven out of pure necessity. NoSQL was driven out of the necessity to solve problems at scale, basically in online advertising, either search or online display, where no other solution could actually solve that problem. I think it's growing in acceptance and widening its scope to different industries, but I think the problem domain remains very similar. OK. Dave, repeat anything? Are you assuming those data revolutions succeeded or failed? I don't know if it was skeptically. No, no. Yeah, so I think that the thing that's driving NoSQL is two big things. Number one, the economics of traditional databases. And number two, being able to scale up data to huge, huge sizes. And that's not a revolution that I don't think that it's turning around. So I think we're on a long path with it. Yeah, I don't think it's a revolution so much as an evolution. What we see a lot of is there's a lot of the whole story, about 80% of the world's data is unstructured, and now that number is growing. In this network world, the amount of information that's just drastically, the velocity and the volume, is just ridiculous. And it's about gaining insight and driving decisions from that data and being able to handle that data. And you can't quickly get it into rows and columns. And the tools don't exist for that. And you want flexibility in your models. You want flexibility in your system to be able to ingest that information and start doing something with it. And this has been going on for a while, right? Mongo started out a double click. People actually were trying to solve these problems, and they couldn't solve them with rows and columns. They couldn't do it with a scale-up solution. They needed a scale-out solution. And so I think about that also with terms of MarkLogic. I mean, we've been doing this. We started solving these problems like 10 years ago. MarkLogic was founded a couple years after that. It was the first release in solving these types of problems that don't fit well in the rows and columns, more unstructured information, giving it semi-structured information. Yeah, so I think it's an evolution. So obviously the questions are coming from the perspective of what exists in the enterprise today, which is a lot of rows and columns, a lot of tables. But I think you started to answer my next question. If you want to hold that mic, why now? What forces have created our current data-rich environment and the tools now available to process, share, and analyze all this information? Why now? Why not? It's an evolution, right? It's the evolution, but I think now you have this. It's kind of exciting to see that everything is happening with all these different databases. But basically people have been struggling to do something with this information have not been able to, and they've hit the wall. And so now they're exploring alternatives. And people are driven by necessity, like David mentioned, it's not something like, oh, let's create some WYSIBang new technology. They're actually trying to leverage the data they have they're not able to use today. And so there's different, depending on what problems you're trying to solve, it's more like right tool, right job. Because in the no-sequel space under that umbrella, there's quite an array of different technologies, from Key Value Store to a document-oriented database like MarkLogic to et cetera. And so it's not just like, oh, no-sequels this, one size fits all type solution. It's what problem are you trying to solve, right? And so, and people are trying to solve those problems. And what we see at MarkLogic, it's all about the, you have your operational data, but now more and more it's, I have this world of information. If I'm gonna have data-driven decisions, I wanna be able to take in those external data sources and marry that with my operational data to be able to do more with the data that I have. And within the data I have, I have, I'm sitting on content that I don't even know what's there, I wanna look at that. And then I also wanna pull in these external sources and start to remix and analyze and, and so that's, I think that's where we're at. Dave. So, I think there are a few things going on really converging. So, you know, in the last few years you've had enough compute, sheer compute power to realize things like machine learning and classification, predictive analytics. So people have come up with interesting algorithms to analyze unstructured data where that, those kind of algorithms could not really be computed on hardware 10 years ago, right? So that's going on. So being able to take in an unstructured stream of text like a Twitter feed, you know, a fire hose, open that up. If you're a financial services guy, do sentiment analysis on that text and understand what's going on from a macroeconomic perspective, you know, wasn't, you couldn't even contemplate doing that, you know, five years ago, 10 years ago. So I think that's going on. I think the other piece is that people have looked at, looked at these schemalists types of stores and have found great use for them. They actually support, you know, agile development, which, you know, depending on how you look at it could be a beautiful thing or it may not be a beautiful thing. But clearly the ability to be able to, you know, model your store for your application or change it very quickly without going through that very, very painful, you know, relational modeling exercise, whether it's, you know, a star schema or a normalized model, it's painful. So there's that going on. And I think, you know, there's a lot more solutions out there in the market today. And so people are just looking at these things out there and they're making a choice in terms of what problem they're trying to solve. But I think you have a number of different things converging. Okay, all right. If you like. No, no, let's pass through to the next one. Okay, do it. Very well. So let's look forward a little bit now. So we've heard about some of the use cases of NoSQL here this week. What are some aspirational use cases of NoSQL for the enterprise that we may or may not be thinking about that we probably should be in our enterprises? So I've been trying to figure out at this conference whether NoSQL includes analytics or is mostly focused around operation or whether it sort of implies operational or not. I still don't know. Maybe somebody can tell me after this they've figured it out. But I think the obvious aspirational use case for the analytics side of the equation is the real-time analytics. And sort of what you're getting into is the limitations of Hadoop. Hadoop is a batch system. I hear people about trying to like micro batch Hadoop, get that batch runtime down to 10 minutes or something. It just sounds ridiculous, right? So I don't know how it's gonna happen. I think you gave a couple of examples of companies that are pursuing that. But I think the real aspirational analytics use case is getting to that real-time goal. I think in terms of the operational stores, to me the aspiration is to try to be able to actually consolidate the many disparate NoSQL databases and to some extent eventually traditional databases that companies are now using down into one engine. And I talk to companies every day that don't just have one NoSQL database, they have four or five or six. They've adopted all of these databases, each one providing them a different data model. But I think a lot of them have an aspiration not to have to operate and run six databases to get that capability for their developers. Anybody else? Go ahead, Dave. So I'm gonna give you two answers. One is a selfish answer and it's something I've been wanting for years and that is search over the enterprise repository of unstructured data. You know, whether that's PDF, Word, source control system, I wanna know, give me everything that has to do with network latency that we've done in the last year. I can't answer that question today. I'd be surprised if any of you could answer that question in the data that you have in your enterprise today. It's all unstructured, it's all raw text and it's all basically unsearchable. So that's one thing I'd like to see. I think ultimately when you look at real, useful use cases, I think really ad hoc query at scale is probably, you know, is the holy grail of where NoSQL is going. Aspirational use cases. Yeah, it's aspirational, that's kind of interesting because Mark Lodzik, we do have search at scale over this unstructured information and Mark Lodzik, we're investing heavily in semantics and that's not just because we think semantics is cool, that's actually what people are asking for. It turns out there's facts within the data, there's facts about the data and there's the facts of the world and if I can take my unstructured data, throw it into a repository and do this search over petabytes of information but then I can model relationships among that data, what kind of new powerful searches are gonna help me to make those data-driven decisions in my enterprise. And so that's something we're very excited about. As well as the real-time analytics. And so aspirational use cases I think are also getting tools on top of the NoSQL, a lot of the NoSQL stuff that's out there is very infrastructure-y right now, right? And your standard BI tools are still bolt-ons to a relational model. And so like Tableau, Cognos, and some others have started to make strides in converting their applications on top of NoSQL repositories, which is very exciting. Their first pass, I noticed with one, when you have a real-time repository but you have some single-client memory-bound application that basically takes in information and you're looking at a static view, keeping those applications in sync takes a little update on the part of those applications, right? So I like the real-time analytics as well as the semantics. Okay, there we go, there's some good categories there. Now, we know that it's hard to replace something that's in place and working in the organization but are there any cases inside of organizations that are using traditional data management infrastructure that you see moving whole-scale to NoSQL in the next few years? Start with Dave from Oracle, if you have anything. I didn't catch it. All right, so I think there's a couple of things where, or a couple of use cases where people are moving existing functionality or business solutions. And it's around storing of image data. So when you look at applications, for example, in security, people that are doing image recognition, fingerprint, facial recognition, there's metadata associated with that data that they clearly wanna be able to look up very, very quickly. But really all you're doing is, is you're doing a get using some metadata attributes and you get back a blob and you deserialize it, you do whatever it is you're gonna do with it and then you're doing a simple put. So there are cases like that where we see people getting interested in using NoSQL to do that kind of stuff, especially when they're looking at doing scale out. Peter, Dave. Yeah, I'm gonna say that I see this all the time and maybe it's just by virtue of the people that come and talk to us, but every week I talk to people that are considering replacing an existing database infrastructure with NoSQL databases, absolutely. Somebody once came to me and said, well, isn't this kind of thing only gonna happen when somebody's rearchitecting their whole software because isn't that a big transition? And I sort of said, well, how often do you think a product needs to be rearchitected every five or 10 years, something like that to stay relevant? And how long does the rearchitecture of a 10 year old product take? Couple years, right? So by my math, at any given time, probably about 20 or 30% of all the software projects in the world are being rearchitected, right? And that's a lot of opportunities for people to think about their data infrastructure. And from my perspective of the people that I talk to, virtually 100% of developers are considering NoSQL as at least part of the infrastructure for their next generation application. Good point. Pete, anything? Yeah, I don't think rows and columns are going anywhere and so maybe it's just the playgrounds that I'm existing that I see as it's more augmenting that structural, what exists in the operational structured world with the unstructured, and basically augmenting those systems gracefully and providing interfaces for developers to quickly, like the agility, basically adapt and integrate with those systems. It depends on the use case, but I by no means think that NoSQL is a rip and replace for existing relational databases, right? And so it depends on the use case and the particular NoSQL being considered. But generally, there's a reason why those rows and columns, if it works well in rows and columns, keep it by all means in rows and columns. But if NoSQL's here to solve the problems that you aren't able to solve with those traditional technologies. Okay, so if we're talking about the enterprise, we have to talk about IT. So where are these budget dollars coming from for NoSQL? Are they coming from the business or are they coming from IT? And just how are we dealing with IT in organizations that are fairly entrenched with their SQL? Pete, you wanna start with that? Oh, it's the, who's driving these decisions and dealing with IT. Okay. So driving these decisions, I think it depends on the vertical. You know, I think we see definitely technology, the IT is the early adopters and the technology is driving business decisions and we see IT more embracing these technologies and then they're delivering that message up to, you know, the C-suite who's been calling, you know, wants to know more about this information, you know, about these new technologies, but the purchasing is coming from the business. You gotta be able to show you provide value, really. You know, are you solving the problem? And even if I solve the problem, what's the actual business value? You need to be able to measure that. And if you can do that, right, then the purchase will come, right? That technology is worthy. Yeah, but then, you know, but it's not so much with IT, I was just trying to think about IT. Like I said, they're driving these because they're exploring these two technologies to solve these problems for the business that they're unable to solve today. Central IT? Central IT. Okay. Yeah, so that's what I see, you know, but then so that's like in Hollywood, that's what we see some of our customers in Hollywood IT is really pushing the adoption of these new technologies, right? And then in others, like in research or information publishing, that's where more of the business, right, is more familiar in making the decisions with regards to the NoSQL solutions that we see more, at least that's what I see a more logic. How about you guys? You know, it's interesting. If you would have asked me that, excuse me. A year ago, I would have said it's driven by the developers who are getting, you know, annihilated by the business guys who are saying, you know, I need to know, you know, the unique users come into my site, you know, every month that are, you know, male 18 to 24 that are interested in, you know, sports. And the developers are looking at that question and trying to answer that, you know, over many hundreds of terabytes of data and are driving the decisions to buy the technology so they can actually meet the needs of the business. So roll the clock forward. Now we're actually seeing, you know, people at the CTO and CIO level that are basically saying to their development groups, you know, go out and figure out how you're gonna use NoSQL. So we're still seeing it being driven from the development folks who actually argue for the budget to solve the business problem, but we're now, we're also seeing it from the C level folks who are saying, you know, go figure out how to use this kind of stuff. Solution in search of a problem then. So the money is an interesting question, but money often follows pain and companies are willing to get rid of pain with money. And the pattern that I see a lot is that developers are really eager to adopt and work with NoSQL databases. It's an exciting thing for them. And oftentimes instead of trying to figure out sort of the way to integrate some existing, some new functionality into their existing data infrastructure, it seems easier to download and try this tool that, you know, is gonna give them a task queue and only has seven API calls in the whole library, right? Now, the problem is that you can download and learn 90% about a NoSQL database in a weekend in terms of the API, but you definitely cannot learn 90% about how to operate one in production in a weekend. So the pain comes from the operation side. From the ops people are left sort of holding the other end of this decision to adopt these NoSQL databases. And from my experience, the money flows from that. Okay, very good. All right, so in my talk this morning, I talked about some of the enablers of NoSQL in these enterprises. I talked about, you know, cloud computing, being accepted and having a strategy, open source being embraced and accepted into the organization. What else? I talked about data governance a little bit, but what are some of the things that organizations need to be doing? What sort of investments do they need to make in order to embrace NoSQL? I mean, like you said, you can just go out and download it, but how does that work its way into the enterprise and then into production? What are some of the things that should be in place? Anybody? Go for it. So I would say probably one of the most important things is you gotta give your developers time to get their hands on a NoSQL solution. So they can really understand what it's good for. There are trade-offs in every single development decision you make, right? If you're a developer, you know, every day you sit down to write some code and a good chunk of your time is in figuring out what the trade-offs are in what you're gonna do. And like anything else, using NoSQL database has specific trade-offs. And so if you dive into a project and you get, you know, three quarters of the way into developing a solution and you figure out, wow, I'm building a financial solution and eventual consistency isn't gonna cut it. You know, you're in big trouble. So I would say that is the most important thing. Really understand what it is you're doing and allow the developers to get their hands on these things so they can figure it out. Do you think ultimately the rules that apply to what enterprises are accepting today will continue to apply to NoSQL? Like governance, you need governance, you need return on investment, you need these sorts of things? Well, you know, it's really hard to make a general statement on that, right? So there are different parts of the business that require different levels of governance, right? You know, if you're building a credit card processing application and you have PCI standards, you know, that's a different thing than building a solution that's gonna take, you know, open up a Twitter fire hose and compute sentiment analysis. So really it has to be looked at case by case. Pete, you wanna come in on this? Yeah, what was the question though? What's the investment? What investments should an organization have already made in order to more fully embrace NoSQL into their environment? Yeah, because what came to mind for me was like awareness. I don't know if you know, it's more like people, what I tend to see is people see the worlds through a certain pair of glasses and that's a relational scale up pair of glasses with certain tools. And so this awareness that there's a new set of tools that can actually solve the problems that they're trying to solve and some that are in production actually, some of those problems that they're trying to solve have been solved. You know, it's a lot of great stuff here. One of the aspirational cases just real quick was a cloud, which I didn't even think about. And then Greenfield development is always wonderful for a developer, because when you're in Trinch and IT and you got this legacy system built over 20 years and your job is to modify, it's a huge pain, right? So to go play with a new technology for a weekend is fun and all, but it gets back to awareness and business value, right? That's the driver. It's not like, hey, cool, you play with this new technology over the weekend. How is that gonna add to our bottom line, right? How is that gonna help us to extract information out of here and drive our business decisions? Or how can we leverage that data to, you know, are we leaving money on the table by losing that information? Will our algorithms that we have be better if we stop dropping certain feeds on the floor because we just can't model them fast enough to get into our relational database, right? So everyone's wondering. So Dave, you wanna come in on that one? Sure. So I'm thinking about what these guys are saying and I'm actually still sort of formulating an answer. Investments are, the investment question is a really tricky question. What do you invest in? I'll tell you one thing that I see people investing a lot in and that's benchmarking. Okay, I see a lot of people spending a lot of time benchmarking different NoSQL systems and from my personal experience, the benchmarks are usually wrong and they're usually not very useful, especially to the actual applicability of the business. So I wish I could tell you what to invest in but one thing that you might wanna think about not investing as much in is doing benchmarks because a lot of people that I talk to spend a lot of time doing that and from my perspective, it's of dubious value. Sort of relegates it all to total cost of ownership where you're just looking for the lowest cost. Yeah, it's one of these things where NoSQL databases, it's a new market. There's a huge number of dimensions of differentiation among the products and so it's easy to sort of latch on to some things that you can measure about them because everybody loves numbers but I think I like what you said a lot about investing and learning about the systems and not trying to sort of boil it down into this one's 10,000 or this one's 20,000. Right, right. Okay, so how about tools and products? We've been talking about sort of the demand side. What about the supply side where you guys are? What newer tools or products do you see as having the most impact on the NoSQL ecosystem? It can be your own, I suppose. It's our own. No, you can go ahead. I'll think about something else. I would say supporting or getting closer to supporting something like ANSI SQL. So really today most of the NoSQL products are API driven which is great. That typical workload of I got to get data in as fast as possible with single digit or double digit millisecond latencies and I got to scale that thing out is really wonderful. Now you start collecting data. The first thing to business ask you is, I need some aggregation. I need to answer some questions. I need to start analyzing the data along these three different dimensions aggregated by this timeframe. And so I think probably the most productive thing we can see on the side of the tools is some sort of structured query language. And I think the juries come in and the verdict is SQL. You can see this at Google with BigQuery and Spanner. You can see it with Impala, Dremel. And so I think that's probably gonna be the biggest productivity gain on the tool side. I know it's not a tool, but of course once you have SQL you can take all the tools that live on top of SQL today. And now your world is wildly different. So do we have to rename our industry once we get to SQL? Well, I think it's inevitable really. Unless somebody out there can come up with a better query language. And I think there's no mystery why SQL has been so successful for the last, I don't know, 20 to 30 years. There was an object database initiative, I think in the late 80s, early 90s to try to topple that. It failed for one reason or another, but it's hard to see another query language that's really gonna become as popular as SQL. I mean, look at Hive, right? Why did the Facebook guys actually put a SQL processor on top of Adoop, right? It's just people wanna talk SQL. It's what they know how to do. It's quite a nice language for doing the different aggregations and data access that you wanna do. So Pete, Dave says SQL. What do you say? Well, I was thinking Agility, you went multiple. I think for no SQL systems is a benefit to having multiple points of entry into your data. There's something to be said for standards, definitely. And so, but right tool, right job. We are a document database for, we're a database for trees, essentially hierarchical information. We model that information in XML, so we support Xquery. We also support SQL. SQL is a wonderful language for rows and columns or structured type information. These higher level REST APIs though, there's something to that too for, when you go into an IT organization and people are used to programming in a procedural language like Java.net, usually you embed SQL inside one of these languages. And then you ask them to learn something functional like Xquery, that's a mental leap. It's also a new tool set, right? And the enterprise, it's all about making information as actionable and operational as quickly as possible. So we tend to wanna, you wanna give people the interfaces for the languages and the idioms that they're currently, the tools they're currently using. And so having those types of interfaces, I think is, there's something, it's very useful. But like, there's something to be said for having that SQL interface, because like with MarkLogic, we can put Tableau, we can put Cognos, we can put Excel, anything with an ODBC driver now can connect to MarkLogic. But there is a lack of application, a dearth of lack of applications for no SQL databases, because we're doing something different. It's no longer rows and columns. It's structured and unstructured, right? And what's that, I don't know what the killer app is, generally in the enterprise, everyone has a different definition of what that app is. And so all apps are pretty much custom built. So then it becomes, well, how quickly can you custom build that application on top of this no SQL system? How quickly can we get to where we wanna be? And what's the level of investment, right? But so there's probably a wide range of tools and apps. So far it's been on the infrastructure and also building, I think Dave mentioned tool for ops, tools around monitoring and integration, making it easy to integrate in that infrastructure. But we're seeing more development in that arena as well. But yeah, that's all we got. Dave, last word. So I'm gonna disagree with Oracle Dave a little bit. And I think that one of the, I'm Foundation Dave, he's Oracle Dave, we decided before. I think that one of the biggest lasting legacies of this whole no SQL little adventure that we're on here is gonna be that developers want different APIs for different problems. Though the idea of polyglot persistence of wanting a simple API to do a task queue if you just have a simple task queue is something that's gonna be, I mean that's the legacy, I think. And I don't think that things are gonna converge to SQL. I think that SQL is gonna continue to exist because it is an excellent query language for a variety of tasks. But there's a huge demand for things other than SQL. I think that the most important thing coming to the no SQL world right now is transactions. I think that's been the biggest thing lacking from the no SQL products that have existed over the past few years. And I just spent four years at FoundationDB building a product to attack that problem. So I think it's the most important thing. All right, great. Well let me check in with you now that you've heard the panelists a little bit here. Do you have any questions or follow-up questions for them? Let's start right here. Factors inhibiting no SQL coming into enterprises and into the cloud in specially regards to security. Anybody wanna pick that one up? I think one of the keys is the lack of rich security models in the products today, right? You know, you just can't build that kind of stuff overnight. You know, the relational database folks they've been around for ever. You know, that technology and those features have been built over the last 25 years. You know, cell based security, you know, rich authorization and authentication models. So I think the no SQL products will get there. It's just gonna take time. Go ahead. I think you partially answered your own question as you asked it, which is the cloud is a big problem for sensitive information. And one of the big challenges, especially, I'll talk about a class of enterprises that we speak to sometimes ISVs who are developing an application. And one of the big challenges is that they've been used to delivering a product on premise to their customers. And the backend was part of that product. Well, they now have this challenge where half of their customers are saying, well, keep shipping it to us because we wanna own the information in our own data center. And other half of their customers are saying, could you host this for us? Cause, you know, we don't wanna host this ourselves. It's sort of annoying. And this is a huge challenge in terms of backend cause now you need to have a backend that can both run in the cloud in a multi-tenanted infrastructure and also run on premise at a customer. And so finding a good solution to that is a real challenge and I think it's preventing a lot of people from adopting it. Pete, unless you have something quick, I was gonna go on, go ahead. No, I was just thinking, some of these NoSQL solutions are relatively new and MarkLogic has been around for several years. So we've had transactions. We're asset compliant. We have role-based security, support fifths, 120 SSL. So I just wanna bring that to attention cause I just don't wanna be, we put everything into the NoSQL bucket, right? And it's not all are, have the same history or investment that's been put into them. And with regards to the cloud, there's a sensitivity of information. There's also the elasticity. That's also who's providing your cloud. I work with Amazon. It's not the fastest machine of cloud infrastructure out there, right? So there's different costs, not even the technology, but your Amazon investment that you're willing to make there, right? And yeah, I think what we're seeing at MarkLogic is people have been looking at the open source solutions but now they're coming to MarkLogic because we do have high availability, disaster recovery, backup. These are the things you expect out of an enterprise database, consistency and different ways to, when it comes to governance and compliance and your single source of the truth, there's certain things you expect in an enterprise database, right? And maybe that's why those other technologies aren't being adopted, right? Is NoSQL precursor to a whole lot more open source coming into the enterprise? Anybody? I would say, yeah, you know, if the VC community keeps, you know, investing in rounds of funding, you know, one thing, one data point that I always think about is, you know, there's been only one red hat, right? So, and there's been a lot of open source. It's a very, very challenging business model, as you could imagine, right? You know, developers aren't cheap. People want to get paid and, you know, do the math, right? Yeah, I think it's inevitable. One thing that open source is great at doing is copying, right? When a product is laid out in front of you of what it should do and when a product stagnates, when a product category stagnates, I think that provides an especially big opportunity for open source to come in and catch up because the product roadmap's laid out. I think, and maybe I'm bad mouthing open source here, I think it has a little bit harder time innovating and there's a lot of innovation happening in open source, you know, SQL projects right now and wherever things go, though, whether it's closed source or open source or whatever, I do think it's inevitable that there'll be an open source effort to build a version of that functionality, but I think it might not be likely to happen until things have settled down a little bit more. Let's go with you. No, you, yeah, yeah, Spark, Sparkle. Anybody on Sparkle? It's a great, great idea. So, yeah, so actually, so the next release of Mark Logic, that's where we're investing into semantics and so that means the ability to load triples, model an RDF with a triple index and getting back to standards, one of the language we'll support is Sparkle 1.0 with some aspects of 1.1. So we don't have inference, that'll be some external service to start with, right? So, but off the bat, you'll be able to load your triples, have them indexed. Really excited, like I was saying, because right now you have separate triple stores and document databases, you don't have them all integrated in one system. So what kind of queries can you drive when you can look at those relationships in conjunction with full tech search over documents, right? And so Sparkle is a standard, you know, Mark Logic, our engineers sit on the committees, the W3C committees for Xquery, XML, Sparkle. Are you a plant? Because that was a great question. I love it. No, but, oh, nice. So, but we're very excited about that, but Sparkle, but that's part of a, you know, we have a roadmap for the next three years where we're gonna be building where, this is a serious investment. We're gonna continue to invest in semantics over the next two years. Great. Right here. We touched on that a little bit. The question is about data warehousing, anything more to add, data warehousing as a real-time platform of analytics. Okay. Okay, how's it gonna morph? I would say yes or no, right? The perfect answer, it depends. No, and really, so, you know, one of the things I really like, and as a vision, you know, Nathan Mars gave a talk earlier and he's, you know, the inventor of Storm. If you look at the Storm architecture, basically real-time streams-based, you know, parallel computation framework, very, very compelling for doing real-time analytics, you know, on a stream of data being produced, you know, by machine resources, right? So there's that, right? Easy to use, no, you gotta, you gotta write a bunch of code to make that happen, right? Predictive analytics, easy to do, no, you gotta, you have to find a data scientist that really understands a lot about statistics and data analysis to make that happen. So I think strides are gonna be made. I think, especially on the real-time side, when you look at things like Storm, because I think that's very interesting, but I think on the other side, you know, taking data that's part of your enterprise, that is in your operational data stores, classic transaction data, and being able to run data warehouse type queries, and especially, you know, operational data store as well as any kind of NoSQL data stores, I think that's still gonna be around for quite some time. Okay, let's get one last question, one last question. Who's got a last question? Okay, any more DBAs? NoSQL systems right now are pretty hard to run, so the DBA is the person that's running the database, I think they'll be around for a long time. Guys. I'll actually answer your question with a question. Will we ever be able to solve the out-of-disk space error? DBAs will increasingly work for the cloud providers though. Pete. I think it's the evolution, I think there's always gonna be a need for DBAs, but what those DBAs do, you know, I think because we're seeing the evolution of the data warehouse. I was thinking of a paper by Greenclumb called, back to your question, it's called Mad Analytics, and it talks about the characteristics of a next generation data warehouse, and I think a lot of those NoSQL solutions have those attributes of magnetic, agile, and deep, and so if anyone Googles that paper, it's an excellent paper, I'm not sure I agree with their solution, but I like the characteristics they describe at the data warehouse, but the DBA job is not going anywhere, right? Someone still has to, I just think there's actually gonna be more work because what we're seeing is more right tool, right job. Enterprises are more willing to bring in, you know, multiple systems if there's benefit, right? So they'll be learning new systems, it won't just be one with multiple databases, now there'll be a mark logic, and an oracle, and a foundation, and a Mongo, and a whatever, you know, depending on what problem they're trying to solve, at least for the time being, till we evolve to the next level, right? And with that, we're out of time. Thank you all for your great questions and interest. Thank you, panelists.