Introduction to Couchbase for Oracle Developers and Experts: Part 1- Architecture
In this article, we'll compare and contrast Oracle with Couchbase from a SQL point of view. You'll get a good feel for the architecture and capabilities of Couchbase.
Join the DZone community and get the full member experience.
Join For FreeIntroduction
You know Oracle, but need a good overview of Couchbase, a modern NoSQL database? You're in the right place. This will speed up your understanding of Couchbase. It’s not intended to evaluate all the features or performance. Since Oracle is a relational database with SQL as the main query language, it's normal for developers to view other databases from SQL's point of view.
In this article, we'll compare and contrast Oracle with Couchbase from a SQL point of view. You'll get a good feel for the architecture and capabilities of Couchbase. We won't do a deep dive into high-availability, scale-out, and sizing the databases in this series.
This blog series will cover the following topics, comparing Oracle and Couchbase from a developer perspective.
[Series is now complete. Follow the links to read each article]
- Architecture
- Database Objects
- Data types
- Data Modeling
- Statements and Features
- Indexes
- Optimizer
- Transaction
Here’s the overview comparison from logic to language, transactions to tooling. In the rest of the blogs in the series, we’ll cover each of the topics.
Both Oracle and Couchbase were developed to handle enterprise transactional and analytical workloads. They coexist in enterprises. It’s with this sensibility, we’re providing a comparison of these products to help Oracle developers to understand what’s Couchbase.
Architecture
Single Node Deployment
Cluster Deployment Oracle RAC (Cluster) Deployment (Shared Disk)Couchbase Cluster Deployment (Shared Nothing)Couchbase Multi-Dimensional Deployment (Shared Nothing)
Topic | Oracle | Couchbase |
Single Node Deployment | Oracle was built and optimized for deploying in a single node database (in the deployment shown in 2). It was then enhanced to run on SMP (symmetric multi-socket/core processing) machines. All the layers of a database (logical, physical space management, locking, logging, are all managed for a single machine). The code executes in a single thread (or cooperating threads) with resources like locking designed for a single machine. This configuration is the majority of the development and production deployment. When you run out of disk capacity, you add capacity. When you run out of CPU capacity, you migrate the workload to a larger machine with more sockets, more cores. Or these days, bigger VMs or containers. The APP for server communication uses proprietary oracle protocol. Higher-level SDKs work on top of this. |
Couchbase Server can be installed on a single server or a single node or a VM/container for development: for example MacOS, Linux, or Windows. All of the database functions are abstracted into services (data, index, query, search, analytics) which work in concert to provide the database functionality. These services coordinate to expose the services via REST API. The applications use Couchbase SDKs or tools to create indexes, run N1QL queries, get results and visualize data. This configuration is used mainly for development on your laptop, cloud, VM, or container. Single node deployment is rarely for production. In fact, Couchbase gives you a warning when you’ve deployed on a single node there’s only one copy of your data! High availability is built into the core. The API for server communication is via REST API and Memcached binary protocol. All SDKs use REST or Memcached protocols underneath. |
Languages | SQL, PL/SQL, XQuery, SES (Secure Enterprise Search) | N1QL (SQL for JSON), Javascript, Python functions (with N1QL), Direct data access API, FTS (full-text search). |
Connections | A persistent connection between the user process and database process/thread running on behalf of the client application. | HTTP over TCP/IP connection. Connection for Memcached. For each request for data fetch, and modification, the query is a REST call. |
Session | A session starts from CONNECT to QUIT. Each application “session” has a corresponding session on the Oracle server. Within a session, you can execute 1 query or one million queries spanning multiple transactions. | Just like connection, in Couchbase, each request is a distinct request. Each request has to carry both bind parameters and any context parameters (e.g. timeout). All the N1QL statements for a single transaction execute on the same query node; concurrent transactions can execute on any number of nodes. |
User, authentication | Supports OS user, a database user. Authentication can be done by OS, database, third party like LDAP, Kerberos. | Supports OS user, a database user. Authentication can be done by OS, database, third party like LDAP, Kerberos. |
Database | Oracle instance ->Databases ->Schema -> Tables -> Rows -> Columns One Oracle instance can have multiple databases. |
Cluster -> Buckets -> Scopes -> Collections -> JSON documents -> Fields One Couchbase instance can have up to 30 BUCKETS. Each bucket can have many scopes, each scope many collections. Within each scope, you can also create functions (in SQL, Javascript, Python). Each JSON document will have a user-provided unique document key. E.g: “cust.x817.022.4u2” |
Table | Table | Collection |
Column | Column | Field All the documents in Couchbase have to be JSON documents conforming to http://json.org/ Consider a simple 1-level JSON document. Document Key: “cust:2984” Doc: {“a”:1, “b”: True, “c”: “Hello”} In your mind map, you can think of this document as a row, individual attributes, “a”, “b”, “c” as columns, the document key as a primary key. This document contains simple scalar values.JSON can contain arrays and objects, arrays of objects, objects containing arrays. Attribute names are referenced from top-down (think of objects in Oracle. This will be discussed in detail in the “Database Types” section. |
JSON support | JSON is a type for a column | JSON is the model for the whole document |
SDKs | http://bit.ly/20TCGn0 |
https://www.couchbase.com/downloads (scroll down to SDKs) |
Multi-node architecture (Homogeneous deployment). |
||
Multi-Dimensional Deployment | Not Available. Each node in Oracle RAC (Real Application Cluster) has full Oracle SQL capability including transactional and administrative capability. | Each node in the cluster can have one or more combinations of the services: Data, Query, Index, Search, Analytics, and eventing. The cluster manager (co-ordinator) is aware of the distribution and availability of the services and will inform the services about each other. The SDK is also aware of the data distribution, query, and FTS nodes. SDK tries to balance the workload among different query nodes for query workload, data nodes for data/KV workload, FTS nodes for search workload. |
System Architecture | Single node deployment is suited for SMP. Multi-node deployment shares the same disk/storage. Hence, Shared Disk System. You can scale up to a point by adding more compute and sharing the same disk. Eventually, shared disk and IO throughput become the bottleneck. Transactions are supported by distributed lock manager which reaches a threshold with a small number of nodes. The developer is oblivious (for the most part) to the instances: single node or multi-node RAC. The SQL supported are the same and transactions work seamlessly in a multi-node environment. Oracle has developed a sophisticated distributed lock manager, buffer pool synchronization, etc to achieve this. It does require an expensive Infinibandto maintain speed and performance. Despite this, it’s not uncommon to partition the workload between multiple RAC nodes to minimize the conflicts in locking, etc. |
Uses shared-nothing architecture from the ground up enabling Couchbase to scale out. Each node can scale up to use the resources in each node; database functionality is implemented as co-operating multiple services running on a single system. Coordination is done via message passing, even on a single system. These services (data, index, query, search, analytics, and eventing) lend themselves to scale out seamlessly. You can have all of the services in each node and simply add new nodes with the same services. All the services will understand the multi-node topology. This makes Couchbase elastic. Applications don’t use all of the services uniformly. The bottlenecks could be on data, indexer of the query. So, in Couchbase, your size and add new nodes simply to run the bottlenecked services. This will provide optimal resource utilization and better performance compared to a homogeneous deployment. It’ll give you flexibility and reduce your cost. The multi-dimensional scaling is as easy to deploy as any other configuration and manageability remain the same. |
Query | Oracle has Full-fledged SQL support. The SQL extensions include support for JSON and text search. Oracle also has XML DB, supporting XML, XQuery, SQL/XML, etc. |
N1QL (SQL for JSON) provides a declarative language that's an enhanced version of SQL for JSON. It comes with indexes and a full-fledged query engine, patented cost-based optimizer, transaction support, UDF (user-defined functions - aka stored procedures) to execute queries efficiently. Details at: https://query.couchbase.com The same language is supported for the operational workload (OLTP) and analytical workload (OLAP), just like RDBMS. Developers also get a simple GET and SET API for each document in a collection. Couchbase also supports built-in SQL and JavaScript functions in the query service to support the equivalent of PL/SQL functionality. Couchbase FTS (Full-Text Search) helps you create text index and search. This is fully integrated with N1QL http://bit.ly/2vbcbOF |
High Availability | Oracle’s MAA (Maximum Availability Architecture) recommends: “On the Cluster configuration screen, in the Disk Group Details section, MAA recommends choosing Oracle Automatic Storage Management (ASM) HIGH redundancy for ALL (DATA and RECO) disk groups for best protection and highest operational simplicity” Oracle has a facility to create hot standby servers, schema-based replication, change capture, and probably more. |
Within a single cluster, you can have multiple copies of data and index just by specifying the number of copies you’d like to have. You can have up to 3 copies of the data and any number of index copies. No additional setup is required. Across-multiple clusters, you can replicate the data with built-in XDCR (cross-data center replication). |
Transactions | Multi-statement, ACID with multiple isolation levels | Supports multi-statement ACID transactions with READ-COMMITTED isolation level. Since these are distributed transactions, it comes with configurable durability as well. Oracle uses pessimistic locking; Couchbase uses optimistic locking (using CAS) for its simple updates as well as multi-statement transactions. |
Drivers | JDBC, ODBC, .NET, LINQ and more | Couchbase SDK (Java, .NET, LINQ, PHP, Python, Go), Simba JDBC/ODBC, JDBC driver for tableau |
Data Model | Supports both normalized and denormalized data models. | Denormalized (aggregated) JSON model. Relationships between multiple types of documents (e.g. Orders to Customers) can be represented and processed. Either the child (orders) or the parent (customer) can store the primary key of the related documents and then JOIN them. This relationship is implied, not enforced by a constraint (e.g. Foreign Key Constraint) in Couchbase. |
High-Level SQL-N1QL Comparison
Here's a sneak peek of the comparison between Oracle's SQL model versus Couchbase's NoSQL(JSON) model for objects, language, and query processing. We'll discuss these in detail in the rest of this blog series.
(Click on the image to view PDF)
That's all for today! Stay tuned for the upcoming parts of this series.
Published at DZone with permission of Keshav Murthy, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments