FAQ
Apache CouchDB™ Production Support
What is a Ticket?
As soon as you are set up as a support customer you can send requests to our CouchDB Support Team via email or via Freshdesk, our ticketing system. Every new request opens a ticket in our ticketing system. By opening a ticket you let us know about a concrete problem with your CouchDB and we are working on a solution with you.
There is a distinction between “Production Tickets” and “Development Tickets”:
Examples for "Production Tickets":
- Server failure / Troubleshooting
- Live upgrade monitoring
Examples for "Development Tickets":
- „Best practices“ Review
- Data design for CouchDB
- Check if the used CouchDB version is eligible for an upgrade
Incoming requests can be split into multiple tickets as needed by the TNH team if they contain different topics and tasks.
How do you prioritize incoming tickets?
"Production Tickets" in principle have a higher priority than "Development Tickets". After a request has been received by TNH, the resulting tickets will be divided into the following priority levels:
| Priority level | Ticket category | Description |
|---|---|---|
| Urgent | Production Ticket | Production is disrupted, server failure. The service is either not available at all or an entire feature does not work anymore. |
| High | Production Ticket | Very limited service, even irregular service or reduced quality of service. |
| High | Development Ticket | A development ticket can be classified as "high" in order to make the client's priority clear to TNH. However, the classification does not affect reaction or solution times due to TNH. |
| Medium | Production and Development Ticket | General inquiries, product questions, feature requests, and development issues that are considered more relevant to the customer than others. |
| Low | Production and Development Ticket | General inquiries, questions about the product, feature requests and development questions. |
When will I get a response on my ticket?
Critical tickets (“Production Tickets”) have a response time of two hours inside EU business hours, in which we will show a first reaction. The response time for “Development Tickets” is one business day.
Do you have access to sensitive data?
When we offer Apache CouchDB Support or CouchDB Consulting, you grant us regular access to your company's and/or your customer's databases and local systems. We use this data exclusively for the purpose of fulfilling the contract and also evaluate the communication of access data or the direct transmission of such data to us as consent to the collection, processing and use.
If your data is very sensitive and you would prefer to not grant us direct access, but would like to talk about possible alternatives, please reach out to us.
Apache CouchDB™ Architecture Review
How do you get information about my CouchDB?
You will be required to run our Opservatory agent, a small node.js application, to gather diagnostic data and statistics from your database. This saves you having to give us direct access to your machines, and allows you to review exactly which data we will receive from you. The application itself does not transmit any data, but only produces a zipped JSON file which you can inspect before sending it to us. You will receive this collector program as soon as the order and the contract have been processed.
What kind of additional information do you need for an Architecture
Review?
For our CouchDB Architecture Review we need additional information on your system and infrastructure. As soon as your order is through we are sending you a questionnaire in which we ask you to provide us the required information.
How can I make use of the three Development Tickets I booked as an add-on
to my Architecture Review?
If you need help answering our questions and collecting the requested information or if you need hands on advice to improve your infrastructure after you have received the results of your Architecture Review, you can book a package of three Development Tickets. This package can be booked in advance or after you have received the results. Development Tickets are not urgent requests which we also offer as part of our CouchDB Production Support.
Structured Query Server (SQS)
Is the use of SQS for my CouchDB limited?
CouchDB is very good at offering simple and medium-complexity queries with speed and scalability. In fact, CouchDB makes a conscious trade-off limiting the complexity of queries in favour of extreme scalability: you can run the same queries on a single node or a 100-node cluster. However, most CouchDB users use between 1–6 nodes and this allows Structured Query Server to make a different trade-off: allow very complex queries, including SQL JOINS, at the expense of extreme scalability. Structured Query Server is still plenty fast and can support a lot of data, but won’t keep up with a 100-node CouchDB cluster. Consult our performance guide below to see whether SQS is a viable option for your scenario.
Is SQS compatible with all other SQL software?
No, SQS is not a fully-fledged SQL interface to CouchDB that is compatible with all other SQL software, as it only supports SELECT statements.
Is SQS only available for SQLite?
Due to SQLite’s technical nature, per-database indexing is single-threaded and querying is serialised through a mutex to ensure correct results. While this leaves some performance opportunities on the table, we plan to address this with future products: Structured Query Server for MySQL, PostgreSQL, MSSQL & Oracle, if we get enough interest in them. Sign up here to register interest and receive news when those ship.
Tell me more about the performance of SQS
We’ve run extensive tests to ensure the best possible performance for Structured Query Server. These act as guidelines and order-of-magnitude comparisons for your own installations. This will let you decide whether Structured Query Server will work with your CouchDB setup. There are two main areas of interest when it comes to SQS performance: indexing and querying.
Indexing Performance
Here, we make two comparisons:
- How much slower is SQS at creating an index by reading the CouchDB _changes feed than just letting curl dump the _changes feed into /dev/null. Of course the latter measure is not practically useful, but it illustrates a theoretical optimum. SQS indexing will be slower, but it does full SQL indexing and persistence, at not-that-large a slowdown.
- How does SQS compare to CouchDB JavaScript views, the most complex default querying option? Here SQS does a lot more work at comparable speeds.
SQS vs _changes to /dev/null (theoretical optimum)
| Number of docs | Doc size in bytes | Difference |
|---|---|---|
| 1,000 — 10,000,000 | 100 | 3.5x (slower) |
| 1,000 — 10,000,000 | 1000 | 1.87x (slower) |
| 1,000 — 10,000,000 | 10,000 | 1.98x (slower) |
Our conclusion is that at a ~2x slowdown for typical databases versus streaming _changes into /dev/null, you get a full SQL query engine. Not bad!
SQS vs JS Views
q=1 database
| Number of docs | Doc size in bytes | Difference |
|---|---|---|
| 1,000 — 10,000,000 | 100 | 0.76x (faster) |
| 1,000 — 10,000,000 | 1000 | 0.84x (faster) |
| 1,000 — 10,000,000 | 10,000 | 1.18x (slower) |
q=2 database
| Number of docs | Doc size in bytes | Difference |
|---|---|---|
| 1,000 — 10,000,000 | 100 | 0.86x (faster) |
| 1,000 — 10,000,000 | 1000 | 0.99x (about the same) |
| 1,000 — 10,000,000 | 10,000 | 1.56x (slower) |
| Number of docs | Doc size in bytes | Difference |
|---|---|---|
| 1,000 — 10,000,000 | 100 | 0.95x (about the same) |
| 1,000 — 10,000,000 | 1000 | 1.07x (about the same) |
| 1,000 — 10,000,000 | 10,000 | 1.81x (slower) |
Our conclusion is that with increased sharding, CouchDB can make better use of multi-core systems, but even for typical large databases, SQS can hold its own. For small databases, SQS even beats JS views. Given that SQS allows for very complex queries, the observed numbers are very favourable.
Querying Performance
Here we measure the number of requests per second against SQS. Each run is 1,000,000 random queries against a fully built index. We ran this with concurrency levels of 1–1,000, the results are all in the same ballpark independent of the concurrency level.
| Number of docs | Time per request (ms) | Requests per second |
|---|---|---|
| 1,000 — 100,000 | 2.73 | 381.1 |
| 500,000 — 750,000 | 3.01 | 321.2 |
| 750,000 — 1,000,000 | 12.2 | 66.65 |
Our conclusion is that up to 750,000 docs in the index, SQS is plenty fast for most workloads and after that the limits of the underlying SQLite library are starting to show, but the performance is still not bad. If you need more concurrent read performance at larger doc counts, sign up for our mailing list to get notified when we can reach higher limits.
If you need to reach higher limits for concurrent queries, you can run multiple instances of SQS on multi-core machines with spare CPU capacity or on dedicated machines.
How much storage does SQS require compared to the original CouchDB?
SQS runs alongside your regular CouchDB installation and it uses its own storage system that is in addition to anything you have in CouchDB. Data size depends on your configuration: you can decide which document types, and which fields in those document types get indexed. Say you have one million documents and do nothing but store a single integer, the storage is somewhere between one and five megabytes.
On the other hand, if you index all of your document fields, the storage requirements increase proportionally. SQS stores its data in SQLite, which uses very little disk space on its own, but like CouchDB, it requires a compaction-type process (called VACUUM) that SQS manages for you, but that means you have to provision a little more storage than just the raw index data in order to create clean compacted copies.
Can SQS be used as a replacement for selector-queries in replication (pulling from CouchDB server to PouchDB clients)?
Structured Query Server (SQS) could help in this case, but not as a replication filter, which would be tricky to implement, but in a slightly different way.
CouchDB’s _replicate/ion endpoint(s) (and PouchDB’s sync() API) have a doc_ids filter option that allows you to start a replication but limit the docs by the list of IDs provided.
You could use a two-step process where you could first query SQS from a client where SQS responds with the list of doc IDs that are relevant for that particular client. You can make that query indefinitely complex using all of the supported SQL, including using JOINS or subqueries to get related documents. Then you pass that list of document ids to the doc_ids filter on the client, which then downloads its particular dynamic set of documents from CouchDB efficiently.