Migrating From Sakila-MySQL to Couchbase, Part 5: JavaScript User-Defined Functions

With the release of 7.1, Couchbase N1QL adds support for JavaScript user-defined functions. Originally as seen in Part2: Views and UDFs and Part3: Stored Procedures, we used N1QL UDFs to map the MySQL UDFs and stored procedures. With N1QL UDFs, we can do only a single query or operation per function. This meant our translation to UDFs in Couchbase was a bit cumbersome. However, with the addition of the JS UDFs,  mapping an SQL function as is becomes much simpler. 

Now let's look at the individual functions and stored procedures and their direct mappings.

Alternate Address and Port Support for Couchbase/N1QL Clusters

External applications use this facility to communicate with the cluster, but not directly to the nodes. These settings allow internal access to a router or other networked entity that provides interfaces on the cluster’s behalf.

When setting up alternate addresses, we can also set up alternate port numbers. The best example for the alternate address setup is AWS public and private IP addresses. Each node has a Private IP and DNS but they can also assign a public IP and DNS record. Those public IPs can be either statically or dynamically assigned.

Level up your data Visualization With Charts in 7.0.2 Couchbase

If a picture is worth a thousand words, data visualization is worth a thousand data points. The 7.0.2 Couchbase Query Workbench (and the Analytics Workbench) introduces the charts tab, which allows users to create charts based on the results of the query.

A Closer Look at Charts

Internally we use D3 to render the charts themselves. Each individual value can be seen using the hover tooltip, and the legend (colors and what they represent) for the multicolored charts are seen in the right-hand corner of the canvas. The charts can also be downloaded as an SVG using the button on the right-hand side of the canvas. Sizing the canvas or the screen itself auto-adjusts the charts to fit. 

Couchbase Support for Node-to-node Encryption

When customers using Couchbase require us to comply with privacy regulations such as HIPAA (financial or healthcare customers as an example), then we typically need to allow for Authentication(LDAP), Authorization (RBAC-role based access control), and Encryption. It is also important to support auditing and redaction of important information, especially in logs (Couchbase has support for log redaction using specific tags), all of which Couchbase supports. When it comes to encryption, Couchbase supports node to node encryption at multiple levels using the cluster configuration level setting. This is controlled by the user and can take 3 values:

  1. Control: At this level, only the cluster and server connections to internal services are encrypted. This basically includes the cluster management information and the related internal processes. However, data across nodes in the cluster is not. So, for example, a server to query service connection is encrypted. This is the default behaviour. 

Authentication Using Server Side X.509 Certificates With N1QL

Authentication and authorization to the query service in Couchbase works in multiple ways - 

  1. Passing credentials through a rest request - curl http://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces" -u Admin:pwd
  2. Passing credentials using the creds named parameter and/or query parameter - curl http://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces&creds=[{user:“Administrator”,”password”:”pass”}]"
  3. Using basic auth in the request 
  4. Request from cbq (similar to 1,2) using the -u -p -creds options and \SET command. 
  5. X.509 Certificates for TLS
  6. Node to Node encryption

With the addition of RBAC, the creds query parameter was made redundant but is still supported for backward compatibility.