{"id":15117,"date":"2023-11-29T21:38:32","date_gmt":"2023-11-30T05:38:32","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=15117"},"modified":"2025-09-16T00:09:56","modified_gmt":"2025-09-16T07:09:56","slug":"navigating-analytics-in-the-nosql-era","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/ko\/navigating-analytics-in-the-nosql-era\/","title":{"rendered":"NoSQL \uc2dc\ub300\uc758 \ubd84\uc11d \ud0d0\uc0c9"},"content":{"rendered":"

\"\"<\/a>NoSQL database systems have firmly established their presence for more than a decade, garnering substantial market share in the OLTP database domain. The rapid adoption of NoSQL databases for OLTP use cases can be attributed to key factors such as scalability and availability, along with robust support for agile development through flexible schema design and enhanced performance. <\/span><\/p>\n

The cornerstone of agile development practices for modern application developers lies in the flexibility offered by a document model, enabling swift adaptation to evolving business requirements. This has effectively liberated developers from dependency on database administrators, eliminating bottlenecks and the need to adhere to enterprise database change windows.<\/span><\/p>\n

Let us consider a sample library application having a JSON Schema<\/span><\/p>\n

{\r\n\u00a0\u00a0\"book_id\": 1,\r\n\u00a0\u00a0\"title\": \"The Great Gatsby\",\r\n\u00a0\u00a0\"author\": \"F. Scott Fitzgerald\",\r\n\u00a0\u00a0\"publishers\": [\r\n\u00a0\u00a0\u00a0\u00a0{\"name\": \"Scribner\", \"year\": 1925},\r\n\u00a0\u00a0\u00a0\u00a0{\"name\": \"Vintage Books\", \"year\": 1995}\r\n\u00a0\u00a0]\r\n}<\/pre>\n
Introducing the genre of a book into our library application is a straightforward task for the application developer. This entails a simple adjustment\u2014adding a new array field called genre<\/em>\u00a0to the document. Given that a book can belong to multiple genres, this flexible approach accommodates the dynamic nature of book categorization effortlessly.<\/span><\/p>\n
{\r\n\u00a0\u00a0\"book_id\": 1,\r\n\u00a0\u00a0\"title\": \"The Great Gatsby\",\r\n\u00a0\u00a0\"author\": \"F. Scott Fitzgerald\",\r\n\u00a0\u00a0\"genres\": [\"Fiction\", \"Classic\"],\r\n\u00a0\u00a0\"publishers\": [\r\n\u00a0\u00a0\u00a0\u00a0{\"name\": \"Scribner\", \"year\": 1925},\r\n\u00a0\u00a0\u00a0\u00a0{\"name\": \"Vintage Books\", \"year\": 1995}\r\n\u00a0\u00a0]\r\n}<\/pre>\n
Does the data lifecycle culminate with an OLTP application? The unequivocal answer is no. <\/span><\/p>\n
Many OLTP applications seamlessly flow into downstream analytical systems, such as real-time analytics, data marts, data warehouses, or data lakes. However, a significant challenge arises because the majority of analytics database systems worldwide are built on relational database models, expecting a fixed, tabular, relational format for stored data.\u00a0 <\/span><\/p>\n
Herein lies a noteworthy predicament: while upstream OLTP NoSQL database systems boast a flexible schema with a document model\u2014where each document may possess a distinct schema, and documents can encapsulate nested documents or arrays\u2014converting this diverse data back into the relational world induces considerable ETL (Extract, Transform, Load) challenges. However, the issue extends beyond ETL challenges alone.\u00a0 <\/span><\/p>\n
The flexibility of schema and document model support in OLTP applications means that developers are no longer bound to coordinate database changes with a Database Administrator (DBA), leading to rapid and dynamic evolution of the application schema. In contrast, downstream systems, inherently relational in nature, struggle to keep pace with the constant evolution of the schema. To illustrate this issue, let’s revisit our example of the library application.<\/span><\/p>\n
Assuming this library application has a underlying relational analytical database, the schema would look something like the following.<\/span><\/p>\n
Book Table<\/strong><\/p>\n\n\n\n\n
book_id<\/b><\/th>\ntitle<\/b><\/th>\nauthor<\/b><\/th>\n<\/tr>\n
1<\/span><\/td>\nThe Great Gatsby<\/span><\/td>\nF. Scott Fitzgerald<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Publisher Table<\/b><\/p>\n\n\n\n\n\n
publisher_id<\/b><\/th>\nname<\/b><\/th>\nyear<\/b><\/th>\n<\/tr>\n
1<\/span><\/td>\nScribner<\/span><\/td>\n1925<\/span><\/td>\n<\/tr>\n
2<\/span><\/td>\nVintage Books<\/span><\/td>\n1995<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Book_Publisher Table<\/b><\/p>\n\n\n\n\n\n
book_id<\/b><\/th>\npublisher_id<\/b><\/th>\n<\/tr>\n
1<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
1<\/span><\/td>\n2<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If we need to convey the straightforward addition of the genre <\/em>field in the NoSQL OLTP database documents to the downstream analytics system, the process involves the following.<\/span><\/p>\n
We would introduce 2 new tables: Genre<\/em> and Book_Genre<\/em>.<\/span><\/p>\n
Genre Table<\/b><\/p>\n\n\n\n\n\n
genre_id<\/b><\/th>\nname<\/b><\/th>\n<\/tr>\n
1<\/span><\/td>\nFiction<\/span><\/td>\n<\/tr>\n
2<\/span><\/td>\nClassic<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Book_Genre Table<\/b><\/p>\n\n\n\n\n\n
book_id<\/b><\/th>\ngenre_id<\/b><\/th>\n<\/tr>\n
1<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
1<\/span><\/td>\n2<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Furthermore, the ETL application responsible for supplying data to the relational analytical system must undertake the task of decomposing the genre<\/em> array within each document and populating the resulting information into the corresponding tables for every document.<\/span><\/p>\n
From the examples provided above, it’s evident that constructing real-time analytical applications and synchronizing with the dynamic changes in upstream OLTP NoSQL databases pose challenges for Relational Analytical systems. Despite these challenges, why do enterprises persist in building relational analytical systems, especially when the upstream OLTP systems lean towards a NoSQL document-oriented nature? To delve deeper into this, let’s explore the fundamental principles that underpin database systems designed for analytics.<\/span><\/p>\n
Analytical queries often involve handling extensive datasets with intricate joins, aggregations, and multiple layers of filtering. Many of these operations can be significantly expedited by executing them in parallel across a network of servers. This necessitates that database systems designed for analytics possess robust <\/span>Massive Parallel Processing<\/b> capabilities, enabling the distribution of a query plan across multiple physical servers to enhance the speed of query execution.<\/span><\/p>\n
Analytical queries commonly focus on retrieving a specific subset of columns from the entire dataset. Therefore, <\/span>Column-oriented databases<\/b> are favored in analytical use cases because they optimize I\/O operations. By selectively fetching only the columns relevant to a query, these databases minimize the need to retrieve all column information from the disk, resulting in more efficient query performance.<\/span><\/p>\n
Analytical queries are inherently intricate and can yield multiple potential execution plans. In the realm of database systems for analytics, it is paramount for these systems to go beyond rule-based planning and employ a <\/span>Cost-Based Query Optimizer<\/b>. This optimizer plays a crucial role in identifying the most efficient query plan by considering a range of cost factors, ensuring optimal execution of complex analytical queries.<\/span><\/p>\n
Analytical databases are designed for horizontal scalability, enabling the seamless addition of compute resources to an existing database cluster. This scalability serves to reduce query runtimes and accommodate additional queries. Particularly in cloud environments, where the swift addition and removal of compute resources is feasible, it becomes imperative to adopt an analytics database architecture that emphasizes <\/span>Storage-Compute Separation<\/b>. This design facilitates the swift scaling or contraction of the database cluster, ensuring adaptability to varying workloads.<\/span><\/p>\n
Historically, NoSQL document-oriented databases did not meet the above four essential principles required by analytical database systems. Consequently, enterprises persisted in utilizing relational databases for analytical systems, even when the upstream OLTP database adopted a NoSQL approach. This decision was driven by the limitations outlined earlier.<\/span><\/p>\n
Couchbase Analytics to the rescue!<\/b><\/p>\n
Couchbase Analytics stands as a NoSQL Document-oriented, Storage-Compute Separated, Massively Parallel Columnar Database Cloud Service equipped with an integrated Cost-Based Optimizer. Addressing all the crucial principles of a high-performance analytical database, Couchbase Analytics preserves the beloved Flexible Document-Oriented data model. Empowering enterprises to construct real-time analytical systems, it significantly reduces the ETL effort and time required for ingesting data from upstream NoSQL OLTP databases. Moreover, it ensures that analytical applications stay synchronized with the most recent business data arriving from upstream transactional systems.<\/span><\/p>\n
Learn more about how Couchbase Analytics addresses your needs:<\/p>\n