What is the type of NoSQL (big data) database that houses a spatiotemporal database in a data store?
The spatiotemporal data store uses ElasticSearch.
Cannot answer your question as I don't have such a setup, but I do know that the distinction between traditional RDBMS and NoSQL databases is blurry these days...
E.g. PostgreSQL can store and access unstructured data as well, either being key/value data stored in something like an "hstore" or "jsonb" column, or non-traditional table / unstructured data accessed through Foreign Data Wrappers (FDW). In addition, there are variants of PostgreSQL that run over multiple computation nodes / servers, and PostgreSQL itself is quite capable of using multiple cores and large datasets (I currently have the whole of OpenStreetMap's Europe data in a single PostgreSQL database, with one of the spatial tables having > 218M records).
So, I wouldn't be surprised if the spatialtemporal database is just a PostgreSQL database at its core.
Is ElasticSearch considered a a graph type NoSQL? Thanks.
Not too versed in database nomenclature, but I'd say, no, ES is a document database, not a graph database. Both fall into the category of NoSQL though.
Same as you I'm just starting to learn about this technology. So the data is stored as JSON objects?
I think the graph database employs a concept of nodes and edges, meaningless to me right now, and I see in the 'elasticsearch' sub-folder of the Data Store server configuration folder there are sub folders named 'node', so maybe a term commonly used in NoSQL deployments.
I created a spatiotemporal data store recently and there is now a Windows service named 'java' that is consuming nearly 8GB of RAM. Is the strategy to keep the entire spatiotemporal DB in RAM with a backup to disk?
I believe a graph database is able to store relationships/hierarchy between data elements, which is what "nodes" and "edges" refers to. I don't think that the Data Stores "node" reference is equivalent of a "node" in a graph database.
But take all that with a grain of salt, , just speculation on my end.
No, that's definitely not the strategy. The spatiotemporal data store can support terabytes upon terabytes of data; that's of course not going to memory. Due to the immense amount of data the spatiotemporal data store can store, which would also involve indexing and other operations, the memory requirements of the spatiotemporal Data Store are significant.
Retrieving data ...