AI Glossary / Data engineering and architecture / Intermediate

Online complex processing

Definition

Online complex processing, or OLCP, is a historical database-workload term for demanding online operations that can combine complex queries, multi-statement transactions and mixed concurrent activity. Its meaning varies by source, so it should be interpreted through the particular workload being described.

What it means

Historical OLCP discussions contrasted complex, varied database work with simplified high-volume transaction benchmarks. The concern was that excellent performance on small repetitive transactions did not necessarily establish suitability for applications combining operational updates, analysis and longer requests.

Later vendor documentation can use the term more narrowly. Teradata, for example, associates it with tactical queries supporting operational decisions and specified response-time expectations. The label therefore does not universally mean that every query is long-running.

OLCP is not a separate database language or a standard architecture. It is also different from complex event processing, which concerns identifying patterns in streams of events. The useful question is what operations must coexist and what correctness and responsiveness they require.

How it works

A team characterizes its workload by the data accessed, work performed, transaction boundaries and concurrent users. It examines how short requests interact with heavier queries or updates, rather than relying only on an isolated transaction-per-second result.

Database mechanisms then address the concrete requirements. Query planning and indexing affect access cost. Concurrency control governs interactions between reads and writes. Resource management can prevent one class of work from consuming capacity needed by another. These mechanisms are possible responses, not features mandated by an OLCP specification.

Isolation requirements must be stated separately from speed. A multi-step decision can become invalid if relevant data changes between reading and updating. Depending on the system and transaction design, protecting correctness may involve locking, conflict detection, retries or another supported approach.

Evaluation uses representative mixes, including overlapping activity and exceptional cases. Average response time alone can hide a small set of requests that become unacceptably slow under contention. The historical label is useful only when it leads to a more precise workload description.

Three practical examples

• A production-planning application evaluates many related component requirements while staff continue updating orders and stock records.
• A service operation combines a detailed availability query with a subsequent reservation that must remain valid despite competing requests.
• A database evaluation runs routine updates alongside analytical and batch work to assess how the combined workload behaves.

Think of it this way

Think of a workshop that must handle quick repairs, long assemblies and urgent inspections using shared equipment. Testing only the number of simple repairs completed per hour would not reveal how the full mix performs.

The analogy is limited because database operations also require precise transactional correctness. Scheduling the work efficiently does not by itself ensure that concurrent decisions use compatible information.

Worked example

Seeing why an average can hide the important requests

An invented mixed-workload test completes ninety routine requests in twenty milliseconds each and ten complex requests in two seconds each. The total of the measured request durations is 90 × 20 + 10 × 2,000 = 21,800 milliseconds.

The arithmetic mean is 21,800 ÷ 100 = 218 milliseconds. That figure does not describe either class well: routine requests are much faster, while every complex request takes two seconds.

Suppose the complex requests support an interactive decision with a one-second requirement. The overall mean being below one second does not show that the requirement is met. The test should report the relevant class separately and examine how it behaves during realistic concurrent load.

The duration sum is not necessarily the test's wall-clock elapsed time because requests may overlap. These invented figures demonstrate reporting logic, not an OLCP benchmark or a universal response-time target.

Illustrative case study

A fictional equipment-rental company evaluates a database for its booking application. A simple benchmark shows fast updates to individual records. The real workflow also searches combinations of equipment, dates and locations before committing a reservation.

The team builds a test that runs those searches alongside returns, maintenance updates and competing reservations. It distinguishes read latency from the correctness of the final booking decision. A fast search result does not guarantee that the selected equipment remains available when the reservation is committed.

The evaluation report describes the operations and isolation requirements directly, with OLCP included only as historical context. The case illustrates why a named workload category should prompt careful specification rather than substitute for it.

Common misconceptions and mistakes

• OLCP has one universally fixed definition. Historical and vendor usage differs.
• Complex means every request must run for a long time. Complexity and response-time requirements are separate characteristics.
• A high simple-transaction rate proves mixed-workload suitability. Concurrent expensive operations can change behavior.
• OLCP and complex event processing are interchangeable. They describe different areas of processing.

Business use

The term can help readers interpret older database literature and recognize the limitations of narrow benchmarks. In a current project, translate it into explicit requirements that a supplier or engineering team can test.

Specify the request classes, expected volumes, transaction scope, acceptable latency distribution and required consistency. Include the interaction between analytical work and updates when those activities share resources. Record which test conditions represent normal and peak demand.

For AI-assisted operational decisions, separate retrieving a recommendation's inputs from committing the resulting action. An assistant may produce a plausible plan from data that changes before execution. The database and application must enforce the relevant conditions when the action is accepted.

People also ask

Is OLCP a replacement name for OLTP?

No. Historical discussions used it to highlight broader or more complex workloads, but the boundaries depend on the source.

Is it the same as hybrid transactional and analytical processing?

They can involve related mixed-workload concerns, but the labels have different histories and should not be assumed identical.

Does online mean a public web application?

No. In this context it concerns active or interactive processing, which can occur in private systems.

Check your understanding

A workload averages 218 milliseconds, but its decision-support requests each take two seconds. Does the average prove those requests meet a one-second requirement?

Answer: No. The relevant request class must be assessed against its own requirement. Combining it with many faster requests hides the failure.

Related terms

• OLTP
• OLAP
• Concurrency control
• mixed workload
• transaction isolation
• tactical query
• workload management
• latency distribution

Learn next

Read transaction isolation and workload management. Replace an OLCP label in a system description with a list of actual operations, their concurrency assumptions and the response-time and correctness requirements for each.

More in Data engineering and architecture

• OLAP cube - An OLAP cube is a multidimensional analytical model that organizes measures, such as sales or quantity, by dimensions such as product, location and time.
• One-to-many (data model) - A one-to-many relationship connects one instance of an entity type to potentially several instances of another, while each instance on the many side relates...
• One-to-one (data model) - A one-to-one relationship is a data-model relationship in which each instance on either side is associated with at most one instance on the other side.
• Ontology alignment - Ontology alignment identifies and represents meaningful correspondences between entities in different ontologies.
• Ontology-based data integration - Ontology-based data integration uses an ontology as an explicit model of meaning to connect information from different sources.
• Ontology merging - Ontology merging is the construction of a combined ontology from two or more source ontologies.

Sources

David McGoveran, Online Complex Processing, DBMS, October 1992: https://www.alternativetech.com/publications/OLCP%20DBMS%2010-92.pdf. Historical primary article; relevant indexed passages reviewed, direct retrieval unavailable.

Teradata, Tactical Queries Defined: https://docs.teradata.com/r/Enterprise_IntelliFlex_VMware/Database-Design/Design-Issues-for-Tactical-Queries/Tactical-Queries-Defined. Primary example of source-specific OLCP usage.

PostgreSQL, SET TRANSACTION: https://www.postgresql.org/docs/18/sql-set-transaction.html. Primary illustration of isolation requirements, not an OLCP definition. The timings and rental-company case are original.

Previous: Online algorithm Next: Online expectation maximization