This webinar helps you get started with NuoDB. Solutions Architect Boris Bulanov walks through installing and creating a NuoDB database and also showcases some of NuoDB's unique advantages such as scale-out and automated resilience.
Christina Wong: Hello, everyone, and welcome to our webinar, “Getting started with NuoDB.” My name is Christina Wong, and I’ll be the moderator for today’s webinar. I’m also the director of product marketing here at NuoDB, responsible for understanding how NuoDB solves customer and market problems, and communicating that both within NuoDB, as well as to the outside world. I recently joined NuoDB in November from Red Hat, where I was in charge of product marketing for JBoss Middleware application development platform product. And today I am joined by Boris Bulanov, who is the star for today’s webinar, and he is our VP of technology, and represents the voice of the customer within our organization. Boris is responsible for understanding customer requirements, and how NuoDB can address these requirements with a focus on solution architecture and return on investment. Boris will be walking us through how to get started with NuoDB, using our free community edition version for today’s example.
But before we begin today’s presentation, I’d like to review a few logistics. Our webinar will last approximately 45 minutes, and it will be recorded and made available for replay afterward. If, at any point in time, you experience a bad connection during the webinar, GoToWebinar will typically try to reconnect you. However, if that’s not working, please try closing your browser and then signing back in again. As Boris walks us through getting started, he’ll be sharing his console and some command-line inputs and so, if you need to, please feel free to use the zoom function in the upper right of your screen for a larger view of the shared screen. All attendees will be muted during the call, but we certainly welcome your questions. So, in order to submit questions, please use the questions back in the GoToWebinar control panel. And, after the presentation is over, we’ll be answering as many of your questions as time allows.
So, before I turn this presentation over to Boris, I’d like to just set the stage today and provide some context for why we are here. We get a lot of attention from organizations seeking to building new applications for the cloud or migrate existing applications to the cloud. Why? Because cloud environments, today, provide elastic scalability, cost savings, availability and flexibility beyond what traditional environments can typically provide. So, in fact, just last week, we published a press release about a customer who was facing this exact situation. Alfa produces end-to-end platform for lenders that do financing and leasing of assets like cars, airplanes, farm machinery, and more. And they have a large number of both on premise and single private cloud customers. But Alfa realized that, as the world moved toward cloud applications, the market expectations were increasing around customer experience and availability and, because of these trends, they decided that they needed to offer a highly available cloud solution that would cost-effectively scale as their needs grew. But, while organizations like Alfa, can easily scale out their web tier, their application tier, and their storage tier, their databases weren’t originally designed to scale. Instead, finding a database solution that scales, typically means giving up other important database capabilities in return for the cloud benefits. Specifically, many organizations don’t want to give up transactional consistency, durability, and true ACID guarantees, or even a familiar SQL interface.
And so, often, achieving scale-out benefits and cloud benefits can mean purchasing add-ons to your traditional database and, of course, that means giving up additional budget and resources and simplicity. In fact, when we look out over our common database choices, whether it be traditional databases like Oracle, Microsoft, and IBM, NoSQL solutions, cloud databases, or other new SQL solutions, each of these offerings has their own strengths and drawbacks of what they can offer. When customers like Alfa come to us, they’re often looking for a way to gain elasticity while maintaining ACID performance expectations and the familiarity of SQL. In fact, when Alfa chose NuoDB for several reasons related to cloud, plus traditional benefits, they got more than just elastic scalability and ACID compliance and the SQL interface. They also chose NuoDB because it can be configured to deliver full active benefits while saving customers up to 90 percent cost in database licensing fees.
As an elastic SQL database, NuoDB was conceived fundamentally as a peer-to-peer distributed architecture that provides database services. So, it appears as a single logical ANSI SQL database to the application, and that makes it very straightforward and easy for developers to work with. But, under the hood, both the in-memory transaction layer and the storage layer are comprised of process nodes that can easily scale out or back in, and be configured for a variety of requirements, whether it be performance, resiliency, availability, workload, throughput, or whatever else.
One great way to learn about NuoDB is to download our free community edition and start playing with the technology. And, in fact, this is exactly what Alfa did. They started with community edition. They found that the familiarity to traditional databases in terms of ANSI SQL functionality, plus ACID transactions, made it really easy to migrate their application over, and they actually did that all on their own. And just recently they have upgraded to our enterprise version in order to scale out, implement in active-active deployment, and to get official support for production use.
But Alfa’s not the only one. We have thousands of customers who have used community edition to explore NuoDB for use with their large production deployments, and also developers who use it as their database of choice in smaller projects. And a couple weeks ago, actually, we released a new extended version of community edition, which really showcases our ability to scale out across multiple transaction processes and across multiple hosts.
So, that concludes my introduction, and I’m going to now turn over the webinar to Boris, and he’s going to show you exactly how you can get started with NuoDB community edition, and take advantage of the newest functionality we’ve added to the project. Boris?
Boris Bulanov: Christina, thank you very much. And, everybody who joined us for the session, thank you as well for taking time. So, as Christina said, our objective for the session is very simple. First of all, it’s practical. We would like to show you practical view of NuoDB. But, secondly, because of our extension of community edition to be not bound to a single host, but now having a broader version of the product, which can incorporate multiple machines, multiple hosts working together, we felt that it would be useful for us to provide additional guidance to you. So, you can download the product and become productive and efficient and start experimenting with the product and start observing different applications, different workloads, yourself very quickly. So, you would be efficient, you wouldn’t waste time. And therefore, this set of slides is a very practical way to go through the steps. The current documentation of NuoDB has all of this available, but in a much broader way, much deeper way, and sometimes it’s difficult to get all the little pieces together. We hope that these slides in this presentation and our new interactions with you will enable this process to be much smoother and much more efficient.
So, as we go through this process, also wanted to outline couple of things, couple of themes to keep in back of your mind, which are very important. One of them is the notion of simplicity. This is probably the most important outcome, hopefully, of the next 30 minutes, is that working with NuoDB is simple. It’s a set of simple, predicable steps that can be repeated over and over and over again and, as you scale your system, you can just use the same operations over and over and over again. It’s not doing things differently, it’s doing the same thing more times. And that’s really the foundation for simplicity of a distributed system. Also, a couple of other things to keep in mind as we go through this process is that the fundamental reasons why customers find NuoDB to be so valuable to them is the notion of scale-out, right? The fact that NuoDB database is comprised of multiple active database servers, active database processes, which act together as a single logical database scale-out is very meaningful. And, as Christina mentioned, as customers move their applications from on premises into cloud, the notion of being able to scale-out becomes very foundational. And the last point is that, because of this modern database architecture, ability to tolerate failures are really baked into the NuoDB architecture. And in this sequence of steps that we’ll go through -- and you can see here, on the bottom of this, we have “survive” -- we’ll try to experiment and see how this is achievable in life. The ability to just step over failed components and continue operating, this is something that is very important and the faster you, as a practitioner of NuoDB, can get to that point where it can start experimenting with these types of scenarios, the better it is. And we would like to make it a little bit more efficient in terms of the process.
So, to step back, I wanted to start by a few words about NuoDB architecture, for those of you who haven’t seen this before. NuoDB, most important, function of life for NuoDB is that it’s a pure, functional operational-relational database. And what this means is we support SQL in full of its breadth. We support ANSI SQL 99, as well as we support ACID transactions. Those two properties are what all existing applications in future relational operational applications expect. But while on the outside NuoDB looks very similar to other database technologies, on the inside it is fundamentally different. NuoDB is -- a logical database of NuoDB is really comprised by number of processes. These processes are all active, some of them have different roles, but they all work together to collectively deliver this functionality of a single relational logical database. As you can see in this picture, we have on the inside of NuoDB a couple of types of processes, we’ll call them transaction engines -- TE for short -- and these are the processes which are responsible for connectivity to external applications, and they fulfill functions like SQL processing, SQL optimization, parsing SQL statements, caching records of the databases, exchanging metadata with other processes, garbage collecting records which haven’t been used in a recent time and so forth. So, these are -- this is really front end of the NuoDB database, and that’s -- they’re very important and that’s what we call memory-centric architecture at NuoDB, because that’s the -- these are the processes which actually store the data or hold the data while applications interact with it.
And then we have the second kind of processes on the bottom, which are called Storage Managers. Storage Managers are responsible for storing data on the disk. They’re clearly very important to provide overall ACID semantics, but they are a second line of defense, if you will, in the way the database operates. The important property of this kind of architecture -- properties of the architecture, first of all, the architecture is capable of scaling out. That means we can add new processes to increase database capacity, and that is very unique, and that’s really what the next generation of databases is being asked to do. Also, the outcome of this architecture, as I said, that because of the memory-centric nature of this architecture, the latency of the product is minimal, because data resides very close to applications -- it resides in the TE tier, which is very different from storage-centered architectures of traditional relational databases.
And probably another topic to touch on because of this multi-server architecture, NuoDB makes it very natural to span not only one data center, but multiple data centers, or availability zones. So, the engines can reside in different types of topologies, and NuoDB makes it very seamless, right? If you’ll think about what it takes to run traditional database into data center in active-active mode is both very onerous, expensive, and failure-prone. In the case of NuoDB, it’s opposite of all of that, right? It’s very natural. You don’t have to do anything special. You inherit behavior of the database in the single data center, and you just deploy those engines in multiple locations.
So, all of that makes this kind of architecture to be very unique, and that’s what we’ll start working through the process of, how do you configure the database? How do you observe this kind of a behavior in the community edition setting? And what it takes to start working with the system.
So, now to step back, I’ll quickly describe through the layers, if you will, of what one needs to do in order to enable a cluster of servers to work together as a single NuoDB database. The very first prerequisite, if you will, that one needs to configure is a set of hubs in which the databases will reside. In this case, just like in the previous diagram, the diagramer wants to maximize the topology of the community edition by deploying the databases from four hosts, one storage manager, and three transaction engine, as well as, we’ll allocate one house to actually house the application that will connect to the database. So, the very first thing, the prerequisite, to NuoDB is having those hosts and having network connecting those hosts to be correctly configured, so there’s no problem communicating between the different hosts. You can ping any host from any other host; there are no firewalls or any other kind of gating factors to the network being performant. It has nothing to do with NuoDB database, but you imagine that that’s-- you have to have the foundation before you start working with the database.
The next step is that we need to install the management layer. The management layer in NuoDB is comprised of what we call broker processes. Every host, which is intended to run a NuoDB process, whether it’s a storage manager or a transaction manager or a multiple of those, needs to have a broker running it. We call it a provisioning process, we provision a host with a broker. A collection of brokers establish a management layer. They communicate with each other. It’s a distributive people of its own, but the intent of it is to provide a single logical view of the entire, what we call, domain-- management domain, to be able to manage processes, observe processes, such processes down, bring them back up, relocate processes, and so forth. So, that’s the management tier.
The next later in our installation process is configuring a storage manager. Storage manager is a foundational component for any database. In NuoDB, that’s the first process which is started. A storage manager is responsible for managing what we call database archives, which is on-disc representation of the database. Once the storage manager’s up and running, we can then start transaction engines, which connect to storage manager and connect to each other. They form a peer-to-peer network of processes, which together act as a single logical database.
And then finally, we’ll actually take a look at how do we configure and application which connects to the database and interacts with the database. And that will be the sort of like the scope of what we’re trying to accomplish in the next 20 or so minutes.
So, the next set of slides -- and we’re going to go through the slides in detail -- they will serve as your guide as you go through this process. But the first step is really, as we talked about, is to prepare the machines and make sure they network properly. If using AWS, please refer to the Appendix A of the slide deck at the very end. At the very end we actually have a few coaching points for you to work with to configure the machines properly, so NuoDB can operate on them. The next step is install binaries on each one of the machines, and that is, you know, very straightforward, it’s just an install that you have to run. But we actually pointing you to a particular blog on our website, which will take all the mystery out of this process, but it’s a simple, one-step process -- a little different for different operating systems, but nevertheless very straightforward. And the last one that we have to perform is modify configuration on each one of those hosts for each one of the future brokers. And there are two properties that we need to click. Generally we use password “bird” for most of our setups in development and testing -- not in production, don’t do it in production. And another setting is something that we have to be reasonably careful about or understand how it works is a property called peer. And we’ll actually look at the next slide, what is intended use of this property. And once we configure these files, we can start the brokers, and once the brokers have started, the management layers provision, and now we can check the state of it, we can monitor it, but the system’s ready to go.
So, with that, let me switch to the next slide and give you a little bit more context in terms of setting for this property called peer.
So, to step back, in any kind of a distributed system, it’s important to understand, if you’ll think through the lifestyle of a distributed system, how do you-- how does the system come to life? How do you bootstrap it, right? And, generally, bootstrapping process is a unique step in the lifecycle of a distributed system, and it happens all at once, it happens in the beginning. And once the system’s up and running, then you don’t have to think twice about how the system really operates. So, this is the case with NuoDB. And the way we approached it is, amongst all the brokers, which are peers to each other, we have one broker, which we’ll call a leading broker, or a leader broker. And that’s the broker which is started in the first host that we’ll bring into the system. And the way we indicate that the leader broker is the one which, so, like a bootstrapping point for the system, for the property peer in the configuration file, we don’t set up this property. It’s empty. For every other broker and every other hosts which participates in bootstrapping, they have to point to a lead broker. Once the system comes up, then the system is up and running. It can go down. The brokers can come in in different order, it doesn’t really matter. But bootstrapping point is an important one.
And this is really the only, I would say, point about how configuring the system on a single host is different than configuring the system on two hosts or 20 hosts. You have to indicate who is the leader peer, you have to indicate that in the file. You can actually do it through other means as well, and once you do that, the rest of the brokers come up, the system is live, and you can proceed.
So, the next step in the lifecycle of our system is creating a database. And just following the slides will be good enough. This slide illustrates that first we have to start the storage manager, given our configuration -- remember, we have the host-4, just for consistency, we’ll dedicate that host to run as storage manager -- so, host-4 is where it’s started. Then we can start TEs -- Transaction Engines -- there’s a sequel of commands, which does start the Transaction Engine on a number of hosts -- Hosts 1, 2, and 3 -- and once we’re done with that, the system is up and running, it’s ready to go. If you have a minute, please check out documentation for a couple of additional properties, which are quite interesting and important. These are not properties in the configuration files, these are the properties which are passed either on a command line or through other means to the database, but they’re committed memory is something that is -- these are the important knobs, if you will, in terms of how database operates.
Once the storage manager and Transaction Engine’s up and running, we can populate the database. One of the ways of doing this is by using a utility which is called NUOSQL. NUOSQL, for those of you who’ve used Oracle before, very similar to SQL*Plus. I’m less familiar with Microsoft SQL server. I’m sure there is a similar facility there. But it essentially is a shell, which allows you to issue management or applicational commands. So, in this case, we’ll use the utility in order to an external file and execute SQL statements in that file to define the database schema and populate it with data. By the way, NuoDB installation come with this data. This is what we called a hockey, simply hockey database, which captures number of teams, players, how the players were scoring for a number of years, and therefore that creates a nice foundation for us starting to work with the database.
So, at this point in time -- just to step back and see where we are -- we’ve been able to provision a set of us hosts, which are connected to each other. The network is up and running. After that, we’ve configured the configuration files -- the default, that property file -- so the brokers can come up. We’ve then started the brokers, and brokers form the management layer. This is the domain and we’ll be able to, in a minute, actually observe and see how it behave sands how we can observe it. And then after it, we started the storage manager on host-4. We started the other TEs, and now the system is ready for operation.
So, the next step, I wanted to show you -- these are just examples, in practice there are many, many more tools -- but I wanted to grab so, like, one or two tools so our commands from each one of the areas of management and share it with you. So, the two utilities -- which are pretty key, and we already talked about them, but we’ll actually see in practice how they work -- one is called NuoDB manager, and that allows us to connect into the domain and start observing different components of the domain in a variety of different ways. And another one is NuoSQL client. NuoSQL client allows us to issue, again, various kinds of applicational (inaudible) commands.
So, with that, let me see if my network is up. Uh-huh. Actually, we are ready to go. Here we go. So, let me describe very quickly, in this case, what we have is -- let me just -- forgive me for one sec. Just let me make sure all hosts are available. So, in this case, what I have, I have a number of hosts configured in AWS, and they’re sort of like laid out based on the diagram that I’ve shared with you before. We have Hosts 1, 2, 3, and 4. These are the hosts which manage the database, or comprise the database. And then we’re going to run application client on host-0, which is this big guy in the middle.
So, before we actually go through the tools, I want to quickly show you, so, how does database actually look in terms of processes, right? So let me perform a command here, and we can see that there’s a number of NuoDB-related processes running on the system. One of them is called nuoagent, and that’s really the broker, right? It’s written in Java. And brokers connect to each other and form a management layer. And also there is the actually TE process running right here. This is NuoDB, right? You can see it’s connecting with a certain piece of the database. Now we’re going to go to host-4, and let’s issue the same command there. Right, so we just copy and and paste for expediency here. And we’ll see that this a is a storage manager. And if we look at the storage manager, again, we have the broker process running -- that’s great -- but also we have the same NuoDB process running on the storage manager machine. And this is significant. The point I wanted to make here -- it’s the same executable, which runs in different environments, in different hosts, but plays very different roles. One is Transaction Engine, another one is a Storage Manager. And this contributes to a real product simplicity. It can take the same binary and make it do different or perform different roles. So, it’s just one aspect of how NuoDB is delivered and packaged and operates.
So, the next step for us is, let me log into NuoDB manager tool. This is the utility that allows us to run a variety of different commands. As a matter of fact, let me just do a “help” here, and you can see that many commands are available to us. I can start with a first command called “show,” and again you can see, progressively you can see how commands are used. So, you can log into the shell and just start exploring what kind of commands you can have. But let me specifically issue a command “show the main summary,” and what this will allow us to do is actually look at how the main is configured and what components it has. So, just to make it a little bit more readable, let me reissue the command. Here it is. So, in this domain, we have four hosts with brokers running. All of them are happy, they’re all connected, they’re in a good state. And we also have four processes running, three of which are TEs, and one of is a SM. But this here gives us a very specific view of how the main is configured. Many other commands we can dive into configuration of a specific host or a specific process and so forth. But NuoDB manager allows us system-level view of the entire domain and all the databases that we may have.
The second tool we’re going to explore is the SQL levels tool, right? So, we’re using NUOSQL, which is -- as I said before, it’s almost like SQL*Plus command in Oracle -- and it allows us to do all kinds of explorations at the SQL level. So, for instance, we can see here the schemas here, right? Schema in this case is user, we can say, “Well, in this schema, what are the tables that we have?” You can say there is a number of tables that we have imported from outside. We can do other things, like, let us actually count records. This is like every developer’s first command that you try out is “count*.” And this is the table that we have. So, you can see that career perform will give us an answer. So these are like application-level ways of interacting with the system.
Now, let me show you some other aspects of how we can manage and observe how the system behaves. So, along the lines of user-specific, user-created tables and data, we also have system tables. And a couple of tables I’ll share with you. There are many more. The documentation will actually cover all of them, if you’re interested in broader NuoDB documentation. But system connections is actually a very interesting table, right? So, here it is. System connections is what we call a pseudo table, right? Pseudo table doesn’t physically exist; it’s computed in a fly as a way to formulate a set of answers for your SQL query. So, in this case, if we issue the screen, it shows us that we have a query right here, right? That’s the query we just issued. And also information about the connection that the connection number 81 was used to connect node 4. So, this system table gives us a view of all the active connections in the system at any given time -- very useful.
The second system-level table I wanted to share with you -- let me see if I can find it. I might not be able to. Now I’m curious. Little lag here. So, it’s a system nodes table, right? Nodes-- a system nodes table shows us a slightly-- a very different view of the system, which is very, very useful. It shows us that we have four nodes running, right, with different IDs. Those IDs correspond to the nodes we have in the management view. So, so far, so good. Running it on different hosts, playing different roles -- one storage engine, three transaction engines -- but this is the column which is very interesting, it’s a triptime. Essentially, it’s a round-trip between the engines, how they see each other. And when that becomes very important is just to make sure that your networking layer is laid out correctly, you don’t have extra latency, which you don’t expect here. But also, as you operate your database across multiple availabilities on multiple datacenters, ability to see the true latency between those is critical, because that’s how you can start optimizing the system towards taking advantage of locality of reference, certain usage patterns, locality of data, data residence, and so forth. So, these are different steps to optimize how the data is accessed, modified, and distributed throughout the system.
So, let’s go to the next way of monitoring the system. And I wanted to very quickly show you another example here. So, the previous commands we used interactively to see how the system operates. But you also can install monitors. Monitors can monitor the state of the system itself -- of every process of every host of the database component -- and it can be reporting on this continuously. And this command if you experiment -- when you experiment with it -- you’ll see that there is a lot of information which is coming out, and this information is useful, but it’s not really human readable. You need some other tools or some other tools to be able to integrate it together, or to bring it together to be able to sort through it and visualize. And that’s what we do in customer deployments. We have a number of tools and approaches to how do you consolidate this data? How do you process it? And how do you visualize it? So, as you start moving into production deployment, into larger deployments, that become critical.
Another example of monitoring is SQL-level monitoring, and here’s a command which allows you to do this. So, for instance, you can say, “Hey system, I’d like to see all SQL statements for this particular database, and this is the structure of the SQL that I’d like to see.” And once you’ve set up this monitor, the system will produce this kind of information back to you, and you’ll be able to capture it, analyze it, and work with it. Again, in this case, this may be human-readable if you use it for a short period of time. On the flip-side, you can just generate batch files, and then use other kinds of tooling to make those files to be usable. But the point behind all the management and monitoring is that you actually have lots of means of observing the system, of different tools that you can build around it, to be able to observe, learn, and react, and optimize. And in a distributed system, you can imagine that that’s very critical.
So, moving on, the next or last topic we wanted to cover is actually running the application. So, let’s take a quick look at that. So, how does an NuoDB application work? So, we can-- we’ll take a very simplistic view of this, as a Java application NuoDB doesn’t look any different to the application than Oracle would or SQL Server would. So, in this case, this is an example of only the most compact code, which opens up JDBC DataSource. Clearly, we’re shifting our own, but you can have DataSource -- you can use JDBC directly, and load the file dynamically for configuration, but in this case we’re accessing it directly. We’ll open up a connection. We create a SQL statement, we execute it, we continue the transaction, so you can have multiple statements in a single transaction. If something goes wrong, we can catch the exception, or you should be able to, the application should be able to get you the exception and re-try it. And, by the way, as a part of this sort of package or flags and sample source code, we’re providing much more sophisticated, so like, best practices implementation of NuoDB Java interface, so you’re welcome to download it and start working with it. If you have questions, we’ll be happy to answer them. But the point here is, it’s very straightforward. Your existing applications should have minimal change -- the only change will come in in small dialects, how SQL statements are structured, but we’ve had great success with customers pulling down community edition, importing almost entire applications to NuoDB, and then working with us in terms of productizing these implementations for their real application.
But now what we’re going to do here -- I just wanted to quickly show you an example of how we compile this application, and how do we run it? So, let’s switch back to our environment. Let me start the application here. So, you see that in this directory, we have just one file, very simple Java compile here. You see we only need one jar file. This is NuoDB JDBC jar file. We generate a whole bunch of class files, and now we can actually run the example. You can see that the simple program that you have access to is producing statistics about how the application is running. The important elements of statistics is that there is latency, especially with each transaction. Also, we’re reporting on the number of operations per second. And by the way, while we’re here, let’s go to connections and let’s see how connections are structured. So, here, because connections are computed at any given point in time, you can see we captured few transactions here -- few SQL requests, rather -- on different connections. So, the active connections are four, two, and eight. And because DataSource in NuoDB by default opens up 10 connections, you can have that there’s a bunch of connections open here, there are 10 of them -- actually, 11, including the SQL shell itself -- but only a few of those are active at any given time.
So, and, our little program came to an end, and let’s move on, and try a more interesting example with this setup. So, our next example will be the one where we inject a failure and see how the system responds to it. So, in this configuration, we have three TEs. And, in this example, we’re actually going to take one of the engines, database engines, down and observe how the system will react. What you can see is that as the engine goes down, a whole bunch of connections is severed. And, once connections are severed, the important thing is the system just continues to operate. So, when you are ready to experiment with this, you’ll follow the following process. First, you’ll check with the NuoDB manager tool the domain is up and running, we have a number of active engines there. Then you’ll see that you have a number of active connections. And then you’ll shut down one of the Transaction Engines. And what you will see is that as the application is running, at the same time, you’ll see that the application will incur a number of failures. Some of the connections will be severed. But the important point is that the system continues to operate. It recovers itself, it connects to other engines, and it just continues to go. And at the same time, if you check the connections after the failure, you will see that you only have two active engines. And those are the engines that will be used.
So let us quickly try to demonstrate that and see if the system actually operates in the matter that we think it should and that we design it to operate in. So, what I’ll do, I’ll increase the number of-- the length of time this program actually operates, so it doesn’t time out on us. So the next step, as the application is running, let’s go and check out the connections so we can see that there are three engines which are active at this particular time. We also can check the main summary. We can see all the engines are up and running. And now what we’ll do -- let’s check the operating system. So, what we’re going to do, we’re going to kill this client right here. Right? Let me make it a little bit more obvious here what we’re doing. So, here’s the process, right? This is a TE process. Its number is 21311. Let’s double-check... yep. So, in the NuoDB, this is the process that we see. This is the TE, Transaction Engine, that we’re working with. So now what we’re going to do, we’re going to do a very nasty thing, we’re going to kill this process, right? So, we’re killing the process called 21311. Here we go. And let met zoom into the application so we can see two things at once. But, as we kill this process, you can see immediately connections have severed. But guess what? The product just reconnected to other live TEs, and continues to operate. And that is really what we’ve been looking at -- looking for, rather.
So, let’s do another thing, another check. Let’s look at the connection, and you can see that we just have two active engines. But guess what? The connections are still active, and executing queries against those connections. And if we look at the domain summary, we’ll see that only two engines are active. But now, let’s go an extra step and get an extra credit for this. Let’s stop the application for a second, and we’ll go and we’ll restart the engine. I have the command available here. We’ll restart the process on the same host again. So, we’re starting a different TE process on the same host. So, now you can see it’s running. Let’s make sure the domain is properly configured. And it is. And we have, again, three TEs running, and we started the process with node ID number nine on the same host that failed us before. Let’s check on the processes. Yep. So, the processes are here. This is a new process, which has been started -- 21375. Let’s check -- 21375 -- so all the tools are correct. And now let’s restart our application and see what happens. All right and, as we restart the application, we go back to connections, and we have engine with no ID number five -- number nine, rather, is running and now we haven’t caught it with being active, but now it is active. So, you can see -- from connections we can see that all the engines are being used again.
So, this -- we’re proving our point, and let’s go back to our presentation, and really wrap up at this point in time. I think, stepping back, and looking at what we were trying to achieve is to give you a very definitive, short path how to go from download to something you can actually validate and observe and make good use of. So, if you just follow the set of slides, we think that your process is going to be much shorter than otherwise. And you don’t have to do anything else. Once you’re up and running, then you can start exploring different parts of the product. But this is the simple part.
Also what we’ve tried to demonstrate -- and, if you look back -- we used very basic tools. They were command line tools. There was no-- anything wasn’t magical behind the covers or UI. You’re in control of every operation. The reason why this is important is because, as the application scales, you don’t want to create new types of utilities or new types of approaches how to manage it. You want to take simple steps and just repeat them many times. And therefore you’ll be able to script interaction with those systems or you’ll be able to use a domation like Kubernetes or Mesos or a variety of different systems which would provide ability for you to automate operational aspect of large databases or a large number of databases. And that’s important.
Also, quickly, just to recap, that we saw multiple, active servers working together in collaboration to give applications impression of single, logical database -- that was critical.
And lastly, we saw that we just killed one of the engines, which is the most fundamental -- one of the most fundamental -- components of the system, and the system just continues to operate.
So with that, these were the points we wanted to make in this particular sessions. On this slide, you see that there’s a number of resources we’re packaging for you. You can either -- we’ll send out these slides to you, so you can grab and pull the slides and also access these other resources, but also wanted to let you know that we have other steps beyond that, where we have what we call a jumpstart program, which is confined use of the product for smaller customers, or startups. And we have other ways of helping you out. How do you move beyond using community edition to different patterns, to different applications and development efforts, via C-files and so forth. So, let me stop at this moment in time, just in case you do have any questions online for us?
WONG: Thanks, Boris. Actually, we do have several questions. Thank you so much for walking us through community edition and getting started. I have a few questions here and, in the interest of time, I think we’re only going to take a few. But we can answer additional questions via our text log, after the webinar is over. So, once question is, can you define what NuoDB domain is?
BULANOV: That’s a great question. I do want to jump into the details. But, domain is a logical construct. It doesn’t physically exist. But it’s a way for us to describe a management layer. So, all brokers together make up what we call a domain. It’s a set of hosts that ran NuoDB resources, physical resources such as engines and nodes, but domain itself is a logical construct.
WONG: Great. Thank you. Next question is, what type of community connections are use with the project?
BULANOV: Connection as a client connection?
WONG: It’s not entirely clear, but...
BULANOV: Yes. So, we use-- we’ll provide a number of applications APIs, and APIs include JDBC, C, and C++, as well as Microsoft technologies like .NET and C#.
WONG: Okay. Great. Thank you.
BULANOV: And they communicate with the product over TCP/IP connections.
WONG: Okay. Wonderful. Thanks, Boris. Let’s see. We have a few more questions, a bunch of questions coming in, but we can take a few more, I think. Which operating systems are supported for use with community edition and which, if any, deliver the best performance?
BULANOV: Great question. So, community edition is binary compatible. It’s the same product, full product, we’re just constrained in certain ways. So, the same platform is supported for community edition as for enterprise product, and it includes, for development, Windows and a number of Linux platforms. Linux includes Red Hat, CentOS, and Ubuntu. And for deployment, we support only the Linux platforms. We don’t support Windows for deployment. But applications are fully portable, so you can develop it on Windows and deploy the Linux with no problem. In terms of performance, there’s no -- it really doesn’t really matter, in terms of fasting in a Windows deploy -- a Windows development environment or on Linux. They should be comparable.
WONG: Great. So, this other person is asking: For evaluation, I have a single laptop. Can I use the same laptop for one TE and one SM?
BULANOV: Yes, absolutely, depending on power, or -- horsepower of your machine, you can run, you know, the smallest database we can have is one Transaction Engine and one Storage Manager. Community edition allows you for a larger number of both hosts and processes, and you can easily round two, three, four processes on a pretty beefy laptop. That’s no problem.
WONG: Great. And I’m going to take one last question, and like I said, please look out for a text log addressing the additional questions that are coming in that we don’t have any more time for. But are there database size or configuration limitations for community edition? And then, what if we need additional flexibility with our deployment?
BULANOV: Great question. So, as I mentioned before, community edition is the same product as enterprise, but it just has a certain number of limitations built into it. One of those limitations is the number of TEs and SMs, right? Three and one. But also it is the maximum size of the database, which we limit to 500 gigabytes. Five-hundred gigabytes is a -- it’s a lot of data, but these are the limits. If you’re looking for something bigger than that, larger than that, in terms of the size, not a problem, but you’ve got to check with us so we can find the appropriate types of avenues for you to move forward with us.
WONG: Great. Thanks, Boris. So, I want to thank for Boris for your time and I want to thank the attendees for participating in our webinar today. I hope it was enjoyable as well as informative experience. And please look forward to getting an email with the replay of the webinar, the record, as well as a link to the text log, once we get it up within the next few weeks. Thank you everybody.