 Hello, and welcome. My name is Shannon Kemp, and I am the Executive Editor of DataVersity. We'd like to thank you for joining today's DataVersity webinar, Data-Centric Infrastructure for Agile Development, sponsored today by MarkLogic. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. For questions, we'll be collecting them via the Q&A in the bottom right-hand corner of your screen, or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DataVersity. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and any additional information requested throughout the webinar. Now, let me introduce our speaker for today, Jim Clark. Jim is the Senior Director of Product Management at MarkLogic. Primary focus areas include financial services and Hadoop strategies. For joining MarkLogic, Jim was on the executive staff of various big data startups in the Bay Area, and prior to that, he spent 14 years at Oracle in various product management positions. With that, I will give the floor to Jim to start the presentation. Hello and welcome. Thank you. You can hear me okay? Great. Thank you, everyone. Thank you for the introduction, Shannon. Today, I'd like to take you through what we're calling the Data Center to Data Center in roughly two parts. I think, interestingly enough, for me, both of these parts somewhat map my career from when I started at Oracle and in my transition through the various big data startups and now to MarkLogic. I speak from experience as we go through a few of these scenarios. As Shannon mentioned, or maybe she didn't, but we'll take questions at the end. What I will say is that if there's anything that I can't answer specifically today, I will offer people to follow up with me directly and I will get the information that they need. So with that, I'll go ahead and get started. Since today, if you look at the world, it's very application-centric. As I mentioned before, in my career, I've really had two parts. I started my career at a large relational database company where part of the benefit there is one could move around organizations fairly free, which provided me a lot of opportunity to experience many aspects of the enterprise database in ERP businesses, both as a producer of product and as a consumer of the dog food we've produced. A typical life cycle from a data-centric application process is the first step is you design the application, determine the data that you need, determine the queries that you need, design the schema and indexing strategy, build the database, design the ETL strategy, load the application, change, repeat steps one through eight. That's a pretty typical flow and something I experienced while I was at Oracle and other companies as I moved forward. And particularly when I was at Oracle is as a certain point in time around the early 2000s, Oracle started acquiring companies and they were a mix of both small companies and large companies. And at the time, while I was at Oracle, we were managing a lot of our support systems and contract systems. And this was a very familiar scenario. When an acquisition occurred, we had to take the company's data, customer records, contracts and try to organize them into our existing infrastructure. We repeated steps one through eight, new times trying to fit this into a relational database, changing the schema. It became very challenging and we were not able to innovate as we moved forward because we spent all of our time just trying to integrate those new customers and the information that they provided. I'll give you an example here of kind of what the high-level architecture looks like. It all started out with a simple OTP system run your business. It was flexible enough to run the transactions and reporting requirements. When you needed to grow, you were able to check for some better hardware and some extra database license. In order to scale those quarter-end reports, the books are evaluated with marketing campaigns to bring the OLT environment to a crawl. Extra milliseconds of latency could mean lost revenue, so the solution was to create a new environment specifically designed to aggregate reporting. The warehouse required a dimensional view of data or some ETL to get the right data out from the OLTP system periodically. The design of the warehouse served very well for the original reporting requirements. However, with more data, as you think of increasingly clever ways to ask of it, you didn't have a plan for a particular dimension or your enterprise data warehouse schema. You typically have to sign up for a dedicated environment with its own representation of the data. These were in the dozens or may not be controlled by central IT or a DW owner. Advancing to dicing comes more bespoke DTLs. At a certain scale, right-and-increasingly large-scale database warehouse and storage vendors become unsustainable. In order to maintain some predictability of costs and performance for online systems, you have to do an archival process. Periodically older data is aged out into offline cold storage from the OLTP and warehouse environments. This is particularly tricky because you have to get just the right size, right-and-increasingly traversing all the relationships among the tables. Additional data is all about the context of the transaction. In a bank, it's customers and instruments. Managing the enterprise-wide reference data creates new relationships and dependencies across the data model. You can see it's very complicated. Additional complexity with each environment has the correct data for its authorized use and the directions and modifications propagate throughout the system. Additional complexity makes sure each environment has the correct data for authorized, sorry, I just said it, and then each new business line or acquired company, this process repeats itself. Most of these organizations will accompany disparate systems for managing particular types of unstructured information under an enterprise search umbrella. So this was pretty typical of what we experienced at Oracle. It became very challenging, daunting, and in some cases, what we decided to do is just keep the customer systems that we acquired online and through an ETL process, which didn't lend itself to any sort of real-time analysis, a lot of latency, and I think still today there's challenges in those types of environments. So some of the questions we would ask is, how do you determine in advance what's useful? Love the application. Can you go back and include the data from 1990 to 1995? If you need to be copying for every new application, listen to what happens pretty consistently, have to go back and move the data around, organizing in a different way for it to be useful. ETL consumes all resources. This is something we experienced firsthand. Anytime a new data type comes in or a new data source, have to either add a new ETL pipe or modify the existing one that's in place today. Too many technologies. In heterogeneous environments, it's very challenging to try and organize those technologies and come up with a standard reference architecture to manage things going forward. Too many old copies. We've lost control. We don't know where the master data records are. Trying to manage that is a challenge in and of itself. So that's kind of an overview of the application-centric data center. Another way to look at it is A to D, C, or any other ways to help. So I'll leave that visual up there as I sort of transition into where I kind of move to throughout my career and experience kind of the change into more of a data-centric data center. While working on the integration through acquisition, we're doing a lot of things in terms of organizing what we now call as big data. Different types for coming in from different customers, customers that we acquired, such as PeopleSoft and Siebel, there were a lot of smaller companies as well that were part of that acquisition treadmill. And as I mentioned in my slides before, it just became a daunting challenge trying to integrate that. We some ways had an advantage in that we had all the software capabilities we needed working at Oracle, but also it was a limitation. Interestingly enough, when we were at Oracle doing this, we realized that there was actually a pretty big business opportunity out there in the context of relational databases and managing a data-centric environment. And a number of us left and started our own company. In all, a big company for big data solutions at the time, that name had not been tagged. So it was something where we were just managing non-national content. These solutions that we designed were focused towards enterprise and the degree of difficulty we managed on the cloud, it was SaaS-based, and we targeted initially towards enterprise software companies. So in the course of managing this company, we pivoted to the financial services industry, specifically focusing on buy-side and sell-side analytics firms. Our focus became squarely on the data, and how do we unlock its real value to customers in a flash-flexible, real-life manner and ensuring it was secure. Again, it wasn't something necessarily at the time we constantly designed again, but by hanging our own shingle and working with other people's money and having to be extremely nimble and responsive to customers. In context of cost, we just couldn't deploy in the application-centric model and continue to exist. We had to look at another way to approach this. In this section, what I'm going to do is I'm going to describe a shift to a more data-centric orientation in the data center and what feels like a move towards a standard configuration or reference architecture so that we can explore the ever-dynamic customer needs and a way of turning the existing model on set. So the application-centric approach was based around traditional relational databases, and it really hasn't been able to keep up with the new types and volumes of data that we all see out there in the marketplace today. The structure that's designed around this specific application makes it difficult to accommodate change. Adding new data source means adjusting the entire stack from top to bottom where it's made assumptions about the entire scope or the requirements. A new source that we'll call the data-centric data center has emerged. The DC-DC provides a central place to accommodate data of all shapes and sizes, and then the late-find structures or schemas is only when you need it. This will just to maintain all the rich context around your data that you may not have known or cared about when you collected it, giving you the flexibility to adjust as you learn. And then the areas I'll cover is part of what we see as reference architecture includes a dupe, some local storage capabilities, elasticity, how to use the data lifecycle, all data is valuable, but some is more valuable than others based on time, based on business needs. The ability to do this pressing on-premise or cloud or both, to bring powerful data services to the fold when it's needed, to also provide a complete database platform that powers all of this without having enterprise-ready capabilities included in it. That's what I'm going to talk about with just describing Hadoop. As part of the data-centric data center, Hadoop is a really key part for us. Google's general use case, of course, is aggregating all the messy data from the web to provide an analytic sandbox for building search indexes and selling ads. As the ecosystem matures, more mainstream companies are looking to leverage Hadoop with and along some cases instead of the legacy data management infrastructure to provide more flexibility. Hadoop has three particularly strong use cases in the enterprise. Because Hadoop can accommodate any shape of relative data relatively cheaply, it's often used to store raw data and to process it for downstream analysis. Having an economical place to put large volumes of low-marginal value data has changed how we think about it rather than aggregating quickly and discarding the raw inputs or data that doesn't necessarily fit into the existing infrastructure. Hadoop makes it possible to keep all this data around. This will be traditional transformation and cleanup, but also things like specialization or logs or joint enormous data sets on the fly. When Hadoop is staged, Hadoop provides a reliable storage on commodity hardware. Built-in application makes the storage highly available and available locally. Hadoop provides performance and storage sequential I.O. Your own enterprise capabilities like role-based security and encryption are now added to Hadoop to its core. Finally, Hadoop provides a sophisticated distributed computation design to work well with its distributed storage model. This is a goal for building large-scale predictive models or aggregating across a population. With this new distributed storage and computation at your disposal, you still need a way to reach your end users. There are active queries and granular updates. A way to operationalize insights derived from Hadoop in an application. A way that doesn't compromise the flexibility that Hadoop offers. And because it's added to its core Hadoop as a file system, Hadoop can handle many different types of data having to pre-define the shape of the data or the queries will be executed against it. Hadoop provides a flexible, albeit archaic, to write queries across a terabyte or even a petabyte of data without having to be a distributed systems expert. And we are working with various Hadoop distributions and partners today to certify against our platform and we continue to work with them closely as we provide solutions out to the market. So moving on to the database, why must we choose latency queries and granular updates of course require database. Hadoop alone is not equipped for this type of workload. Popular tech press will have you think that to start right off between legacy relational databases and the popular new open source NoSQL, what if you have the best of both of these worlds, the flexibility and scalability of NoSQL along with the reliability and security organizations that have come to trust in mature relational database. That's what we contend is enterprise NoSQL. In order to document model and power developers more in line with the domain model of an app, fewer layers of abstraction. One of the defining features of most NoSQL systems is a flexible model more flexible than its relational friends. By energy and the NoSQL movement has been around the flexible scheme of empowering developers. The seamless data model has been touted as more in line with the domain model of an application with fewer layers of abstraction. For example, a patient visited a lab result in a health care application is likely coming in as a document and a significant portion of the workflow in the application logic likely also treats the patient visit as an atomic whole. The seamless, the thin rich contextual documents makes developing applications faster and easier. Letting and marshalling awkward ORM. It's not that you don't have to do any modeling, it's just that you can only define your data modeling as you need to support a particular business processor analysis. However, the schema under the document data model really shines as in data integration. By not having to declare a rigid data model upfront, you get the flexibility to load any shape of data. A well-fought indexing strategy will allow you to slice and dice based on the semantics of the data itself. In this scenario, all of your data may in fact end up being consumed. What Hadoop NoSQL does is allow you to evolve from an unstructured sparse to messy data without having to sacrifice consistency along the way. This is a example of how Enterprise NoSQL in our case-mark logic interacts with Hadoop. Hadoop is a heavy lifting, petabytes of raw and indexed data. Hadoop is a shared infrastructure, provides low latency queries and granular updates. The logic is deployed directly on the Hadoop file system. Data files sit side-by-side with other data in HDFS. There's single-source storage, availability, durability that comes with HDFS. It really amounts to a mark logic data that's co-located with Hadoop nodes or on its own dedicated infrastructure. Once it's immediately available for querying the update with full security. The next generation architecture Hadoop sits at the foundation. It's responsible for the heavy lifting across petabytes of raw and indexed data. NoSQL deployed on top of Hadoop like MarkLogic takes advantage of the shared infrastructure to provide low latency queries, granular updates for interactive applications. MarkLogic redeployed directly on top of HDFS. As MarkLogic stores and indexes data, its Hadoop file sits side-by-side with other data in HDFS, providing a single-source storage to manage and all the availability and durability that comes with HDFS. For real-time queries and granular updates, you can mount these data files to a MarkLogic database either co-located with Hadoop nodes or on its own infrastructure. Mounted quickly takes seconds. When mounted, this data is available for media queries and updates so that changes to the application code. So we see this as complementary approaches. By binding Hadoop and Enterprise nodes equal, you get a flexible scalable platform for building today's applications with today's and tomorrow's data. By simplifying the overall stack and reducing the number of schema changes in ETL hops, you also reduce the opportunities for your data management to divert that outcome. The data center is storage. These trends and challenges need to be addressed. Continue to investment in DUP and moving into production and more and more. But many organizations aren't seen to do that investment today. The clients have great promise but harnessing the potential capabilities has just been inside the grasp of operational teams because software couldn't easily adapt. As your data volumes grow, the cost of storage is going faster than budgets. You can say storage is cheap. Organizations need to figure out the best storage for their data. They really need a storage strategy to ensure that it's still usable in a timely manner. Three, we set out to address in MarkLogic how customers achieve greater performance. Let's take you through some shared storage examples here. With storage, you can get important data readily available for subsets that can perform to make your finance teams smart by leveraging the cost-effective cloud platforms to back up your data. Available for compliance officers to give your data scientists a place to perform analysis. You can influence governance, compliance, security policies over the entire data. MarkLogic allows you to store data across different types of storage. This in itself is not a new capability as database and storage vendors have been offering this hierarchical storage information lifecycle management for years. What differentiates our offering is the ability to easily and consistently move data between tiers without complicated and expensive ETLs as a duplication. In France, where it's first interested in querying leverages as indexes no matter where it's stored today. By allowing you to live at the most appropriate tier of the infrastructure, you can save money while still providing appropriate performance and availability for applications. Aligning storage strategy with the value and use of your data allows you to make smarter jobs among cost, performance, and availability. You can implement data governance policy and deploy MarkLogic data using a fluid mix of SSD, local disk, shared disk, and the Duke distributed file system as well as Amazon, EBS, and S3. Tier to tier allows you to line your infrastructure costs with your business objectives. For example, you can provide service level agreements in a single system to create a cost of ETL to bring offline content back to online and power operations teams without opposing burdens on your developer. Tier to tier storage. You can also find the data tiers based on a range index. Have to balance into what we call forest by tier. Move your tier to different storage. Tier or another tier are both the ones and all with no downtime and 100% consistency. It's the executable same APIs on all these tiers so you can write one app that run across them seamlessly and transparently. Phase of our tiered storage roadmap is the ability to read MarkLogic data file without having to first mount the database. We have manufacturers today that allow you to run MapReduce jobs in the MarkLogic database. These require you to go through the front door, scan the MarkLogic instance and query through the e-nodes. You need our indexes and security model but too much overhead you don't need. Out all, analysis needs sub-second response time. By keeping access to that data with a specific server process, we also get the way the vendor will lock in. This is a great update to this connector that we just shipped is called direct access. It allows any job application and especially MapReduce jobs to get the data out of MarkLogic without having to first mount the database. For our indexes or security modeling accessing the data you get a very long-term archival format and an efficient way to stream across the data with MapReduce. So let's take a look at the user use case and how to practice this example that came from the banking world is that they're very sensitive about their IT infrastructure, what they often feel is their competitive advantage. So I've analyzed both this example and pulled together a composite of several banks. Both the example I showed today are an introduction in roughly the shape that I've described. In derivatives trading business, front-office systems actually execute the trades. Customs are very widely and have evolved in innovation that come up with new financial instruments to change. Things don't stay still, they continue to move forward. People are around acquisitions and people are trying to innovate within the environment. This evolution typically has taken a very application-centric approach for eSphere assets. There's separate back-office infrastructure support, all the post-trading processing, such as clearing and settlement. And all the processes that it needs to be carried out and stay in great places as the regulators. This wasn't an intentional design, but pragmatic evolution over many years. However, it resulted in a patchwork of loose-connected data islands with brittle EL processes gluing them together. The key question the bank needs to be able to answer is, given all the trades that we've just executed, what are my obligations? The impact is just about every aspect of their business. One of the challenges that this customer presented to us and we were able to work with them to help solve is long-distance cycles to provide new instrument types to the marketplace, long-complex combinations of ETL and data models. They have had very limited visibility across their business, what was going on. With all the regulations that have been passed through legislation, governance, risk, maintenance costs, and siloed infrastructure, they have varied SLA's and access patterns which create an inefficient efficiency. If the architecture is a complexity and the difficulty of changing anything, the amount of time it takes to model a new financial instrument has been significant drain on the bank's ability to invade. By the time new application infrastructure is ready to rule out, six or 12 months later, the market place may have passed. Independent ETL and data models not only makes application development difficult, but it adds significant risk. For example, in 2008, it wasn't immediately clear that the bank's actual exposure to Lehman Brothers was because the data was spread out among many systems. With the complete picture of risk that they're often forced to withhold capital, it could otherwise be doing something more productive in the market place. Finally, scaling each infrastructure was difficult operationally because it provided an inconsistent quality of service. It was to realize within reason their data modeling didn't actually accommodate the realities of their business. So it is, unlike securities or complex transactions or complex contracts that vary widely by instrument, the world is also inherently document-based. In this structure, the world would receive contracts and cash flows as documents, interrelational tables, or optical objects in their applications. This object-relational mapping is not a new problem. There are many tools to manage this complexity. For the privileged nature of the relational model, it makes change to the data model very difficult at either end. It would take months to introduce new instruments. For the agility of their traders to take advantage of market opportunities, working with the documents throughout meant a lot less plumbing and fewer opportunities for error. The rigidity probably looks a lot like your original document, except without all the original content. If you tried to model every piece of content, context, and relational schema, you'd end up with something complicated and brittle. We're not saying that everything could be modeled as a document, but that there are clearly things that can be easily modeled as normalized tables. In a document database, if you want to work up a province of a particular piece of data, I don't need to change my database schema. I can set it up in line and continue to move forward with it. And adopting the data-centric approach is the ability to accommodate multiple SLAs. Not all data should be treated equally. In a small organization, a small amount of data accounts for most of the value. For example, current transactions are the latest news. This data requires high availability, interactive response times. However, as the data ages, along the long tail, its patterns change. The storage rate is typically not the data you keep running your business on. You may need to keep it around for regulatory compliance reporting, but it's not something that needs millisecond interactivity or highly available. Automatically, it makes sense to more than act this data off on cheaper storage. In economics, storage and computing allow organizations to keep the long tail around. Much of this data may not need to be online immediately or queryable, but should be accessible to quickly spin up for analysis, then fund down again to conserve our compute resource to see how this plays out in our composite bank. This data would be highly available for query and granular updates. Performances keep, but predictability of performance is just as important. So these are current transactions in the last 120 days. This shows as the current data falls out of the active window, it doesn't require the same amount of availability and performance guarantees of the active data. However, we don't need to keep it around for historical transactions and supporting phone, email, and message records for regulators. They need to be able to access this data, but typically in seconds or minutes, not milliseconds. This allows them to be more densely packed in really cheaper storage. In addition to the data that you need to keep around for compliance, they also have the ability to access to the very long tail to unleash their data scientists. This is something they might be able to recognize the patterns of fraud or develop new trading risk models. The analysis isn't necessarily none upfront, but the wrong inputs around to accommodate new ideas to quickly or to account for the context they hadn't understood when they first collected the data. So this cheaper, reliable storage and large-scale compute infrastructure is ideal for this. Writing an entire petabyte live for real-time query for a school of 10 hosts to accommodate ad hoc analysis, grab the gigabyte or terabyte subset of data you're interested in, map out the database, run the analysis, and tear it down. All of that moving the data from where it resides in HDS, a system that's constantly changing. The key is to keep the performance of predictability in the active tier and the cost low in the compliance and analytic tier while being able to easily and reliably move data to the most appropriate environment. You're able to allocate the most expensive infrastructure to the most important data while keeping the long tail and raw impents around for compliance or scenarios. We call this tiered storage. Of course, database vendors have been selling this concept that's tiered a hierarchical storage for a long time, which makes this approach different is documents throughout out. It's the benefit of multiple storage tiers without having to go all in on relational views of the world and integrating with the data. You're able to align the infrastructure with objectives. The volumes are increasing, but IT budgets are not. Tiered storage allows you to align your objectives. All data is valuable given a period of time. Some is more valuable. So then on this portion is, we are able to optimize storage and be able to organize it The value of data through tiers enables folks to save money. They're still able to enforce their data governance and the data is always available in the data-centric data center is a elasticity. One of the challenges that need to be addressed are continued investment to do and moving into production more and more, but many organizations aren't seeing enough value from that investment. So elasticity can help you know when to scale, how much to scale, and programmatically expand and contract. With elasticity, it provides the tools to understand in detail how your cluster is performing and how to find bottlenecks in that performance. We provide grain-grain tuning parameters, operation of indexes, and cash sizes, etc. Clusterization APIs to expand and contract clusters programmatically on-parameter in the cloud. And we provide continuing online rebalancing of content across the nodes to keep performance optimal for your cluster site. You can also use it by using the cloud to be more proactive with SLAs and be able to manage to compliance. If we work these together, the data center, data center, you can use one so you have a security model to provide transactions when you need them. There's also a data model that's available where you can add more different types of data from different sources and not have to change the schema. We have elastic operations where you can go on demand and pull data and sequester it off when you need to and we provide simplified governance. Marker provides these additional benefits. With Marker Logic, you can use a dupe as a share file system, a storeier, or mixed batch with MapReduce and provide real-time work loads. We drive an enterprise database for real-time search, delivery, and analytics. We also provide a dupe investment without compromising enterprise capabilities, security, HADR transactions. We also provide a duplication in ETL to gain agility and reduce risk. We also provide stores to use dynamically and provide data backups, binaries, archives, archive index, segments directly via MapReduce. We currently support cledra, including Apache a dupe and distribution for Apache a dupe. We continue to work and work forward with the partnerships. We have a level across the data-centric data center. We have three categories that we like to focus on. We provide deliver more value, build more powerful applications. We have agility. We can prepare and respond quickly to change and address trusted. Our database has asked to compliance a lot of the relational databases that we have the additional ability to provide that flexibility to build applications in a quick and more seamless manner and be able to address the ever-changing needs of the market. The new and more data is both an opportunity and it's a threat in the IT center today. The last generation of data management really is not sufficient to be flexible and to be able to address the needs of the business. More opportunities and representations, transformations, increased risk and slow innovation. As stated in my example earlier, particularly through acquisitions or if you're just trying to load new data sources to expand the value of your business that in reference architecture that I just described, you can address once and reuse across workloads and the life cycle of the data. Noted to be able to provide indexing and updates for an active app. And to provide staging and persistence for analysts. I think that is my last slide. Kind of ended early, but I can entertain questions if people have questions at this point. And if there are any questions that I am not on, I am more than happy to take those back and get more information from any of you. Thank you so much for this great presentation and I'll give everyone a minute here to answer some questions. We already have one that has just come in. And just to remind everybody, one of the most popular questions that we always get is if they'll receive a copy of the slides in the presentation and I'll be sending that out within two business days. So by end of day Monday you should get an email from me with links to the slides and the recording of the presentation. So we have one question coming in here. Does Markologic provide replication between node residing in data centers on multiple continents? How does it perform on high latency connect? Well, let's start with that one. There's several questions built into the end point or I'll be reading it all and then you can start with the one. Does it perform on high latency connections and how does it handle a conflict resolution after a long-lived disconnection between nodes? Does it depend on acid? You know, I'm going to have to defer that to get, I don't want to answer this slightly incorrectly. So I'm going to, if I could take that question offline and get back to the person who asked it directly, I would feel more comfortable with that because I think it's probably going to get more of a detailed answer than is in my area of expertise right now. So if they don't mind doing that, I would be more than willing to get back with them personally. Absolutely. I believe, yeah, so we can certainly move on from there. Any other questions? We also have no problem, no rush. That was the only question we haven't come in so far. Everyone's pretty quiet today. I don't know if it's end of the week or what. If you have a couple of other questions, any other questions, there was one question about if we get confirmation that we took the course. Actually, if you need confirmation that you took the course, feel free to email me, Shannon, at the university.net, and I'll get you a certificate to acknowledge that you took the course if you're looking to get educational credits for a certification or a school. And we have a question here, another question. Are you able to discuss Marcologic's ACID support? Yeah. We provide ACID capabilities. I'm not sure if there's any nuance in terms of, maybe there's more of a follow-up question to that. Yeah, we do. We are ACID certified. We provide all those capabilities within our database. I think maybe I'll mention a little bit of history of Marcologic. So we've been around for about 12 years. I think one of the precepts of the design of the database, the founder and CTO came from an enterprise environment. So ACID compliance was designed as part of the initial architecture of the database. So we've had that all along. I know there's other NoSQL databases out there, particularly in the open-source space that do not have that capability today, but we are certified ACID compliant by the various boards. And one of our marketplaces is the U.S. government who certified us as ACID compliant. So I hope that answers the question if there's more detail that we can follow up. Sure, absolutely. No, that's great. Marcologic, do you support in-memory storage? I'll have a little help on that. Okay. And that's to be it for the questions right now. Let me see if there's any more that's coming in. I'll give people a few minutes. Can you want to mention about Marcologic? I think, you know, we've been around for 12 years. I've been at Marcologic for coming out on 7 months now. Like I said before, my transition from Oracle into startups, we ended up in the NoSQL space kind of a mistake. And, you know, I really see the value of that and was more of a frustration of what we were limited with when I was working at Oracle with the relational model. You know, I think that this is definitely, you know, people ask me, what's the difference between the day-to-day market today versus what it was back in the early Oracle days and then I almost think this is kind of a generation where there was the relational database that was with Oracle and DQ and Informix and all those and then probably about 30 or 40 others we can't remember anymore because they faded. The NoSQL space, I think is very similar to that where it was back then. I think the challenges in the marketplace with the social media, how data is now centered to a lot of the businesses that we interact with and certainly the business I was in before was able to have a flexible solution that does have enterprise capabilities and enables the customer or the consumer to be able to quickly write applications of certain needs of the business is really important. And Mark, I think is one of those companies that is on the forefront along with a few others that's helping to address those needs. And we do have another question coming in. How is data modeling practices changed in NoSQL and Hadoop environment? I don't have to follow up on that one. Looks like those are all the questions we have for you today. I will be sure and get you those questions, Tim, so you can follow up with everybody appropriately. We can include it in the follow-up email even if you want. That'll go out again on Monday with links to the slides and links to the recording of the session. Anything else you want to add before we go? Thank you. And again, like I said before, anyone who didn't ask questions through you who wants to get back to us directly more than happy to take those questions and get that back out. That sounds great. So feel free to keep sending your questions in and we'll get everything, all the information to everyone and I hope everyone has a fantastic day. Again, Jim, thanks for this great presentation and we will hope everyone has a great day.