Oracle NoSQL Database Cloud Service overview

(bright music) - Hi, friends. Welcome to the Oracle University module on Oracle NoSQL Database Cloud Service Overview. I'm your host, Sara. Let's get started. As part of this presentation, we're going to cover five different topics. We'll cover modern application challenges and an overview of the NoSQL Database Cloud Service. Next, we'll talk about use cases and features, and then we'll wrap up with the different development tools that we have available to create your application to run against the cloud service. Today's modern applications face many different challenges. Applications are generating and ingesting large amounts of data at a very high speed. For example, IoT applications generate quite a lot of time series data that then has to be ingested. Application response time is critical to match users' expectations. For example, relevant product recommendations on a shopping website need to show up at the speed of every customer's click. With today's global, competitive, and dynamic business environment, enterprises expect innovations to happen rapidly to keep up with the users' needs and expectations. Applications demand a database management solution that can be deployed rapidly and is easily maintained. The application data models may change constantly and dynamically to meet various business challenges. They may include structured, semi-structured, or even unstructured data, and these different data models need to be able to interoperate with one another. Today's applications are expected to be always on. Customers expect non-disruptive, fast services. On-demand scaling of compute resources is a must-have for dynamic application workloads during different times. For example, let's say we take a company that sells goods. We can expect there to be a peak in activity during the winter holiday season, so we would want to be able to grow the ability of the service during that time. Then in off-peak hours, we would want to be able to reduce the services that are unnecessary. Businesses need a database management solution that addresses these challenges, while keeping their operating costs to a minimum. Introducing the Oracle NoSQL Database Cloud Service, which addresses many, if not all, of the challenges that we've presented on the last slide. The service as a whole is a serverless, always-on, fully managed solution by Oracle. Developers can focus on application development, without having to worry about managing things like the server, storage, cluster, software setup, backup, and restore. All of those sorts of things are managed by Oracle. It is also fully elastic. You just provision the throughput and storage capacity required by your application workloads. Resources are automatically allocated and scaled accordingly to meet the dynamic workload needs. The service provides predictable low latency for all types of application workloads, whether it is at its peak, or at its minimum, offering a latency of less than 10 milliseconds. Another feature is its flexible data models. It offers document, columnar, and key value to really capture any kind of data format that you may have. These models can interoperate with each other using a single application interface. It offers developer-friendly APIs, and is fully integrated with popular application development tools. It comes with fully enterprise grade security. It's very cost-effective, and lastly, and most importantly, it makes hybrid cloud, or multi-cloud deployment with Oracle NoSQL Database extremely easy. This enables enterprises to expand their business operations, open up new business potential, and opportunities. What do we mean by fully managed? Well, in this case, Oracle is responsible for the backend software and hardware. Today's modern developers really aren't interested in what's going on behind-the-scenes. They want to be sure that they can get the resources they need and when they need them to put forth the best application possible. The Oracle NoSQL Database Cloud Service allows developers to focus on the application and who can use the application, without having to worry about all of the infrastructure that goes on in the background. Here are some of the common use cases that are used by the Oracle NoSQL Database Cloud Service. Let's just highlight a couple of these. For social media applications, NoSQL Database is used for storing and querying user-generated data, like comments, ratings, tweets, chat sessions, and more. For IoT, data is ingested at high speed from device sensors from different locations and stored in the NoSQL Database. This data is consumed by downstream systems and analytic services to gain real-time insights. For customer 360 view, enterprises need to gain a comprehensive view of the customer behavior and preferences by aggregating data from a lot of different data sources. NoSQL Databases can be used to enable customer 360 service, delivering real-time customer reviews to business teams, like sales, marketing, service, support, and even more. This contextual insight can help enterprises delight customers with a personalized experience. For catalog data, information on products, people, and places can be stored in a NoSQL Database, and queries can run against this information. The examples of catalog data are user accounts, product catalogs, IoT, device registries, bill of materials systems. There's many of them out there. For online gaming, the game console client depends upon a NoSQL Database to store and deliver customized and personalized content, like in-game stats, social media interaction, and high score leaderboards. Online games require a very low latency response from NoSQL Databases to provide an engaging interactive game experience. User profile management and modern applications need to provide interactive, personalized user experience with complex service views based on user preferences, their moods, and other real-time parameters. Such applications need to access user profiles fast to render application UI for a real-time customized user experience. Other common use cases are content management, social networking, real-time big data, online advertising, anomaly detection, and even more. As of March, 2021, the Oracle NoSQL Database Cloud Service is offered in 22 regions worldwide, and this list will continue to grow as new regions become available. Many of these points have already been mentioned earlier in the presentation. However, let's chat for a few moments on what run anywhere means. Since we have both an on-premise database and a fully managed cloud service, we have a huge advantage over our competition. With the functionality of these things essentially being the same, this allows you to run your application anywhere. So what does that really mean? Well, it means that you can run in anyone's cloud environment. You can run in your own cloud environment. You can run on our cloud environment, or you can run on-premise. The same NoSQL application can be run in any of those locations. What if you have some data that you do not feel comfortable with it being run from the cloud? No big deal for Oracle NoSQL. You can run a hybrid setup, where some of the data is on-prem, and the rest of the data is in the cloud. You can use this using the same application. We support different types of data models, and you get to select which one you want depending upon what you need. First is the columnar schema, sometimes referred to as a fixed schema, or a relational schema. This is where you have columns defined, and then each of those columns has a defined data type. Then we have a document type of structure, sometimes referred to as schema-less, frequently referred to as a JSON table, or a document table. There are several different terms being used out there in the industry, but essentially this is a JSON object, and JSON objects have the ability to be variable, as all of the records, or rows, can look a bit different. Lastly, we have a key value. Key value is often referred to as a key value pair. You have a key, and then you have an associated value. So from a table standpoint, the table has two columns. Now, all of these different data models work with each other, so you can use the same SQL and APIs to work with any of these different data models. They all interoperate with one another. We offer both encryption and authentication control. Authentication is covered by Oracle's Identity and Access Management Service, which lets you control what type of access a group of users has and to which specific resources they have access to. Oracle offers better and easier governance with capabilities such as compartments. A compartment is a logical isolation of resources for usage and billing. Additionally, we offer policies with simple SQL-like syntax that are extremely easy to create, manage, and update. We also offer encryption both at rest and in motion. We are fully elastic, which means we have the ability to scale up, or down. Earlier, we talked about allocating throughput and storage capacity for a NoSQL table. Scaling these capacities dynamically can provide a very cost-effective operation for running your application using the Oracle NoSQL Database Cloud Service. Let's look at an example of a NoSQL table that is created for a website that has online activities during weekdays. Let me direct your attention now to the graphs on the right. The first graph on the top represents the activities from Monday on the left to Friday on the right. As you can see, the workload tends to increase from Monday through Wednesday, drops a little bit on Thursday, and again, it increases on Friday. Let's assume the support services does queries and insert operations to the table. The queries and the new data inserts vary every day based upon the workload chart. For example, we see on Monday the queries and inserts are the same. On Tuesday, we see insert operations are higher than the queries, then the reverse is true for Wednesday, and finally, Thursday and Friday have slightly different operational patterns. So based on the queries and the new data insert operations for each day, the right amount of write and read throughput can be provisioned to meet the demand. As you can see in the throughput chart, Wednesday and Friday require higher throughput to handle the higher levels of queries and inserts. Now, looking at the last chart on the bottom, you can see the operating costs for each day fluctuates based upon the throughput provisioned according to the demands, or the requirements of the workload. Businesses no longer need to purchase and maintain the infrastructure to support peak workloads. This avoids over-provisioning the hardware, and paying more than what the workload actually needs. IT no longer has to size hardware based upon the server capacity, or the OCPU. So how do we get this fast, predictable performance? Well, we run on the Oracle Cloud using Gen 2 hardware. The Oracle Cloud is designed to provide enterprise customers with security, rock solid reliability, and powerful management capabilities for large and complex deployments, all while beating industry performance and pricing standards. The Oracle Cloud infrastructure leverages the latest CPUs, GPUs, out-of-the-box networking, NVMe, SSD-based storage. From a raw performance point of view, the NVMe solid state storage is capable of millions of read and write transactions per second. Unlike most cloud providers, the Oracle NoSQL Database Cloud Service is never oversubscribed, so each tenant gets predictable high performance and low latency. To save on costs, different tables can be created for different parts of the business. In this example, each table can have a different capacity at different times based upon the workload. This picture shows the benefit of dynamic billing, which allows businesses to operate efficiently and cost-effectively. At the end of the day, what is the Oracle NoSQL Database Cloud Service, and how does it help businesses? Well, it's basically a client-server architecture. Let's take a deeper look into that. On the client side, an application interacts with NoSQL drivers. We have drivers available for Java, Python, Node.js, Go, and other programming languages. We just rolled out a Spring driver using Spring Data. The application runs database operations, like inserts, updates, deletes, and queries against the NoSQL tables in the server side. From the application developer's point of view, that's really all they need to know. It's extremely simple. NoSQL tables can be created in a matter of seconds. Developers can start right away to develop and deploy their applications. Businesses can focus on rapid innovations to better serve their customers' needs and expectations. Developers and IT don't need to manage any of the computing infrastructure, the software, updates, the high availability setup. All of the underlying computer resources and software maintenance are fully managed by Oracle to host the NoSQL tables. Database administrators manage the authentication, and the roles, and the privileges for accessing the NoSQL tables and the various application interfaces. Let's touch upon how the drivers connect to the NoSQL tables and the various performances of those operations. Each table has two key components. The first is the data component, which consists of the table definition. We support many different data types, including integer, string, binary, long, double, JSON, records, and many others, and as you can see in the simple example here, each column can be defined to support a specific data type. So the example that we have here is more of a fixed scheme type of approach. In this case, the primary key column is an integer. That's on the far left. The next two columns are strings, and the last column is a JSON data type. So we can intermix the different data types in the same row. The primary key is an index, and it's used to access the data. For a more complex table definition, shard keys can also be defined. The purpose of shard keys is to distribute data across shards for efficiency, and to store records with the same shard key in the same shard for a locality of reference and quicker access. Records that share the same shard key will be located very close to one another. The second component of the tables is what we call capacity. The table capacity indicates the resource limits that are allocated to this particular table for its operations. Capacities can be divided up into two types. We have storage and throughput. Storage capacity is expressed in terms of gigabytes. This is the maximum amount of storage allocated to this particular table. Throughput captures the reads and writes that are performed on this table. Write capacity is expressed in what we call write units, and read capacity is expressed in what we call read units. To discuss throughput provisioning, we need to talk about read units and write units and what those really mean. We have a definition of each of them up on the slide, and what I want to talk about briefly here is the notion of eventual consistency and absolute consistency. Eventual consistency is a consistency model used in distributed computing to achieve high availability, which informally guarantees that if no new updates are made to a given data item, then eventually all accesses to that item will return the last updated value. If you are an environment where updates are occurring frequently, then quite possibly with eventual consistency you can return what is often commonly referred to as stale data. So the basis of our read unit is eventual consistency. However, if you want to use absolute consistency, and we have that option available, then basically the charge for each I/O is two read units, as opposed to one read unit. With absolute consistency in this model, you're going to be guaranteed that you will always read the most recently updated value. Here are a couple features that I want to cover. That is time to live and our access via either API, or SQL. Time to live functionality is basically auto-aging of data. We have it at the table level and at the record level if you have a particular record that you would like to have aged out differently than what you set default for a given table. Secondly is our set of APIs and SQL. Within the APIs, there's a mechanism to perform calls within SQL. We have a very rich set of SQL, such that we can access JSON. We have complex filtering expressions with support for conjunctions and disjunctions, as well as SQL interoperability between schema-less and fixed schema. In the Oracle NoSQL Database Cloud Service, you pay for the throughput and storage you provision on an hourly basis. The throughput must be provisioned to ensure that sufficient resources are available for you at all times. The cost of all database operations is essentially normalized and expressed in terms of read, or write units. It abstracts the system resources, such as CPU, IOPS, and memory, that are required to perform the database operations supported by the Oracle NoSQL Database Cloud Service. The service does not charge you for the underlying system resources. It charges you for the read and write units. Here is a more detailed description of read units and write units. The different operations, read, write, update, and delete, may use different units. For example, if you perform a write, it will primarily consist of write units. What if you perform a read? You guessed it. It will primarily consist of read units. Now, if you perform an update, or delete, those operations will consist of a combination of read and write units. This slide covers an example of provisioned throughput and the simple API used to increase, or decrease capacities via a table request. In the parameters of TableLimits, we have set the number of read units to 2,000, write units to 100, and gigabytes of storage to 500. Now, let's look at how to modify those. To modify that such that you either want to dynamically increase it, or decrease it, you would use the exact same API to do that. In the example that we have on the screen, we are taking the 2,000 read units, and reducing them down to 1,000. Every one of the table request calls is a DDL call to alter the information of the table. Lastly, please note that there is a limit of four DDL calls per minute within your tenancy. Oracle NoSQL Database Cloud Service supports many common data types. Here is a complete list of the different data types that are supported by Oracle NoSQL Database Cloud Service. When it comes to connecting to the cloud service, you are going to need a series of connection credentials. On the left-hand side, we list the different credentials that you need to have. You'll need two Oracle Cloud Identifiers, or OCI IDs, a Tenancy ID, and a User ID. Down there at the bottom of the slide, we give a generic structure of what an OCI ID looks like. There is an API Signing Key, a Signing Fingerprint, and optionally for additional security, you can have a Signing Key Pass Phrase. Within the Oracle NoSQL Database Cloud Service, we have different types of resources. We have three primary resources that you will have access to. Those are tables, rows, and indexes, and when you think about that in the sense of a relational database, most people can very easily relate to that terminology of tables, rows, and indexes. The next set of slides cover some of the various permissions that we have to cover the different resources. As mentioned before, we have resources on tables, rows, and indexes, so we have different sets of permissions that can be assigned to each one of those different types of resources. This chart up here shows some of those permissions that are available for a table resource. For example, there's the ability to inspect, read, alter, create, move. Then what we have toward the right-hand side of the chart are the different kinds of REST APIs you can call, and what permissions those would need. This next table here, structured the same way as the previous table, shows the permissions for rows, where we are showing you the REST APIs, and then the various Cloud Driver APIs that need those various permissions, and hopefully the permissions would make sense to most people. For rows, you have to be able to read the rows, insert the rows, and delete the rows. Inserting the rows also covers things like updates. We also have what is called an upsert operation, which is a combination of update and insert. And finally here we have the third resource, that is, indexes, presented the same way as the prior two slides, except this one is focused on the index resources. This slide shows the permissions for the NoSQL driver requests. It shows the requests, the permissions, and the operation ID for each one of those. Hopefully, this gives you an idea of the different permissions that can be allocated and controlled, and what level you can do that on. Schema-less and fixed schema can interoperate with one another. Let's take a look at the schema-less definition on the left. Here, we have a primary key and a JSON object, which we've named content. If we were to take that exact same structure and convert that to a fixed schema model, then we basically take that JSON object and convert it to a record. There's the record definition on the right. We ask the same question to both types of data models, that is, we want to find all visitors to the website in November, who are males between the ages of 24 and 30 years old. The bottom shows you the syntax from a SQL standpoint on how you query that based upon whether it's schema-less, or fixed schema, and as you can see, the schema is 100% identical between those two different approaches. We offer extremely rich secondary indexing. We use path expressions to access JSON data. It's very easy to use. We can index scalars, non-scalars, composites, JSON fields within a JSON structure. You can index just about anything that you have within your database record. This is very, very powerful, and something that our competitors don't offer. The next couple of slides show you some of the rich offering that we have in our SQL language. We've color coded them with descriptions underneath the SQL to make it easier to look at and understand. On the far left, we have predicates, projections, and paging. On the right, we have group by and aggregates. For projections, you can do that with simple scalars, or JSON document fragments. You don't have to display the entire JSON document. You can just display a fragment of it. Here, we are showing you a where clause, and some of our string functionality. We're looking under the JSON field content demographic.gender for the values that start with a lowercase f. We can also sort, and then finally at the bottom with the limit of the offset clause, we have the ability to do paging. The limit clause specifies the maximum number of results to return. The offset clause specifies the number of initial query results that should be skipped. So if you have a very long list, you can basically display some subsection of that list that starts partially in that list, and again, as we already mentioned, we also offer aggregate functions, time extractions, group by, which is there on the right-hand side, where we're showing the simple aggregates min, max, average, sum, and count. Here, we're doing a year, and we're extracting the year out of a timestamp. We have the ability to, if you wanted to, extract the month, extract the day, hours, minutes, what have you. You can extract any of those, and here in this example on the right, we are also showing a group by. Continuing on this general idea, in addition to insert and upsert, we have the ability to do shard local joins and regular expressions. You can insert a new row, while upsert is used for updates. These all work well with the different data types and the nested data structures. The example on the left shows SQL that updates a row and a simple put operation to insert a new value into the map data type based upon the cookieID. The SQL on the left is doing a lot of different things, so let's break it down. We've got the set in there, which would be more of an update kind of operation. We have the add in there, which is more of an insert type of operation. Then we have the remove in there, which is going to do almost the equivalent of a delete. It's going to remove an element of an array, and then we have the put in there, which will put new arrays into an existing document. All of this, this combination is done via a single SQL statement. The example on the right shows operations on nested tables. This is a way to create joins between what we like to call parent and child tables, or sometimes refer to as nested tables. The nested tables clause is equivalent to a number of left outer join operations centered around the target table. In this case, the target table is the shopping cart. A target table may have ancestors, or descendants, which can go to unlimited depths. If data needs to be projected from the parent, the ancestors clause is used in the query. If the data from the the child tables need to be projected, then the descendants clause can be used in the specified query. The beauty of the parent-child table structures is each table is treated like an individual table. If you're retrieving data in the parent, then you don't necessarily need to access the child, or if you want retrieve data from the child, you don't necessarily need to access the parent. NoSQL supports the standard GeoJSON RFC 7946 structure. Each GeoJSON object has a type and a set of coordinates. We have points, lines, and polygons. With GeoJSON, we have four different functions to look at relationships between these different types of objects. We have geo_intersect, geo_inside, geo_within_distance, and geo_near. We also offer a geo_distance. A geo is geometry to determine the type of geometry that a particular path an object will take. On the right, we offer ID generation. Identity columns are a way to auto-generate values. You define the start point and the increment. The cache determines the number of values generated at any given point in time. In the example above, we have cache 1000, so we're going to create 1,000 entries at a time, and then cache those. There's also the ability, if you want, to recycle after you hit the max, so we're not showing the recycle clause up here, but we also have that functionality. Switching gears a bit to IDE plugins, we have plugins available for Eclipse and IntelliJ, which are very popular. Here are the three different approaches to access the Oracle NoSQL Database Cloud Service for testing, development, and deployment. We have a UI service, a cloud service production, and a local standalone client server NoSQL simulator. Through the UI console, a standard console interface provides basic functionality. You can do things like create tables, insert rows, update rows, select rows, and basic query functionality. You can't do absolutely everything through the UI, but it's intended to give you a flavor of the cloud service, get you up and running quickly, and help you develop some basic understanding. In the middle, we have the primary approach, which is using the cloud service in a production environment. You have your application, and have compiled in that application your driver. You can use that for deployment, for development, for production. That's going to give you the entire functionality. And then on the far right, we're showing you our NoSQL Cloud Simulator. That's a standalone, single process kind of environment that simulates the cloud. The beauty with the NoSQL Cloud Simulator is that there's nothing you have to pay for. You can test your application and make sure that application runs without having to pay any of the expenses involved with actually running in the cloud service. The UI is a very simple and easy way to get an initial experience of the service. You don't have to download any drivers, or develop any software. You can go through several of the screens to explore what's going on and test everything. The following slides will show screenshots of what the UI console looks like. Once you log into the console, you can select your compartment. As a reminder, compartments are where you group your table resources together. This initial screen comes up which lists the tables you've allocated in the selected compartment. It tells you what capacities you've allocated for your tables, including read units, write units, and storage. We also have some additional information, such as when they were created, and then on the far left side, we have the status. As you can see, the first three tables are in the active status, and the table on the bottom named foo was deleted some time ago. We also have the ability to monitor through the OCI Console. You can monitor all of your capacities, and what they're doing. You can monitor those at different time intervals, and take different snapshots. What we're showing up here is also throttling. We have this concept called throttling, where if you try to do more work in terms of read units, or write units than what you have allocated, then we will throttle those requests for you. Let's say you want to do 100 read units, and yet you're trying to do 200. We will throttle that 200 down to 100. When that happens, you could come look here, and look at the monitoring, and then you could see if you're being throttled. That could be an indicator that, hey, you might be getting into a time period where you need to increase your read units, or your write units. So that's a very good indicator and a very good clue to tell you that maybe you need to go and adjust those different capacities. Also for storage, the same sort of issues are there. So if you have under-allocated the amount of storage that you need, you could come and take a look, and see if there's been any throttling expectations, which would tell you to increase your storage appropriately. How is Oracle NoSQL different? From a high level standpoint, we have a seamless multi-model. We have key value, fixed schema, and schema-less all stored in a single data store, and as we saw a few slides ago, all of these interoperate with one another. We also have tunable ACID. We have shard local full ACID. We have parent-child tables, which is an easy way to operate on multiple tables in a fully ACID-compliant manner. We also offer adjustable consistency, including eventual and strong consistency. We offer a fully managed, throughput-provisioned, flexible, no lock-in service, so you can run as a fully managed cloud service in the Oracle Cloud, or if you want, you can run in someone else's cloud. We offer a full hybrid approach as well, where if you want to run some of your applications on-prem and take a sub-component of that application and run it in the cloud, you can do that too, and that's a very powerful differentiator that we have that our competitors do not have. Thanks for hanging with me. I hope you enjoy today's module on Oracle NoSQL Database Cloud Service.