Performance & scalability of Couchbase Server – Couchbase Connect 2016

©2016 Couchbase Inc. 1

The Couchbase Connect16 mobile appTake our in-app survey!


Performance & Scalability of Couchbase Server


Raju SuravarjjalaSenior Director, QE & [email protected]

IMAGE GOES HERE

mailto:[email protected]

©2016 Couchbase Inc.©2016 Couchbase Inc.

Agenda

• What is Couchbase?• Why you will choose Couchbase?• Accessing Data from Couchbase• Performance within the Database & Application• Tuning N1QL• Performance testing at Couchbase• Measuring Couchbase Performance• Benchmarks• Demo


What is Couchbase?

Couchbase is a distributed operational database that enables you to develop with agility and operate at any scale.

Managed Cache Key-Value Store Document Database Embedded Database Sync Management


Operate at Any Scale

Elastic Scalability Consistent High Performance Always-on Availability

Multi-Data Center Deployment Simple, Powerful Administration Enterprise Grade Security

©2016 Couchbase Inc.


Accessing Data From Couchbase

Key access using Document ID

• Operations are extremely fast

with consistent low latency

• Reads and writes are evenly

distributed across Data Service

nodes

• Data is cached in built-in

Managed Caching layer and

stored in persistent storage layer

Queries using N1QL

• SQL-like : SELECT * FROM

WHERE, LIKE, GROUP, etc.,

• JOINs

• Powerful Extensions (nest,

unnest) for JSON to support

nested and hierarchical data

structures.

• Multiple access paths – Views

and global secondary indexes

• ODBC/JDBC drivers available

Views using static queries

• Pre-computed complex Map-

Reduce queries

• Incrementally updated to

power analytics, reporting and

dashboards

• Strong for complex custom

aggregations


Performance within the Database

• Architecture and Design:• Shared nothing workload distribution• RAM < - > RAM replication and data transfer (DCP)• Managed Caching Layer• Direct Client < - > Node communication

• Efficient Resource Utilization:• Asynchronous and multi-threaded processing• Core data management written in C/C++• Workload isolation between data storage, querying and

indexing (MDS)• Append-only storage format


Performance for the Application

• Choose the right access pattern:• Key-Value

• Primary key lookup, whole document or individual fields• Predictable sub-ms latencies for 100K+ reads/writes per second• Less flexible, application needs more code

• N1QL (plus GSI)• Operational queries: Low-ms latencies, 10K ops/sec• Analytical queries: Variable performance• “Push-down” to data base layer• SQL-based language provides much more flexibility

• Map-Reduce Views• API-based, incremental map-reduce• “Scatter-Gather” = Less scalable for reads, more scalable for

writes


Indexing with Couchbase Server: Views vs GSI

Find the Top 10 Most Active Users for Month of Jan

CREATE INDEX ON customer_bucket(customer_name, total_logins.jan_2015)

WHERE type=“customer_profile”;

SELECT customer_name, total_logins.jan_2015 FROM customer_bucket WHERE type=“customer_profile” ORDER BY total_logins.jan_2015 DESC LIMIT 10;

Q1: Execution Plan on N nodes1. Scatter: Scatter Q1 to N nodes2. Gather: Gather N results from N nodes3. Finalize: Re-Aggregate Q1 on 1 node

Local Indexes (Views)

Q1Active @ Jan 2015

Cluster Manager

Data Service

Managed Cache

Storage

Cluster Manager

Managed Cache

Storage

Cluster Manager

Managed Cache

Storage

Cluster Manager

Managed Cache

Storage

Cluster Manager

Managed Cache

Storage

Index ServiceQuery

Service

Data ServiceIndex

ServiceQuery

Service

Data ServiceIndex

ServiceQuery

Service

Data ServiceIndex

ServiceQuery

Service

Data ServiceIndex

ServiceQuery

Service

1

2

3


Indexing with Couchbase Server: Views vs GSI

Find the Top 10 Most Active Users for Month of Jan

CREATE INDEX ON Customer_bucket(customer_name, total_logins.jan_2015)

WHERE type=“customer_profile”;

SELECT customer_name, total_logins.jan_2015 FROM customer_bucket WHERE type=“customer_profile” ORDER BY total_logins.jan_2015 DESC LIMIT 10;

Q1Active @ Jan 2015

Q1: Execution Plan on N nodes1. Execute Q1 on N1QL Service node2. Scan index on Index Service node3. Return results to application

Global Indexes (GSI)

Cluster Manager

Index Service

Managed Cache

Storage

Cluster Manager

Index Service

Managed Cache

Storage

Cluster Manager

Query Service

Managed Cache

Storage

Cluster Manager

Data Service

Managed Cache

Storage

Cluster Manager

Data Service

Managed Cache

Storage

1

2

3


Tuning N1QL – Indexing, Indexing, Indexing!

• Global Secondary Indexes/Memory Optimized Indexes:• Index any JSON field (including nested and array structures)• Compound/Composite Indexes• Functional Indexes• Partial Indexes• Covering Indexes• Partition-able for scaling out

• Per-query scan consistency options• EXPLAIN plan for analysis/optimization

• Best Practices for performance:• Covering indexes• Avoid “intersect” scans• Smaller result sets


Couchbase Testing Suite - Summary• Couchbase Software goes through rigorous testing

• 4,500 Functional Tests via continuous integration model • Hours of functional testing – 12000 for major releases, 4500 for

minor releases• Platform certification – 3000 functional tests • Scale tests on 30 node on a weekly basis, 130 node being run on a

monthly basis• 30+ different System test setups including some customer workloads• Hours of performance testing - 5000+ hours for major, 2000+ hours

for minor releases• 103 performance metric captured for Performance tests

Couchbase Testing Suite

Sanity & Unit Testing

Functional Testing

RegressionTesting

SystemTesting

ScaleTesting

PerformanceTesting

©2016 Couchbase Inc.©2016 Couchbase Inc. 14


Performance Testing


Measuring Couchbase Performance

• Hundreds of metrics available from Couchbase Server:• Throughput: • Data Service: >100k reads/sec/node • Data Service: >10k writes/sec/node• Query Service: >10k queries/sec/node

• Latency: • Data Service: 500µs-1ms for reads and writes in RAM• Data Service: 1ms replication between nodes• Query Service: 1-3ms for simple lookup queries

• N1QL:• SELECT * FROM system:active_requests;• SELECT * FROM system:completed_requests;

• Built-into client/SDK:• Throughput/Total Ops• Latency Histograms



Benchmarks


Latest YCSB Benchmarks

Couchbase Key-Value Access

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

454,652

YCSB Workload A Throughput %50 Read + %50 Write

Couchbase Server 4.5

Ops

/sec

Details: Standard Workload A as Defined by the Benchmark, 1 bucket 150M items with 1K size, Couchbase Server 4.5, 9 c3.8xlarge nodes


Latest YCSB Benchmarks

Couchbase N1QL Queries

0

5000

10000

15000

20000

25000

30000

35000

30,911

YCSB Workload E Throughput %95 Range Queries + %5 Writes

9 Nodes Couchbase Server 4.5

Ops

/sec

Details: Standard Workload E as Defined by the Benchmark, 1 bucket 150M items with 1K size, Indexing: Memory Optimized GSI, Couchbase Server 4.5, 9 c3.8xlarge nodes


Couchbase on Google Cloud Engine 1M writes/sec to disk on Google Cloud Engine, median latency 15ms, 95th at 27ms Couchbase server 3.1.5: 50 nodes, n1-standard-16 VMs, 500GB SSD per node

https://cloudplatform.googleblog.com/2015/05/Couchbase-Server-Hits-One-Million-Writes-Per-Second-with-Just-50-Nodes-of-Google-Compute-Engine.html


Couchbase Performance Improvements• YCSB improvements: Hundreds of commits/improvements to Couchbase Java

SDK• https://github.com/brianfrankcooper/YCSB/tree/master/couchbase2• JAVA Object cleanup• Remove thread contention• Streaming improvements

• Couchbase Server 4.5:• “Memory-Optimized” indexes: 20X throughput improvement from standard GSI• Array-element indexing: 2000X query latency improvement• “Flexible JOIN”: 7x query latency improvement• Sub-document API: 10X key-value latency improvement for large documents• Enterprise Backup-Restore: 2x faster• Key-Value throughput: 20% more throughput

0

1

2

3

4

5

6

7

8

Subdoc Fulldoc

95% Get Latency95% Set Latency

0

50

100

150

200

250

300

350

400

450

EE CE

Backup speed(MB/s)

Restore speed( MB/s)

0

10000

20000

30000

40000

50000

60000

70000

80000

Array index 4.5 (MOI) Primary index 4.5 (MOI)

https://github.com/brianfrankcooper/YCSB/tree/master/couchbase2




Couchbase Performance Improvements• 3 nodes, 24 cores, 1 bucket, 1 replica, 20M * 256b docs• 100% resident, 80:20 read/write, same latency

4.1.1 4.5.0 Improvements

Reads/s 235K 285K 21%

Writes/s 58K 72K 24%

CPU 75% 70% 7%


N1QL Configuration• curl -u Administrator:password http://localhost:8093/admin/settings >z.json• Edit the z.json & increase servicers • Example:

• {"completed-limit":4000,"completed-threshold":1000,"cpuprofile":"","debug":false,"keep-alive-length":16384,"loglevel":"INFO","max-parallelism":1,"memprofile":"","pipeline-batch":16,"pipeline-cap":512,"request-size-cap":67108864,"scan-cap":0,"servicers":32,"timeout":0}

• CHANGE the relevant values. • E.g., Your queries are getting large number of documents for each query.• Increase pipeline-batch to 1024 and pipeline-cap: 4096

• Do the following:• curl -u Administrator:password http://localhost:8093/admin/settings -XPOST -

[email protected]

http://localhost:8093/admin/settings





Demo


Summary

• Performance tests are run on daily & weekly basis.• Major releases: Over 5000 hours of performance testing are usually spent on major

releases.• Minor releases: About 2000 hours on minor releases.

• Any regression in any of the metrics (103) will be reviewed and analyzed immediately.

• All releases (from Major to Maintenance) will not be signed off if there is major regression.

• YCSB workloads A & E are run on 4 node cluster and analyzed and will not be signed off if there is a major regression


Share your opinion on Couchbase

1. Go here: http://gtnr.it/2eRxYWn

2. Create a profile

3. Provide feedback (~15 minutes)

http://gtnr.it/2eRxYWn




Thank you!