Couchbase

Couchbase Server is a NoSQL database, designed with a distributed architecture for performance, scalability, and availability. Couchbase enables developers to build applications easier and faster by leveraging the power of SQL with the flexibility of JSON. Deploy Couchbase Server as a Document database to access, index, and query documents while taking advantage of integrated caching for high-performance data access. Couchbase can also be deployed as a key-value store to meet high-performance requirements for read and write data access while maintaining durability and availability. Couchbase can also be deployed as a distributed cache to provide scalable, low-latency access to large in-memory data sets, optionally via the memcache API and clients.

Configuration

port: 8091 (used for the web console REST API)

port: 8093 (used for the query service REST API)

Limitations on Number of Couchbase Buckets

Based on some experiments others have run, we learned that if you want more than 10 Buckets (or change the value), you will need to do this before building a cluster. If not, you will end up with out-of-range errors. Since we have already built our clusters we would need to rebuild our existing cluster/vbuckets.

From what I read, increasing the number of vBuckets is NOT a supported scenario from Couchbase (even though you can). If we increase the number and have issues, we will be on our own…they will not support us. Increasing the max vBuckets has a significant impact on overall performance, I/O and memory usage. Each vBucket is split into 1024 partitions between our 3 nodes (342 buckets per machine X # of vBuckets). This means that with a 10 max vBucket default setting, we will have 3420 partitions per machine at are all asynchronously threaded and managed. Since the load on the systems will increase, we would have to manage/configure each vBucket (data/index/query) to be on separate physical storage (if we want to do something to improve the impact on performance).

I do not recommend that we go down this path (if we can avoid it). It may be a significant cost to OTE to initially reconfigure all Couchbase cluster and ensure/manage performance. It also means that the 3 host machines will need to be fully (or near fully) dedicated to Couchbase. This means that we will have to rebalance all the VMs and take the 3 hosts out of the Windows cluster, so that there is no failover possible for the Couchbase VMs.

Cloudera Navigator Key Trustee Server

https://www.cloudera.com/documentation/enterprise/5-5-x/topics/sg_hdfs_encryption_wizard.html#concept_ucw_lfr_wt

Administration

Create Primary Index

CREATE PRIMARY INDEX index_name On BucketName  USING VIEW

 

Query Couchbase using Query Explorer

  • Copy the Couchbase workbench to local drive: couchbase-query-workbench_dp3-windows_amd64
  • Update the production couchbase uri  in launch-cbq-gui.bat file
    For example set COUCHBASE_URL=http://couchbase.servername01:8091
  • Save the batch file.
  • Run the batch file from command line which will provide the local url to access.
  • Copy the url and paste in browser.

Support Options

Couchbase CE is free, for EE three levels of support are available:

  • Platinum: 24×7 Support with 30min SLA, $15,500/node/year
  • Gold: 24×7 Support with 2hrs SLA, $9,900/node/year
  • Silver: Business-day only Support (7am-5pm business hrs) with 5-10hrs SLA, $5,600/node/year

Couchbase only recommends Gold and Platinum for production. Silver is only recommended for non-prod environments or non-mission critical apps, it does not include support at night or on weekends and it’s capped at 5nodes/cluster.