The Database Landscape
Databases can be confusing. While “relational” seems to be the type most commonly referred to when talking about databases, there are actually many other kinds of databases. In fact, there are hundreds of them available in the marketplace–not just relational–designed to handle different data types and manage a variety of workloads or use cases.
While there can be many subcategories of databases, most can be classified under two categories: transactional (or On-Line Transactional Processing) or analytical (On-Line Analytical Processing) databases. OLTP databases are usually relational databases, and OLAP databases can be further subdivided into whether they are real-time analytics or data warehousing databases.
OLTP is characterized by a large number of short on-line transactions (INSERT, UPDATE, DELETE). The main emphasis for OLTP systems is put on very fast query processing while maintaining data integrity in multi-access environments; and effectiveness is measured by number of transactions per second at low latency and ability to handle high concurrency. There is detailed and current data in an OLTP database.
OLAP is characterized by relatively low volume of transactions. Queries are often very complex and involve aggregations. For OLAP systems, response time is an effectiveness measure. There is usually aggregated, historical data in OLAP databases. Data warehousing usually looks at long historical data to find patterns and draw conclusions or recommendations about the present or future, while real-time analytics looks at transactions and/or data as they are happening in the moment– to draw similar conclusions or recommendations.
Built for OLTP–Not Your Average General-Purpose Database
ClustrixDB is not an OLAP database. ClustrixDB is a distributed (multi-node), relational scale-out database designed for OLTP with high-value, high-transaction workloads deployed on-premises or in the cloud. ClustrixDB is a perfect fit when you’ve outgrown your single-node OLTP database like MySQL, and need to scale beyond its limitations to handle higher transaction volumes and a massive number of concurrent users–without losing performance or ACID compliance.