An Overview of Ignition’s MongoDB Connector Module

Speakers

Matthew Raybourn

Sales Engineering Manager

Inductive Automation

Earlier this year, we introduced a connector module that allows an Ignition Gateway to integrate with MongoDB. This session provides an overview of MongoDB, outlines the connector module's capabilities, and demonstrates how you can most effectively leverage it to elevate the functionality of your existing deployments. 

Transcript:

00:03
Matthew Raybourn: Hello everyone. Welcome to ICC. And welcome to today's session on the MongoDB Connector [Module]. We'll be going over the connector a little bit on MongoDB itself, and also look at some different examples and use cases and how you can actually leverage this different kind of database. I'm Matthew Raybourn, Sales Engineer from Inductive Automation. So I'll be walking you through all this. So just to jump right into it. So for those that aren't familiar with the MongoDB Connector it's a part of a series of cloud connectors that will be available not just for [Ignition] Cloud Edition, but also for standard [Ignition]. So you'll... You should expect to see more and more of these different types of connectors show up. It allows you to connect to a MongoDB database. When you actually use this, you set up this module, you'll see a new option in your configuration for the MongoDB.

01:09
Matthew Raybourn: So it won't be part of the main database connectors there that you'll see. It'll be its own MongoDB section, and, like I said, it's available for standard. You can go today, download it, install it in your system, run it in trial mode, and start playing around with it. In addition to this of course, Cloud Edition will just continue to receive these updated in new modules over time. So if you are also using Cloud Edition then you'll just automatically get these different modules. So moving right into the module itself, what does it provide? It allows you to connect to a MongoDB database, but it does provide some additional functionality there. So first thing is it gives you a Perspective binding, and you can actually see that on the right side here. So that means once you have the module installed, you'll see that new type of binding inside Perspective in say a component, maybe a table you could bind to it.

02:11
Matthew Raybourn: In addition to that it gives you some helper functions in the expression syntax there. So ability to find and aggregate and do different kinds of things with that. And we'll show some examples certainly it also gives you some system functions. So if you're familiar with the system functions, the Python scripting in Ignition, it gives you some there for not just being able to query the database, but this is also how you'd be able to edit it to insert, to do our updates, to do removes, for example, so if you're planning on simply querying data out of it then you can look at the binding. If you want a little bit more control or if you're doing some kind of editing of some kind, then certainly you can look at these script functions and of course we'll dive in deeper on those.

03:00
Matthew Raybourn: So, if it is in the getaway scope, and the Perspective scope and Perspective binding, so your question that, certainly would likely come up is how do I use it inside of Vision? Can I use it inside a Vision? And you certainly can, if you aren't aware, you can set up different kinds of simple kind of requests to tell the gateway to run the script function for you and then return that result so that way you can still use it with other types of applications, especially if you wanna leverage it inside an existing one. So with MongoDB, if you aren't familiar with this type of database is it the same as SQL? Is it relational? Why is it a separate connector? And it's because MongoDB fundamentally is different than a relational database, is different from SQL.

03:44
Matthew Raybourn: It uses JSON-like documents. So you can store different kinds of documents you don't have to think of it as rows and columns inside tables. It's really just a collection of documents inside a database. And those documents, since they are JSON-like, they're easy to read, easy to manipulate, easy to map two different kinds of models and components inside Perspective. So that's why it ties in really well with that Perspective binding and just Perspective in general. But JSON is also very useful just throughout project anyways because it is just a very universal kind of easy-to-use format. So with that binding, you'll also notice on the right side here, you'll be able to select which connector 'cause you could certainly connect to different kinds of databases, different collections inside a given database.

04:37
Matthew Raybourn: And you have options there to query it. So the binding itself will allow you to find different kinds of documents or run an aggregate function. So you have also the ability to provide those different pieces of what is the query and that section down below really is the query itself. It's different from SQL. You don't write a SQL statement like select from wherever you actually build out a document itself, and depending on what you're doing that document could have multiple stages or layers to it. So with that, we have this different kind of structure there as part of the query if you're familiar with the expression structure, then it's going to be very similar to that but ultimately you can add onto any of these properties here and start using things like an expression syntax there, so that way you can combine it to other properties and really make this pretty interactive.

05:33
Matthew Raybourn: The other big difference here is since it is this flexible document database there is no schema that you have to define ahead of time. You could have documents that have all kinds of different fields, and there's no real rule to that. Of course, having said that, it is certainly a good idea to plan ahead, make sure there's a standard there, but it does mean that you are not only flexible in what you can build today, but also if things need to change down the line, then you can certainly do that. So you could have two different documents side by side, different fields between them. Maybe there's just extra context that you need to provide for one document versus the other. So it is, like I said, it's a pretty flexible kind of system.

06:19
Matthew Raybourn: Not only is it flexible, but it's also scalable. So a lot of database systems it certainly can be scaled horizontally pretty far. So you can have different shards, and each of those could have different systems in them, primary, secondary, that way you can have really high availability as well as distributed storage. So that way not one single system has all the data. You can actually distribute it which might help ease things like cost. Also geographically, you could separate these and just make it a little bit more effective, if you have a really large spanning kind of project. In addition to that, you can have things like a dedicated config system, different routers using Mongos, and then different applications could certainly hit these different routers to help load balance your application.

07:06
Matthew Raybourn: You can always just start with one simple little tiny MongoDB database just like I did, and be able to leverage a lot of these features that I'm showing here. But it does have that power to grow. So, of course, it supports standard product operation, so create, read, update, delete. They might have certainly different names like insert one or insert many. A lot of the functions that you'll find will have that kind of concept. They're in pairs, one versus many. So if you wanna just insert one single document, then you can do that or insert multiple that's certainly fine. So you'll see if you install the module, you'll now have access to system.mongodb functions. And so with that, you can start playing around with it. And again, because it's not in Vision's client scope, you won't see it inside your designer's client scope as well.

07:57
Matthew Raybourn: But certainly if you open up Perspective screens, you can start using those just as an example. One other key thing to note is you'll notice there's a replace one versus an update one. Replace will just completely wipe out the old document, replace it with a new one versus update. We'll actually just update in place, which means any old fields will still remain. So it's key to know the difference there and be able to use that so you're not mixing up when to use one versus the other. So there's also all of these examples. This example, here's from our online documentation. So certainly go to our docs.inductiveautomation.com, go down to the MongoDB section in the system functions, and be able to just use those right as is.

08:47
Matthew Raybourn: Besides the system functions and the simple kind of find features that you'd expect like selecting from a database, it also has this nice aggregation concept. So you can think of an aggregate as a way to do a certain kind of query like select from the database, but instead of just one statement, you actually have stages. And so you can provide different kinds of operators that will then feed their result into the next stage and so on. So you would normally start with something maybe like matching a certain field maybe sorting those or grouping them, maybe use the limit feature, even transform the document, and then you end up with the resulting output which is really just a set of documents as the result. So starting from the input all the way down to each stage is really just documents, then being manipulated, more documents and continuing.

09:41
Matthew Raybourn: So yeah, it is quite powerful in that sense that you can really construct some pretty complex queries. And at first it may seem a little complex, maybe there's a big learning curve, but really it's just step by step, a few different fields in the right place. And you've built a MongoDB query. In addition to some of the basic ones, there's some more additional kind of complex and advanced aggregation operators available. So if you had some sort of maybe document, maybe you had a legacy document that was missing certain fields inside the query itself, you can throw in new fields. So there's just an option there called addFields, and it does like you would expect, but not only that, the operations itself can be their own object with operators in them.

10:34
Matthew Raybourn: So you could, for example, have it automatically calculate a sum, throw it into a field, which then matches your interface. You don't have to go back reprogram anything. You just have the database build the document and result exactly how you want. Besides that, you could do things like automatically categorize them into different buckets. So you can even set those different boundaries and expressions yourself. You can use a lot of interesting geospatial querying. So if you had actual map data, geospatial data, or simple points of latitudes, longitudes. You can actually use a lot of query features to be able to find effectively very efficiently to the points that you're looking for. It also supports things like graphLookup. So if you want to build something that could take different points in a big network and be able to find maybe the least weight of a path, you can certainly do that as well as others like redacting different content from the output and limiting and skipping.

11:28
Matthew Raybourn: So if you wanna support some kind of paging system you can combine the limit and skip there. So there's a whole lot of different aggregates and operators out there. All of those are explained in the online documentation. So MongoDB has a pretty thorough documentation. So certainly I would recommend checking that out as well if you want to explore MongoDB. Now, besides that, there are some other application considerations to think about when you're designing an application with MongoDB. There's things like the retry writes option. So as is, if a write fails, if you don't have this option enabled, then the write just simply fails. Your application can certainly work around that. But there is an option to retry one time. So if you're on a network that has some kind of transient issues, maybe it's a little spotty, it's not that great, you could just simply have it auto-retry, and that might make the application just run smoother overall.

12:28
Matthew Raybourn: There is no just built-in store and forward as part of some Ignition pipeline here. This is just part of application design, if you need to buffer data that needs to go into MongoDB, then you would work that into your application, maybe buffer it into a local system first before sending it out to a remote system. So there is a kind of a cache and retry just standard practice there, but ultimately that's part of the application design. In addition to that, making it more resilient, some of this is just good practice in general with databases, if your query were to increment, some of this is just good practice in general database but things might make it important. So, if you were to run a query, multiple times, you would end up with the same results or for example, if your query were to increment, I say a column, if you were to click that button several times, you're just gonna keep auto-incrementing that column.

13:19
Matthew Raybourn: So the concept there is to set it so if that query were to say retry or someone clicks the button too much, they're a little impatient then if you do something else to set the value the way that you want so even if that query were to rerun, you end up with the same result so there's a lot of good practices around that. In addition to that, there's a concept called concerns. So both read and write concerns. So MongoDB, if you were to scale it out and have multiple shards, multiple replicas, do you want to make sure that your data actually ends up in those different places before considering it a success? So not just throwing it to one system and hoping it gets out there but it's kind of an option to allow it to require a certain amount of say, votes.

14:08
Matthew Raybourn: So then you have proper quorum across all your sort servers. And again, just making the whole thing more resilient. And of course, standard things like handle exceptions. So those are all part of application concepts. And, a lot of it is out of the box, will you do what you need. But, it always good to review what it can support and how it should work. So jumping into the next section here that I want to go through is not just talking about the module in MongoDB, but actually showing you different examples of how to use it. And certainly this will just scratch the surface, but there's some really cool things that you can do just right away. So typical just basic CRUD operations example that I threw together in Perspective, you're able to insert a new document, you can generate a new ID automatically generate, say random fields because it really has no schema required.

15:04
Matthew Raybourn: And then once you have all of that filled out, you can just insert it into your database. And then of course a table down below. So as soon as it is all ready, it will show up right inside the table there. So a lot of that is pretty standard. A lot of that you could do with SQL, maybe enough tables making it very dynamic, but this is all inside one collection, and I can just go through and insert a new document. Not only that, but if I wanted to insert a second document, it doesn't have to depend on the first; it can be completely different fields so you'll see I'll add the same fields, but then I'll add a custom one and fill it out and it'll actually show up. This is also a key thing to point out with something like a table component and other types of components, now that you have this very dynamic system, you need your interface designed in a way to account for that, because you could have one thing with a field that another thing doesn't.

16:01
Matthew Raybourn: And just like our table component, if you were to just do it as is the first row might have all of fields that it has, and then everything after that might be missing some data just from the display itself, just because of how it works. So this example here actually shows how to get around those kinds of things, how to design, just something simple to show that. And this resource and every other resource I'm showing is actually going to be available on the Ignition Exchange. So this first one here is a very simple just intro into MongoDB basic operations like inserting documents or even just updating one. Select the document from the table, add fields, update fields, update in place. This is also good time to point out that this insert update can work as an upsert. So you could do inserts, you could do updates, or you could do upserts.

16:52
Matthew Raybourn: And there's pros and cons to that. If you want to keep it simple, everything's just upsert, it'll either insert the document for you or it'll update the fields that you provide. Of course, the drawback there is if you meant to only insert a document it will just do the update and any existing fields will still remain there. So it is also a good idea to know when to do inserts, updates or places, or keep it simple, just do upsert. So that's just an extra field that you can provide in the update to be able to provide just an upsert. So as you see here as well, new columns added and then it's just automatically added and everything still functions, still queries. One last thing on this very simple example here is you've probably noticed that one specific ID field.

17:37
Matthew Raybourn: And of course, like any typical database it's good to have an actual identifier, an actual key there. So pretty standard way to do that. There's actually a function available. So you can import the MongoDB types and then create an object ID, which will then create a unique ID that you can immediately use. And so for this example, to create a new document ready to insert, all I have to do is just use a standard custom property in Perspective, update the ID with a new generated object ID, and then I could immediately begin using it. This also helps because it's done this way. If I were to click that insert button twice I'm using the same ID that I've generated one time, which means it's going to run the same sets against the same document, resulting in the same thing. Whether I'm running it one time or a hundred times, it'll result in the same final document there.

18:29
Matthew Raybourn: This next one, if you are familiar the with the Exchange, and different resources there. I have an Ad Hoc Trends example in Perspective, which takes the Power Chart and adds the ability for end users to be able to save what they've configured. So if you've used a lot of different components in Perspective, once you've navigated away and come back they usually just reset to what you have designed in your application. So this allows you to save what you've seen, especially something like the Power Chart. There's a lot of different options and properties there, which tags you're looking at, which time ranges. So it's easy to be able to save that. Now, right now on the exchange, you'll see that it supports SQL and then I've added the ability to just use MongoDB. So it'll automatically browse the existing connections and allow an admin to be able to enable that. And all that really does is throw a new document inside your collection.

19:26
Matthew Raybourn: And you'll be able to see that this is now available. And this is all behind the scenes normally. And so from the end user's point of view, they'll be able to go save, load just like you'd expect. So it functions exactly the same way from the end-user perspective, but now it can leverage MongoDB. So you have the ability to save a chart, just like any other, load a chart, just like any other, and it all happens in the same way. So you can see it just added that to the MongoDB there. And it is saving it in a JSON-readable format, which also makes it pretty easy to manipulate it outside of Ignition, outside of standard queries. So even third-party systems can leverage the data that's stored there. So yeah, loading, saving, all of that is literally the same experience.

20:19
Matthew Raybourn: Besides that though, since this is stored more of a standard JSON format for the Power Chart and its properties, you could actually go in using external tools or some other method and then more directly manipulate it compared to the SQL version, it just stores it as a JSON string. So you'd have to query it, and decode it, change it, and then re-encode it, and re-update it. And here you can even use the standard interface here from MongoDB to be able to just edit it however you want, and then ultimately reload it back into Ignition. So, again, it's pretty powerful to be able to just do that just using standard documents, it matches the Perspective property tree really well. So it's really easy to do that. And this Exchange resource as well is good for seeing how to easily take a property tree and turn it into JSON to be able to save.

21:10
Matthew Raybourn: So even if you don't use the Power Chart, it's still a good resource just as an example of using MongoDB. So this last example's a little bit different here, 'cause, a lot of the other things that I've been showing could technically be done with SQL. Of course in some ways MongoDB might've made it a little bit easier, especially if you look at the queries, they're very straightforward. But this one actually leverages the geospatial queries so you can see exactly what it can do. And this is just one of the many different kinds of operators out there. So I have a MongoDB database. I have it loaded up with a lot of example data, and that example data is also available from the MongoDB website, from their documentation. So if you want to be able to do this yourself, then you'll be able to do that, play around with it, and not have to think about spinning up your, or figuring out ways to get your own data.

22:03
Matthew Raybourn: You can just use some example data they have that's pretty interesting. I'll provide more information in the Exchange resources well of how to get started and test this out. But ultimately this is going to show different kinds of ways to leverage MongoDB using a geospatial information and querying. So right off the bat, we have a standard Map Component in Perspective, and then based on the bounds of the system itself, it's going to use that as the query, and it's going to find everything within that. And there's about 25,000 different points available in this database at the moment. But if you see in the top left, it only has to pull in exactly what is showing in the query. So it makes it pretty performant. The queries in this case on a simple system, we're taking just milliseconds.

22:55
Matthew Raybourn: And so very easily this can be thrown together, and it's a very straightforward query that will show as well. Besides that, you can do different kinds of queries to find maybe points within a certain distance. So in this case, I use the center of the map, and then as I move it around, anything within the circle will show up. You can do min distance, max distance, and manipulate the size based on the zoom level. And so I can find all of this data just focused in on different areas. So if you're trying to maybe find, say you have a large operation across a large area, you want to find maybe the nearest operator that could go work on something, you have the point of where you're looking at, find all the operators, say, find the closest one.

23:40
Matthew Raybourn: And, of course, the query could be more complicated than that. Roll in different kinds of factors there and it just gives you the result. Not only that, but you can actually use custom shapes. So it doesn't have to be something simple like a circle or a square or nearest point. It could be something that is not only complex, but even could be dynamic, in this case, actually have a simple system to be able to draw out points onto the map, that way, even dynamically, I can just filter this down to just a specific region, and it's really just as simple as a bunch of GeoJSON data, and the system can query that. So it's a really interesting way to query data out of it. And when I say custom shape, it really could be any custom shape.

24:33
Matthew Raybourn: There's a lot going on with that. So if I throw together a pretty quick example here, of course, Ignition logo, and it can just filter it out right there, and it's, pretty, pretty accurate of course. So it seems like it might be complicated to set all this up, but in reality, it literally only took hours. So just following standard MongoDB manual and guides and importing basic resources, it's one simple script here to query. It's just actually one line of code technically, and it's just doing an aggregate with different stages, and we're able to pull in information, say the nearest point. So what's the point? What's the distance? And do you want to provide a limit? That's it. And it will return the results. And then you can throw that into markers or UIs or use embedded views.

25:27
Matthew Raybourn: And that's pretty easy. The complex shapes one is actually even simpler because all it really cares about is just a series of points. So if you can provide a list of points and then just run a query there for the geo within, then it will, again, it'll just return the results for you. So yeah, it's not complex at all. It's actually a little bit simpler to do this than even that basic CRUD operation demo. So again, it's, I highly recommend looking into MongoDB for these types of applications. Besides that, since it is working with GeoJSON data, it's also very easy to bring that into the Map Component for a visual perspective here. So along with this example, there's data provided that has a lot of GeoJSON points over several hundred documents actually.

26:20
Matthew Raybourn: So when I say a lot of of data, it's hundreds of data points representing a geometry, and then it's hundreds of those documents and the system can easily query that, it can display, it's pretty performant as well. So I simply bind to that, run a very simple query here inside the Map Component for the GeoJSON. I match anything that has that geometry that I'm looking for. So even though I have other data in there, it doesn't matter. I filter it based on what I need, limit it just to make sure it stays performant just in case there's a lot more that I need. And I am missing a field that Perspective uses to display this. So I just simply use the add fields operator, and I can add that in there. And now I have all of that information, which is just a bunch of different neighborhoods just listed out for you right there.

27:11
Matthew Raybourn: And again, it just takes milliseconds to query and it's very performant there. So you could combine that visual element with the querying side of things. You could have all different kinds of operations and real-time data even shown there. So there's a lot more that MongoDB can certainly do. And there's chance we could certainly keep adding onto this. Of course, it can support things like event streams that are pretty interesting. So there's even an example, I believe, on the Exchange already where someone is taking tag data and loading it into MongoDB as a historian. And of course you could easily query that back right here. You could have your information displayed visually as well as show the real-time maybe data points on that. So with all of that, again, all of these resources are available and going to be made public in the near future for you to go download.

28:10
Matthew Raybourn: I'll have instructions in there to show the basic steps to get started. And again, it's very straightforward. You can use the demo, you can use Docker, spin up an instance of MongoDB, have Ignition connect to it, and then load it with your example data. If you have other data yourself, you can load it in there. It really just needs certain key points and locations and things. And beyond that, it can do a whole lot more. There's different text searching abilities and operators. There's an Atlas service for MongoDB that has even more capabilities. So yeah, it's definitely a pretty powerful module that you can start to leverage here. So, yeah, and final thoughts here. There's definitely a lot of information out there to get started, but it is a different concept. So certainly, hopefully this helps you tie everything together and then it gives you an example of how to get started. So whether you're at beginner MongoDB level that you've never seen it before, you can jump right in, use these resources or more advanced, it's at least good to be able to just easily pull this in and start using it. And so with all that, I'm going to jump over to Q&A here.

29:28
Audience Member 1: Is there any intention to incorporate MongoDB in with the alarm journal?

29:33
Matthew Raybourn: There's at least nothing on say the roadmap right now. Now, technically, of course, you could write your own queries, insert whatever data you want into a MongoDB. But that's something too I've thought about that might be just a good neat thing to have is incorporate it with some of the other modules like SQL Bridge or something. But there's nothing on the roadmap for that, but that's definitely good feedback. Would you use that, in your example is, do you have any specific case where that would really help?

30:04
Audience Member 1: So where I envision it being helpful is in a high-density alarm system where pruning is turned off. So you're talking about a hundred or a million alarm events in a database. Each event represents really three rows in the alarm events table for the active acknowledge and clear event. And then you have the associated data, which if you have five pieces of associated data, that's 5 million rows in that table, and it can become very costly if you want to calculate average time to acknowledge an alarm or average time that the alarm was active and things like that. Whereas I see that being a useful use case for Mongo, and that you could just have one object represent an alarm event, and then you can amend that as you act on the alarm and you go through that lifecycle.

30:55
Matthew Raybourn: Yeah, definitely that would be a pretty good use case there. So that's certainly feedback that we appreciate and we can bring that up with the team. 'Cause yeah, MongoDB certainly has a lot of applications.

31:06
Audience Member 1: Okay.

31:07
Audience Member 2: I actually would just wanted to build off of that question. My ears picked up when you said that there's already currently an example where someone's taking in tag data and writing that to the MongoDB Module. I guess you said that there isn't anything currently on the roadmap for module-to-module communication with this MongoDB module, but I would be extremely enthusiastic to be able to, I guess, use certain MongoDB's API calls in other modules. I guess, can you talk about today best practices for doing that? What I just have to do both API calls within a single script and just essentially take it from the MongoDB Module and put it in another one? Or how would you recommend doing that today?

32:00
Matthew Raybourn: Yeah, so yeah. As is, if you were to just install this module and use it today, you do have access at a gateway level, so the gateway scope level, which means to some extent it is already at least available for the other modules. So, in a, say reporting template, you could set up a script resource there, and that means you could, as is just query data out of MongoDB and use it inside something like a report. In addition to that, things like Vision, of course with the gateway-scoped messaging that I mentioned there's ability to send a message, have the gateway actually query it, and then return the result so you can even get around that limitation today. Beyond that, it doesn't automatically work as a history provider or a data sync, but you can certainly, like the Exchange resource was showing, that's available online, you can just take your tag data and load it into it, and that means you can also query it back out. So yeah, as long as you can run that gateway scope function, then you can query it from anywhere. But yeah, more specifically, if there was built-in ties to it, then yeah, that would be a great thing to have there. So, yeah.

33:12
Audience Member 3: So I think NoSQL is something we're seeing more and more popular from our customers. Are there other NoSQL databases, aside from Mongo, that are on the roadmap? And if so, what are they?

33:23
Matthew Raybourn: Yeah, there's a series of modules that we're still exploring, and there may be more info on that possibly tomorrow, like the Technical Keynote, for example. But, I'd say that the next likely module is more along the lines of something like Kafka, like something that's not NoSQL database, a little bit different, but definitely there's different kinds of connectors out there that will keep showing up. Besides that, there are some third-party modules available that can connect to things like that, say InfluxDB, there's others out there. So depending on what you need, there may be something there or other ways to connect to it. But if you do have any examples, any feedback, certainly just let us know. You can even let myself know directly or your salesperson or anyone really at the company, and then we can take that into account, 'cause yeah, we're open.

34:17
Audience Member 3: Awesome. Thank you.

34:18
Audience Member 4: Maybe more a beginner-type question, but in terms of config and setting this up, is it purely just the module you need to install or is there a MongoDB server you'd also need to connect to once you get that going?

34:33
Matthew Raybourn: Yeah, so the module itself provides the bindings and script functions and the ability to connect to it, but it doesn't provide the database itself. So you would either spin up a server or a Docker container. It's similar to databases in general in that way with Ignition. And so it'll function the same way.

34:53
Audience Member 4: This may be a little bit of more of just me being a little more naive coming to Mongo, but I was curious for applications where you could use Mongo in substitution as a relational database. Do you have any best practices for doing things like, not enforcement of the schema, but just where you would do some of that validation work upfront, I assume move it to UI or wherever data's coming in, or things like how to handle some relationships? I know it said it was a browse graph or browse for the relationships and parts.

35:28
Matthew Raybourn: Yep. So yeah, definitely if you want to try to enforce a schema, there's at least the ability from the interface, from the application side. And, to some extent the Ad Hoc Trends does do that a little bit because it does have to check that there's a collection and it has to have things in it, just because I made that resource so that it won't potentially step on some existing collection there. So I just check for the document and if it exists and it has the right fields, then yeah, you could use that. So that's at least one method. Potentially there might be other methods that might be more on the database side that would be a little bit easier. There's also things like indexing, which we didn't even cover, but there's, that's how the geospatial works as a 2D sphere index.

36:08
Matthew Raybourn: So there's definitely a lot more to it. So I'd highly recommend checking out the MongoDB documentation on that. And then as far as the concept of relational, using it like a relational database, it's possible, but you can create, say, just a field that points from one document to another document's ID or a list of documents, and that's how the graph lookup would work. You want to know where you're at and what you can connect to. But there's no, I would say constraint or enforcement on that, just like a SQL database, you could set that up and if you try to delete something that's dependent on, yeah, it would certainly give you that exception there. But again, you could at least from the application side provide some of that enforcement, but at the same time, yeah, it's a different tool used for different purposes, but there's some overlap there.

37:02
Audience Member 4: Would this be a good fit to persist a Perspective session in, and if so, can you just bind it and automatically insert an update? Or do you got to script the inserts and updates?

37:14
Matthew Raybourn: Yeah, so just like some of the other, the properties on the components, the session properties are still just properties. And so that is a pretty good use case there. If you're in the middle of something, you have all your settings saved as session props, you could then throw those into the database and then easily query that back out maybe the next time a user logs in, just query it, and then you're right back where you were. So certainly that would be perfectly good use case. As far as how specifically work, you wouldn't be able to bind to the mean, say, props, property, but you could underneath that include properties and then create a binding on that, that'd be perfectly fine. Of course for writing to that, you would need to use a script function, but otherwise querying you can use bindings. In addition to that, on that same note, if you had say some complicated process, you could save that state to the MongoDB, and of course you can currently do that in other ways, but MongoDB might make that a little bit easier.

38:20
Audience Member 4: What is, I've never used MongoDB before. What is the licensing on it? Is it open-source?

38:26
Matthew Raybourn: Yeah, so you can, I believe there's different versions of it that have different licensing and different support, and there's something called Atlas, a service for it. But I just went online and spun up the instance of it and Docker just completely opened. In addition to that, there was an interface as an image. And so some of those videos that you saw there, you could see the actual interface, like a web-based interface that directly connects to the MongoDB to C individual documents. And that was also just a freely available image. So I just spinned a container from MongoDB and a container for what's called Express, and it all just works together.

39:07
Audience Member 5: So from a container perspective and a geospatial point of view, does Docker need to be installed on the same container as Ignition? And if you're copying a schema from SQL, does it need to be there on the same server, on the same container?

39:28
Matthew Raybourn: So yeah, the question, the same container...

39:29
Audience Member 5: As you're using Docker or...

39:31
Matthew Raybourn: Yeah, if you're using Docker, those would likely be individual containers. A container just right off of Ignition standard image, container from MongoDB. Usually they're not within one container unless you do your own composition there, build your own, say with Docker Compose build something like that. So more than likely it'd be two individual containers. They could be part of the same stack connected to everything, internally. But yeah, that's the typical approach. They're more of a microservice type of approach.

40:02
Audience Member 6: Scale. Have you guys tested, when does it start to have a performance hit?

40:09
Matthew Raybourn: Yeah, so yeah, the question is scaling performance hit. So I, at least personally myself haven't tested it beyond the 25,000 or so data points, being able to query it that fast. I haven't done long-term, huge-scale testing. But that's definitely something that we're interested in benchmarking in general with Ignition. So SQL Tag Historian, so MongoDB would be no different. So yeah, it'd be interesting to see how we can push it, but yeah, I don't have a document or anything like that at the moment.

40:45
Audience Member 6: Excellent. Thanks.

40:45
Audience Member 7: Piggybacking off of that, does the, Mongo Connector, does it automatically include the horizontal scaling support out of the box?

40:58
Matthew Raybourn: Yeah, it should connect, 'cause usually, and going back to that diagram, there's a Mongo service, so we should be able to connect to that.

41:02
Audience Member 7: Okay.

41:02
Matthew Raybourn: And then it's like a router.

41:03
Audience Member 7: Makes sense.

41:04
Matthew Raybourn: So if you use that with SQL, then it should be the same.

41:05
Audience Member 7: Okay, thanks.

41:08
Matthew Raybourn: And there is an extra connection properties setting on the configuration, so you can provide extra things like setting retry rights and all that concerns through that. So there's probably even more settings there to, to help with that. Oh, we're just about at the end of time here. So yeah, I'd like to thank everyone for joining me today. And certainly if you have any other questions, not just MongoDB, but anything Ignition-related, just feel free to to find me and come ask.