Denodo Platform Architecture, Installation, and Administration
What this domain tests
Architecture questions identify the components, their ports and metadata stores, and how a production topology differs from a single-server evaluation install. Administration covers configuration, startup, logging and backups.
Components
Virtual DataPort is the query engine and the only component clients query over JDBC/ODBC on port 9999; its web container hosts the web tools. Scheduler runs jobs. Solution Manager manages revisions and deployments. Data Catalog serves governed metadata to consumers. The embedded MPP accelerates eligible aggregation workloads. Each server can run on its own host, and a production topology typically separates them.
Metadata and clustering
Evaluation installs default to an embedded Derby metadata database. Production uses an external RDBMS so multiple VDP nodes can share catalog metadata behind a load balancer. Caches are node-local, which matters when sessions are balanced across nodes: a cache populated on one node is not automatically warm on another.
Installation and administration
Installation uses the platform installer, a license file and DENODO_HOME. JVM heap is set in the environment scripts, not in the installer. VDPConfig changes ports, SSL, external metadata and other server settings, and start/stop scripts manage each server. Logs live under DENODO_HOME/logs and are the first diagnostic tool; configuration exports supply backups.
Worked example
Two VDP nodes behind a load balancer must serve a cache-heavy workload. Reasoning: point both nodes at the same external metadata database so the catalog is consistent, keep the embedded Derby out of production, size heap against the cache footprint, and account for cache being per node - either accept cold-cache misses on the second node or preload both. Verify by querying each node directly, bypassing the balancer.
Traps that cost marks
- Running Derby as the production metadata store and then wondering why a second node sees different views.
- Assuming caches are shared across a cluster.
- Changing heap in the wrong file or forgetting a restart.
- Diagnosing performance failures from the client when the server log states the cause.