Performance Analysis of MongoDB Vs. PostGIS/PostGreSQL Databases For Line Intersection and Point Containment Spatial Queries.
agarwal, Sarthak
Relational databases have been around for a long time and Spatial databases have exploited this feature for close to two decades. The recent past has seen the development of NoSQL on- relational databases, which are now being adopted for spatial object storage and handling too. And this is gaining ground in the context of increased shift towards GeoSpatial Web Services on both the Web and mobile platforms especially in the usercentric services, where there is a need to improve the query response time. While SQL databases face scalability and agility challenges and fail to take the advantage of the cheap memory and processing power available these days, NoSQL databases can handle the rise in the data storage and frequency at which it is accessed and processed which are essential features needed in geospatial scenarios, which do not deal with a fixed schema(geometry) and fixed data size.This paper attempts to evaluate the performance of an existing NoSQL database 'MongoDB' with its inbuilt spatial functions with that of an SQL database with spatial extension 'PostGIS' for two primitive spatial problems LineIntersection and Point Containment problem, across a range of datasets, with varying features counts. For LineIntersection function, the dataset consisted of two independent layers of horizontal lines and vertical lines with incremental lengths and their size varied from ten lines to ten thousand lines in each layer and another dataset with two layers, one of random lines of variable size and shape and another layer of a single line which is intersecting many lines of layer1. For Point Containment problem, the dataset consists of two layers, one of polygons in a space of different shape and size and another layer of random points in the space, some inside the polygons and some outside. All the data in the analysis was processed In memory and no secondary memory was used. Initial results suggest that MongoDB performs better by an average factor of 25x for Line Intersection Problem and 10x for Point Containment Problem which increases exponentially as the data size increases in both indexed and non indexed operations. Given these results NoSQL databases may be better suited for simultaneous multipleuser query systems including WebGIS and mobileGIS. Further studies are required to understand the full potential of NoSQL databases across various geometries and spatial query types.
 Good morning everyone. Myself, Arjun from International Institute of Information Technology, Hyderabad, India. Thank you. Yeah. So I'll be talking about performance analysis of MongoDB and PoZIS databases for line intersection and point containment queries. So first of all, why do we need an internet to route from one point to another? Why don't we deploy the server on the phone itself? Suppose I'm in Korea right now and I don't have a phone, I don't have a Wi-Fi connection, but I want to come from my hotel, from my hotel to this hotel. So how do I come? I need to query Google maps for that. But what in case I don't have internet, can we deploy the server on the phone itself? Can we deploy the, the scale of the server is very big that cannot be deployed on the phone. So why not we look for alternate databases that can be deployed on over the mobile devices, such as no SQL databases? So in the, in the past, special databases are being primarily used for, if special databases are being primarily used on RDMMS, like PoZIS, that is being used on Post-Based SQL. They have great potential to store, manage queries, very large dataset queries, but special SQL databases faces scalability and agility challenges as well. And the most important thing is special applications do not have a fixed schema every time. Like in OSM data, we use XML. The schema of the data changes, the schema of a, of a geometry changes. We have a point, we have coordinates, longitudes and latitudes associated with it. But what, but the information, we, we can have more information about, about those points, like what time it opens, what time it closes, for example, if it's a hotel and everything. So we need different tables for everything. And we, if we have different tables, we need to make joints every time. Why not we have a schema list database such as no SQL databases that can include all this information within the same table so that we have less joints and less number of tables. Now Post-Based SQL is an open, open source, open object-relational database system. PoZIS is an abstraction over post, post-based SQL that adds geometry objects to it. The main functions of PoZIS can be broadly divided into five categories, management, the management of the tables, conversion from geometric data types to generic data types, information retrieval from those tables, the comparisons between the geometries and the query generation. Now special databases, no SQL, we have no SQL databases as well. No SQL databases are for non-relational data stores. They have a great potential to store and manage very large queries. They are better in case when we need to improve query time and when the data storage is getting very big. So we can deploy on many servers such as our special databases which is being updated and added every time. And special applications deal with problems like overtime evolution of schema and data size as discussed before. So we will be using, I have used MongoDB as my no SQL database system. It has already been implemented some of the no SQL, some of the special functions like line intersection and point containment. It has high performance and written friendly properties of SQL as well. It uses geogson objects to store geometries. So geogson objects, in geogson objects we can store latitudes and longitudes as well as we can store other tags as well. Data can be imported from CSV file by converting it to geogson objects. MongoDB right now do not have support for arteries but in future they will most probably be coded. So comparison between both of the databases. SQL are not designed for distributed systems. No SQL databases can be spread over many servers. SQL databases are good for structured data like data for a bank or library but unstructured data is not very suitable for but in no SQL as it is a schema less database we can have multiple geometries stored in the same column. We do not have to make column every time for new geometries. We can have lines and polygons both in the same column. So does no SQL have a promise in context of special databases and special queries? Will no SQL perform better in a way that we can use it for routing? In routing as discussed with MongoDB as well, we found out that we need very specific special functions and not all are needed. So for routing first we clip the area in our interest and then we use line intersection queries to find the relation between the lines and the other geometries. So how to compare both the databases? We can use conventional data sets and databases to compare but in our case we have used geometry databases and I have used two functions, point in a polygon function and line intersection function. Point in a polygon function returns whether a point lies within a given geometry and line intersection function as we all know tells us the point of intersection between two geometries. The dataset generated, we generated synthetic data sets for all the cases. Tests were run for worst case scenarios and best case scenarios as well. For line intersection queries we have horizontal and vertical lines from 10 to millions of lines. Then we randomly arrange those lines in the space and then we systematically arrange those lines in the space and we calculate the performance of both the databases. For point in a polygon type of a problem we used a point and a square. Firstly, 10 points within a polygon, then 10 points within 10 polygons and so on and so forth. We did it for random cases as well with millions of points and millions of boxes. All the data was processed using in-memory and no secondary memory was used. Everything was running on the RAM only. This is the performance chart for the, this is the performance chart for no SQL and this is for the SQL. As we can see, for index and non-index both, as we can see, PoZIA's performance is exponentially higher than Momba-Raby for point in a polygon type of problem. These all, these all tests were, PoZIA's performance is exponentially greater than Momba-Raby. These all tests were run without having any write operation on the screen. We didn't have any write operation and write operations for intersection and point containment was calculated. With index, we can see that the performance of indexed version is slightly better than the non-index version. But the performance difference between the SQL and no SQL is quite a bit. So, MombaDB performs better as this data size increases as we saw in our data, in our results. In line data session, we also, we got similar results with similar graphs and we found out that as the data size increases, PoZIA's, PoZIA's, depends on some data sets. The, the competition slows down and as the size increases, it sometimes fails. So, indexing increases the performance of both data sets, both data cases. PoZIA's time increases exponentially as the size of the data sets increase. But MombaDB still performs within some bounds. In discussion, the results suggest that MombaDB performs better by an average factor of 25x. The factor increases as the data size increases in both indexed and non-indexed operations. After observing the results, no SQL can be stated better for simultaneous multi-user query system including both WebGIS and mobile GIS. Conclusion, non-version databases are suited to multi-user query system. It has a potential to be implemented in service for limited computational power. Now, what we have to say is, can we deploy our no-escal databases on mobile, on mobile servers or should we move to more lighter databases such as SQL like databases which, which, which Android phones already use. So, for this, the status are required. In future, we are planning on expanding our study to other special query functions as well and, and algorithms such as routing. Any questions, please? Thank you. In the latest versions of Postgres 9.41, I think they have introduced also no-square capabilities in Postgres. Did you study those? No, I'm afraid sir, I'm not aware of those, but I'll write a point on it and I'll, I'll try to catch up with it. When you're comparing Postgres and what we're saying with large database, large datasets, what's the definition of large? Large databases refers to, we have two layers in, for both of the, for both of the case scenarios for line intersection and for point in a polygon. Last, for point in a polygon, the first layer is, is points randomly, randomly scattered on the, on the space. With large, I refer to the number of points in the number of polygons in both of the, in both of the datasets and the number of intersections and points within. In the paper, in the paper, we can, you can see the number of intersection, number of points within a polygon went to million and when the intersections and within query went to million, that was referred to as large datasets. Yeah. We're talking about points in the sections or their segments and would you define that the graphs are dense sparse for the large datasets we were managing? Yeah. Mam, it depends on the case. We took three cases, we took two cases. One was systematically scattered when the distance between all the points were increasing sequentially. Then we increased the distance between all the points exponentially and then in the third case, we did it randomly, within a bound. So they were sparse cases, they were sequential cases and they were exponential cases. The post-use library has a lot of spatial functions compared to MongoDB. Yes, yes, yes. Can you comment on this? I mean, is there any alternatives to implement other spatial functions? You just mentioned the intersection and the point containment. Is there any libraries that you can associate to perform spatial functions on Mongo? Yeah. MongoDB 4J, another new SQL database, also have some special functions and we talked to MongoDB and they, we discussed the possibility of integrating more spatial functions and adding our trees to MongoDB and we're still in a process of including more functions to MongoDB. What's the other basis of this? Neo4j. Neo4j. Neo4j. Neo4j. Thank you. Yeah. Mam. What data set practically across the main browser and other processes? Not right now, but I'll upload it as soon as I get back to my college. I'll do it for you. Yeah. Sorry. Any more questions, please? I'm going to ask you to explain the index and index also close to each other. Mam, the time is in logs. The difference between index and non-index was there, but due to logs, due to taking log base 10, the time is being collapsed to a single unit. Yeah. Yeah. This is log-arricment. Log 10 time in milliseconds. Okay. Next question. Because in the past cases, the indexing is taking more time than intersection. Yes, sir. Are you going to use the index to contain the infrastructure? Yes. Are you going to use the index to contain? Okay. Next, for line intersection and with inquiry in MongoDB. Any other questions? Which algorithms are used in non-index, the special data? Which algorithms, which special indexing techniques are used to index? I'll use the Ruby index, but there is a Ruby experiment that is used for non-index. Do you have any idea how the performance would change if you had a spatial and temporal query? Spatial. And temporal. So if you had an and statement in there? I'm... So you just basically a certain point in time and in space. So basically, not just a spatial query, but query further elements as well in your database. MongoDB, I have not tested those type of queries. I'll take a note and I'll run those cases as well. Thank you. Thank you for the feedback. Any other questions? If not, thank you very much.
 Good morning everyone. Myself, Arjun from International Institute of Information Technology,  Hyderabad, India. Thank you. Yeah. So I'll be talking about performance analysis of MongoDB  and PoZIS databases for line intersection and point containment queries. So first of  all, why do we need an internet to route from one point to another? Why don't we deploy  the server on the phone itself? Suppose I'm in Korea right now and I don't have a phone,  I don't have a Wi-Fi connection, but I want to come from my hotel, from my hotel to this  hotel. So how do I come? I need to query Google maps for that. But what in case I don't have  internet, can we deploy the server on the phone itself? Can we deploy the, the scale  of the server is very big that cannot be deployed on the phone. So why not we look for alternate  databases that can be deployed on over the mobile devices, such as no SQL databases?  So in the, in the past, special databases are being primarily used for, if special databases  are being primarily used on RDMMS, like PoZIS, that is being used on Post-Based SQL. They  have great potential to store, manage queries, very large dataset queries, but special SQL  databases faces scalability and agility challenges as well. And the most important thing is special  applications do not have a fixed schema every time. Like in OSM data, we use XML. The schema  of the data changes, the schema of a, of a geometry changes. We have a point, we have  coordinates, longitudes and latitudes associated with it. But what, but the information, we,  we can have more information about, about those points, like what time it opens, what  time it closes, for example, if it's a hotel and everything. So we need different tables  for everything. And we, if we have different tables, we need to make joints every time.  Why not we have a schema list database such as no SQL databases that can include all this  information within the same table so that we have less joints and less number of tables.  Now Post-Based SQL is an open, open source, open object-relational database system. PoZIS  is an abstraction over post, post-based SQL that adds geometry objects to it. The main  functions of PoZIS can be broadly divided into five categories, management, the management  of the tables, conversion from geometric data types to generic data types, information  retrieval from those tables, the comparisons between the geometries and the query generation.  Now special databases, no SQL, we have no SQL databases as well. No SQL databases are  for non-relational data stores. They have a great potential to store and manage very  large queries. They are better in case when we need to improve query time and when the  data storage is getting very big. So we can deploy on many servers such as our special  databases which is being updated and added every time. And special applications deal  with problems like overtime evolution of schema and data size as discussed before. So we will  be using, I have used MongoDB as my no SQL database system. It has already been implemented  some of the no SQL, some of the special functions like line intersection and point containment.  It has high performance and written friendly properties of SQL as well. It uses geogson  objects to store geometries. So geogson objects, in geogson objects we can store latitudes  and longitudes as well as we can store other tags as well. Data can be imported from CSV  file by converting it to geogson objects. MongoDB right now do not have support for  arteries but in future they will most probably be coded. So comparison between both of the  databases. SQL are not designed for distributed systems. No SQL databases can be spread over  many servers. SQL databases are good for structured data like data for a bank or library but unstructured  data is not very suitable for but in no SQL as it is a schema less database we can have  multiple geometries stored in the same column. We do not have to make column every time for  new geometries. We can have lines and polygons both in the same column. So does no SQL have  a promise in context of special databases and special queries? Will no SQL perform better  in a way that we can use it for routing? In routing as discussed with MongoDB as well,  we found out that we need very specific special functions and not all are needed. So for routing  first we clip the area in our interest and then we use line intersection queries to find  the relation between the lines and the other geometries. So how to compare both the databases?  We can use conventional data sets and databases to compare but in our case we have used geometry  databases and I have used two functions, point in a polygon function and line intersection  function. Point in a polygon function returns whether a point lies within a given geometry  and line intersection function as we all know tells us the point of intersection between  two geometries. The dataset generated, we generated synthetic  data sets for all the cases. Tests were run for worst case scenarios and best case scenarios  as well. For line intersection queries we have horizontal and vertical lines from 10  to millions of lines. Then we randomly arrange those lines in the space and then we systematically  arrange those lines in the space and we calculate the performance of both the databases. For  point in a polygon type of a problem we used a point and a square. Firstly, 10 points within  a polygon, then 10 points within 10 polygons and so on and so forth. We did it for random  cases as well with millions of points and millions of boxes. All the data was processed  using in-memory and no secondary memory was used. Everything was running on the RAM only.  This is the performance chart for the, this is the performance chart for no SQL and this  is for the SQL. As we can see, for index and non-index both, as we can see, PoZIA's performance  is exponentially higher than Momba-Raby for point in a polygon type of problem. These  all, these all tests were, PoZIA's performance is exponentially greater than Momba-Raby.  These all tests were run without having any write operation on the screen. We didn't  have any write operation and write operations for intersection and point containment was  calculated. With index, we can see that the performance of indexed version is slightly  better than the non-index version. But the performance difference between the SQL and  no SQL is quite a bit. So, MombaDB performs better as this data size increases as we saw  in our data, in our results. In line data session, we also, we got similar results with  similar graphs and we found out that as the data size increases, PoZIA's, PoZIA's, depends  on some data sets. The, the competition slows down and as the size increases, it sometimes  fails. So, indexing increases the performance of both data sets, both data cases. PoZIA's  time increases exponentially as the size of the data sets increase. But MombaDB still  performs within some bounds. In discussion, the results suggest that MombaDB performs better  by an average factor of 25x. The factor increases as the data size increases in both indexed  and non-indexed operations. After observing the results, no SQL can be stated better for  simultaneous multi-user query system including both WebGIS and mobile GIS. Conclusion, non-version  databases are suited to multi-user query system. It has a potential to be implemented in service  for limited computational power. Now, what we have to say is, can we deploy our no-escal  databases on mobile, on mobile servers or should we move to more lighter databases such as SQL  like databases which, which, which Android phones already use. So, for this, the status  are required. In future, we are planning on expanding our study to other special query  functions as well and, and algorithms such as routing. Any questions, please?  Thank you.  In the latest versions of Postgres 9.41, I think they have introduced also no-square capabilities  in Postgres. Did you study those?  No, I'm afraid sir, I'm not aware of those, but I'll write a point on it and I'll, I'll  try to catch up with it.  When you're comparing Postgres and what we're saying with large database, large datasets,  what's the definition of large?  Large databases refers to, we have two layers in, for both of the, for both of the case  scenarios for line intersection and for point in a polygon. Last, for point in a polygon,  the first layer is, is points randomly, randomly scattered on the, on the space. With large,  I refer to the number of points in the number of polygons in both of the, in both of the  datasets and the number of intersections and points within. In the paper, in the paper,  we can, you can see the number of intersection, number of points within a polygon went to  million and when the intersections and within query went to million, that was referred to  as large datasets.  Yeah.  We're talking about points in the sections or their segments and would you define that  the graphs are dense sparse for the large datasets we were managing?  Yeah. Mam, it depends on the case. We took three cases, we took two cases. One was systematically  scattered when the distance between all the points were increasing sequentially. Then  we increased the distance between all the points exponentially and then in the third  case, we did it randomly, within a bound. So they were sparse cases, they were sequential  cases and they were exponential cases.  The post-use library has a lot of spatial functions compared to MongoDB.  Yes, yes, yes.  Can you comment on this? I mean, is there any alternatives to implement other spatial  functions? You just mentioned the intersection and the point containment. Is there any libraries  that you can associate to perform spatial functions on Mongo?  Yeah. MongoDB 4J, another new SQL database, also have some special functions and we talked  to MongoDB and they, we discussed the possibility of integrating more spatial functions and  adding our trees to MongoDB and we're still in a process of including more functions to  MongoDB.  What's the other basis of this?  Neo4j.  Neo4j.  Neo4j.  Neo4j.  Thank you.  Yeah. Mam.  What data set practically across the main browser and other processes?  Not right now, but I'll upload it as soon as I get back to my college. I'll do it for  you. Yeah. Sorry. Any more questions, please?  I'm going to ask you to explain the index and index also close to each other.  Mam, the time is in logs. The difference between index and non-index was there, but due to  logs, due to taking log base 10, the time is being collapsed to a single unit. Yeah.  Yeah. This is log-arricment. Log 10 time in milliseconds.  Okay. Next question. Because in the past cases, the indexing is taking more time than intersection.  Yes, sir.  Are you going to use the index to contain the infrastructure?  Yes.  Are you going to use the index to contain?  Okay.  Next, for line intersection and with inquiry in MongoDB.  Any other questions?  Which algorithms are used in non-index, the special data? Which algorithms, which special  indexing techniques are used to index?  I'll use the Ruby index, but there is a Ruby experiment that is used for non-index.  Do you have any idea how the performance would change if you had a spatial and temporal query?  Spatial.  And temporal. So if you had an and statement in there?  I'm...  So you just basically a certain point in time and in space.  So basically, not just a spatial query, but query further elements as well in your database.  MongoDB, I have not tested those type of queries.  I'll take a note and I'll run those cases as well.  Thank you.  Thank you for the feedback.  Any other questions?  If not, thank you very much.
AT1-03_0_95.png AT1-03_96_647.png AT1-03_648_1895.png AT1-03_1896_3839.png AT1-03_3840_4643.png AT1-03_4644_5567.png AT1-03_5568_6791.png AT1-03_6792_7679.png AT1-03_7680_8651.png AT1-03_8652_9059.png AT1-03_9060_9119.png AT1-03_9120_9167.png AT1-03_9168_9323.png AT1-03_9324_10727.png AT1-03_10728_12467.png AT1-03_12468_13511.png AT1-03_13512_14171.png AT1-03_14172_15131.png AT1-03_15132_20999.png AT1-03_21000_21047.png AT1-03_21048_21095.png AT1-03_21096_24827.png AT1-03_24828_24887.png AT1-03_24888_24935.png AT1-03_24936_25027.png
Good morning everyone. Myself, Arjun from International Institute of Information Technology, Hyderabad, India. Thank you. Yeah. So I'll be talking about performance analysis of MongoDB and PoZIS databases for line intersection and point containment queries. So first of all, why do we need an internet to route from one point to another? Why don't we deploy the server on the phone itself? Suppose I'm in Korea right now and I don't have a phone, I don't have a Wi-Fi connection, but I want to come from my hotel, from my hotel to this hotel. So how do I come? I need to query Google maps for that. But what in case I don't have internet, can we deploy the server on the phone itself? Can we deploy the, the scale of the server is very big that cannot be deployed on the phone. So why not we look for alternate databases that can be deployed on over the mobile devices, such as no SQL databases? So in the, in the past, special databases are being primarily used for, if special databases are being primarily used on RDMMS, like PoZIS, that is being used on Post-Based SQL. They have great potential to store, manage queries, very large dataset queries, but special SQL databases faces scalability and agility challenges as well. And the most important thing is special applications do not have a fixed schema every time. Like in OSM data, we use XML. The schema of the data changes, the schema of a, of a geometry changes. We have a point, we have coordinates, longitudes and latitudes associated with it. But what, but the information, we, we can have more information about, about those points, like what time it opens, what time it closes, for example, if it's a hotel and everything. So we need different tables for everything. And we, if we have different tables, we need to make joints every time. Why not we have a schema list database such as no SQL databases that can include all this information within the same table so that we have less joints and less number of tables. Now Post-Based SQL is an open, open source, open object-relational database system. PoZIS is an abstraction over post, post-based SQL that adds geometry objects to it. The main functions of PoZIS can be broadly divided into five categories, management, the management of the tables, conversion from geometric data types to generic data types, information retrieval from those tables, the comparisons between the geometries and the query generation. Now special databases, no SQL, we have no SQL databases as well. No SQL databases are for non-relational data stores. They have a great potential to store and manage very large queries. They are better in case when we need to improve query time and when the data storage is getting very big. So we can deploy on many servers such as our special databases which is being updated and added every time. And special applications deal with problems like overtime evolution of schema and data size as discussed before. So we will be using, I have used MongoDB as my no SQL database system. It has already been implemented some of the no SQL, some of the special functions like line intersection and point containment. It has high performance and written friendly properties of SQL as well. It uses geogson objects to store geometries. So geogson objects, in geogson objects we can store latitudes and longitudes as well as we can store other tags as well. Data can be imported from CSV file by converting it to geogson objects. MongoDB right now do not have support for arteries but in future they will most probably be coded. So comparison between both of the databases. SQL are not designed for distributed systems. No SQL databases can be spread over many servers. SQL databases are good for structured data like data for a bank or library but unstructured data is not very suitable for but in no SQL as it is a schema less database we can have multiple geometries stored in the same column. We do not have to make column every time for new geometries. We can have lines and polygons both in the same column. So does no SQL have a promise in context of special databases and special queries? Will no SQL perform better in a way that we can use it for routing? In routing as discussed with MongoDB as well, we found out that we need very specific special functions and not all are needed. So for routing first we clip the area in our interest and then we use line intersection queries to find the relation between the lines and the other geometries. So how to compare both the databases? We can use conventional data sets and databases to compare but in our case we have used geometry databases and I have used two functions, point in a polygon function and line intersection function. Point in a polygon function returns whether a point lies within a given geometry and line intersection function as we all know tells us the point of intersection between two geometries. The dataset generated, we generated synthetic data sets for all the cases. Tests were run for worst case scenarios and best case scenarios as well. For line intersection queries we have horizontal and vertical lines from 10 to millions of lines. Then we randomly arrange those lines in the space and then we systematically arrange those lines in the space and we calculate the performance of both the databases. For point in a polygon type of a problem we used a point and a square. Firstly, 10 points within a polygon, then 10 points within 10 polygons and so on and so forth. We did it for random cases as well with millions of points and millions of boxes. All the data was processed using in-memory and no secondary memory was used. Everything was running on the RAM only. This is the performance chart for the, this is the performance chart for no SQL and this is for the SQL. As we can see, for index and non-index both, as we can see, PoZIA's performance is exponentially higher than Momba-Raby for point in a polygon type of problem. These all, these all tests were, PoZIA's performance is exponentially greater than Momba-Raby. These all tests were run without having any write operation on the screen. We didn't have any write operation and write operations for intersection and point containment was calculated. With index, we can see that the performance of indexed version is slightly better than the non-index version. But the performance difference between the SQL and no SQL is quite a bit. So, MombaDB performs better as this data size increases as we saw in our data, in our results. In line data session, we also, we got similar results with similar graphs and we found out that as the data size increases, PoZIA's, PoZIA's, depends on some data sets. The, the competition slows down and as the size increases, it sometimes fails. So, indexing increases the performance of both data sets, both data cases. PoZIA's time increases exponentially as the size of the data sets increase. But MombaDB still performs within some bounds. In discussion, the results suggest that MombaDB performs better by an average factor of 25x. The factor increases as the data size increases in both indexed and non-indexed operations. After observing the results, no SQL can be stated better for simultaneous multi-user query system including both WebGIS and mobile GIS. Conclusion, non-version databases are suited to multi-user query system. It has a potential to be implemented in service for limited computational power. Now, what we have to say is, can we deploy our no-escal databases on mobile, on mobile servers or should we move to more lighter databases such as SQL like databases which, which, which Android phones already use. So, for this, the status are required. In future, we are planning on expanding our study to other special query functions as well and, and algorithms such as routing. Any questions, please? Thank you. In the latest versions of Postgres 9.41, I think they have introduced also no-square capabilities in Postgres. Did you study those? No, I'm afraid sir, I'm not aware of those, but I'll write a point on it and I'll, I'll try to catch up with it. When you're comparing Postgres and what we're saying with large database, large datasets, what's the definition of large? Large databases refers to, we have two layers in, for both of the, for both of the case scenarios for line intersection and for point in a polygon. Last, for point in a polygon, the first layer is, is points randomly, randomly scattered on the, on the space. With large, I refer to the number of points in the number of polygons in both of the, in both of the datasets and the number of intersections and points within. In the paper, in the paper, we can, you can see the number of intersection, number of points within a polygon went to million and when the intersections and within query went to million, that was referred to as large datasets. Yeah. We're talking about points in the sections or their segments and would you define that the graphs are dense sparse for the large datasets we were managing? Yeah. Mam, it depends on the case. We took three cases, we took two cases. One was systematically scattered when the distance between all the points were increasing sequentially. Then we increased the distance between all the points exponentially and then in the third case, we did it randomly, within a bound. So they were sparse cases, they were sequential cases and they were exponential cases. The post-use library has a lot of spatial functions compared to MongoDB. Yes, yes, yes. Can you comment on this? I mean, is there any alternatives to implement other spatial functions? You just mentioned the intersection and the point containment. Is there any libraries that you can associate to perform spatial functions on Mongo? Yeah. MongoDB 4J, another new SQL database, also have some special functions and we talked to MongoDB and they, we discussed the possibility of integrating more spatial functions and adding our trees to MongoDB and we're still in a process of including more functions to MongoDB. What's the other basis of this? Neo4j. Neo4j. Neo4j. Neo4j. Thank you. Yeah. Mam. What data set practically across the main browser and other processes? Not right now, but I'll upload it as soon as I get back to my college. I'll do it for you. Yeah. Sorry. Any more questions, please? I'm going to ask you to explain the index and index also close to each other. Mam, the time is in logs. The difference between index and non-index was there, but due to logs, due to taking log base 10, the time is being collapsed to a single unit. Yeah. Yeah. This is log-arricment. Log 10 time in milliseconds. Okay. Next question. Because in the past cases, the indexing is taking more time than intersection. Yes, sir. Are you going to use the index to contain the infrastructure? Yes. Are you going to use the index to contain? Okay. Next, for line intersection and with inquiry in MongoDB. Any other questions? Which algorithms are used in non-index, the special data? Which algorithms, which special indexing techniques are used to index? I'll use the Ruby index, but there is a Ruby experiment that is used for non-index. Do you have any idea how the performance would change if you had a spatial and temporal query? Spatial. And temporal. So if you had an and statement in there? I'm... So you just basically a certain point in time and in space. So basically, not just a spatial query, but query further elements as well in your database. MongoDB, I have not tested those type of queries. I'll take a note and I'll run those cases as well. Thank you. Thank you for the feedback. Any other questions? If not, thank you very much.
databases? So in the, in the past, special special databases are being primarily used on scalability and agility challenges as well. And do not have a fixed schema every time. Like in geometries and the query generation. Now special databases, no SQL, we have no SQL databases as case when we need to improve query time and when the data storage is getting very big. So we can databases which is being updated and added every time. And special applications deal with problems databases can be spread over many servers. SQL not very suitable for but in no SQL as it is a in context of special databases and special function and line intersection function. Point in intersection between two geometries. The dataset line intersection queries we have horizontal and vertical lines from 10 to millions of lines. Then we randomly arrange those lines in the space and space and we calculate the performance of both the databases. For point in a polygon type of a random cases as well with millions of points and millions of boxes. All the data was processed using in-memory and no secondary memory was used. a polygon type of problem. These all, these all operations for intersection and point containment PoZIA's time increases exponentially as the size results suggest that MombaDB performs better by an average factor of 25x. The factor increases as the data size increases in both indexed and simultaneous multi-user query system including both WebGIS and mobile GIS. Conclusion, non-version databases are suited to multi-user query system. It has a potential to be this, the status are required. In future, we are refers to, we have two layers in, for both of the, for both of the case scenarios for line for point in a polygon, the first layer is, is points in the number of polygons in both of the, in both of the datasets and the number of increased the distance between all the points of spatial functions compared to MongoDB. Yes, SQL database, also have some special functions explain the index and index also close to each being collapsed to a single unit. Yeah. Yeah.