Octo SQL for Analytics
Get More Value from Your Data in YottaDB
Octo delivers SQL connectivity for reporting, visualization, and analysis so those powering mission-critical apps on YottaDB can gain more insight
What Is Octo?
Octo is a SQL database whose tables are in a YottaDB database. There is a vast ecosystem of tools using SQL/JDBC for reporting, visualization, analysis, and more. Octo 1.0 makes databases of transactional applications that use YottaDB accessible to those tools.
Octo Enables Near-Real-Time Reporting with Zero Disruption
Octo can run alongside any database, from YottaDB and GT.M to IRIS/Caché and MongoDB. By isolating reporting resources from production systems, Octo can deliver valuable insights in a clean environment without causing bottlenecks that impact users.
Other Octo Use Cases
The most common use case for Octo is real-time reporting and analytics of applications running on YottaDB or other key-value databases from which application updates can be replicated to YottaDB.
Octo can also provide value when organizations need to perform data forensics, create multiple reporting instances, simplify deployment or archive an application.
Deploying Octo
Reporting and analytics should not be run on a production system. This is because a real-time production system has response time service levels it must maintain. An analytics or reporting query can, depending on the query, “churn” the production database, impacting real-time response times. So, analytics and reporting should be run on a copy of the real-time production system.
The production system can run any database. We of course think that the best database to use is YottaDB, but for an application like VistA, it can be GT.M from which there is real-time replication to YottaDB, or Caché/IRIS from which replication can be established using journal file extracts so that replicated data is near real-time (i.e., minutes). Near real-time extracts from journal files is also the replication technique for applications using a database like MongoDB.
For SQL access, Octo requires the application data, but does not require the application code, except for functions needed to convert data in application specific formats to formats that are meaningful to SQL queries. For example VistA uses a special timestamp called a “Fileman date” and Octo would require that code, or functionally equivalent code, to make a column of Fileman dates accessible to SQL as ordinary dates.
Apart from application data, the other key information that Octo requires is the schema, in Octo’s Data Definition Language (DDL), which is ordinary SQL-92 DDL enhanced with functionality to map tables to global variables. The mapping capability is very flexible: for example, different parts of a global variable sub-tree can be mapped to columns of single table, and conversely, a table can contain columns from different global variables. A column other than a key column can also be a function that returns a value.