My understanding of Polypheny-DB

[Heachy]

The following is my understanding of Polypheny-DB, and I hope to receive guidance and corrections.

In my opinion, Polypheny-DB belongs to middleware. Store the connection information of the database table in the local DB, and perform corresponding queries when querying the table. If you query a CSV or Excel file, the corresponding file will be copied to the data file directory.

When the project starts, the directory structure information will be read from mapDB and cached in the corresponding variables to facilitate querying. Polypheny-DB also provides some interfaces to provide corresponding services for use by other applications, such as Polypheny-UI, etc.

Many adapters are provided to facilitate interaction with corresponding data files. It also provides some monitoring functions to better collect the required data information and respond to the data.

Use sql to query the corresponding table data information. But I want to know why we need to use websocket links to query data. There is nothing special about the information sent to the websocket when querying data. So what is the difference between doing this and providing an interface?

The above should be what I learned by using Polypheny-DB and reading its source code. I don’t know if there is a detailed document or a better place to suggest me to study it. I hope I can gain something from it. Please correct me if anything is wrong.

[hennlo]

Hi @Heachy
Polypheny is very versatile and has many different use cases and therefore approaches how to utilize it.
Hence, I will try to answer as close to your question as possible.

So first of all Polypheny is a full-fledged DBMS like any other DBMS available. This means that you can connect any application and utilize Polypheny as a DB using the provided interfaces. So no mere middleware at all.

Polypheny however allows to further attach existing data stores to it, expanding its capabilities even further.
E.g. You can add several MongoDB, PostgreSQL or Neo4J systems as you desire. This enables Polypheny to offload data to these attached stores and utilize the power and uniqueness of those engines.
Internal entities like tables can then be configured that its data resides on one or more of these so called data stores.
This means that data could be replicated to all available stores or only some of them. Furthermore you can choose to distribute the data only partially to some stores and the rest of the data to other stores to achieve i.e. natural load balancing.
New incoming data for that configured entity/table will then be placed on a store depending to its configuration.

Since Polypheny keeps track on which stores data is located, querying such an entity enables Polypheny to identify the best possible route for the query to retrieve the desired data with the most optimal estimated response time.

This brings me to a core functionality of the system.
It was inherently built as a Multi-Model DBMS so users are not limited to the sole data-model a DB provides and requires.
Since every model has its on use cases when its useful some applications might need several models in combination.
Simply transforming them from one model to another might cause loss ins details when converting it into another model that is not supported by a system.
So when users put data into the system they can also insert document-JSON, graphs and relational information.
And retrieving the data in a model he wishes to use.
That is also why we introduced the matching query languages that best go with those models. E.g. SQL for relational, MQL for document-based-JSON, openCypher for Graph Engines, etc.

Finally Polypheny can attach multiple external sources into the system that can be then queried by users as well and combine it with other sources or even with internally stored data on the provided stores.
So to say it acts as a Higher-Order DBMS that abstracts several underlying data storage engines to the outside via one Single point of entry to your entire data landscape that can be queried and combined on a single platform. Making it agnostic to the outside.

Regarding the Repos:
Polypheny ships with an integrated UI with is developed in a separate repository, namely Polypheny-UI. The core and backend of the DBMS itself is located in the Polypheny-DB repository.

The Web Socket you described is simply the capability of the UI to interact with the DB itself. The main interaction with the DB is always via the provided interfaces.

Regarding additional reads you can consult our official docs page and read through the Getting Started and Concepts sections.

Hope that helped to get a better understanding about Polypheny.

[Heachy]

Thank you for your patient answer!

Sorry for using middleware to describe polypheny.Because I think polypheny is a bridge between data and users, and between different data sources.

Regarding your description, can I understand that polypheny can manage a variety of data and also integrate other data sources, such as mongodb, PostgreSQL, etc. Polypheny can enable data from different data sources to communicate with each other. On the one hand, it allows it to better manage a variety of data, and on the other hand, it also allows it to connect with popular databases. Make better use of the advantages of different data models.

I will continue to learn polypheny, thank you again for your answer!