Proof of concept may be just what you need to start when you’re evaluating Couchbase.
We’ve been blogging a lot about the technical side of moving from a relational database like Oracle or SQL Server to Couchbase. Here are some of the resources and posts we’ve published:
But for this post, we’re going to talk more about the overall process instead of the technical details. You’ll see five steps to creating a successful proof of concept. And if you ever need help getting started, you can talk to a Couchbase Solutions Engineer.
Proof of Concept steps
These steps are not just for migrating an existing application to Couchbase, they also work just as well for creating a brand new “greenfield” application with Couchbase, or even augmenting an existing database (as opposed to replacing it completely).
When creating a Proof of Concept, it’s a good idea to keep the scope as small and simple as possible. Some questions to ask:
Will it prove/disprove what you need it to, and help you move to the next step?
Can this be accomplished fairly quickly? If it takes too long or isn’t a priority, it might fizzle out.
Ask a Couchbase technical team member: is this a good fit for Couchbase? You can draw on their experience to save yourself some heartburn.
Select a use case and application
When I talk to people about Couchbase and NoSQL, I tell them the only thing worse than not using Couchbase is using Couchbase for the wrong thing and becoming soured on document databases.
"Different isn't always better, but better is always different." – Author Unknown
— Programming Wisdom (@CodeWisdom) May 16, 2017
The benefits of a distributed database like Couchbase are:
Greater data agility/flexibility
Improved operational management
If your application can benefit from one of those characteristics, it’s worth checking out Couchbase. Couchbase may not be the best fit if you need multi-document transactions. But as I showed in my post on data modeling, if you can nest data instead of scattering it in pieces, you may not need multi-document transactions as much as you think.
Further, conversations with Couchbase customers have lead us to identify the need beyond a traditional database to power interactions. Marriott calls this the “look-to-book” ratio.
If you’re in a situation where you need to record transactions in your traditional database, but you want a low-latency, flexible, scalable database to power all the interactions leading up to it, Couchbase might be the right fit for you.
Some use cases that Couchbase has been a great fit for include:
Product Catalog (Customer spotlight: Tesco)
Content Management (Customer spotlight: replacing SQL Server with Couchbase for content management)
Customer Management (Customer spotlight: DirecTV)
File or Streaming Metadata Service
And many more: check out our whitepaper on top 10 enterprise use cases for NoSQL
Define the success criteria
Once you’ve decided that you have a use case that would be good for Couchbase, you need to define what it means for a proof of concept to be successful.
Examples of criteria:
Performance/latency improvements – This might boil down to a number, like “5ms latency in the 95th percentile”.
Ease of scaling – How easy is it to scale now? How much time does it take a person? How many 2am Saturdays do you need to work to do upgrades?
Faster development cycles – Does schema management eat up a lot of time in your sprints? A proof of concept with Couchbase can help to demonstrate if a flexible model is going to save you time.
Maintenence and costs
"The most important single aspect of software development is to be clear about what you are trying to build." – Bjarne Stroustrup
— Programming Wisdom (@CodeWisdom) May 6, 2016
Whatever the criteria, it’s good to define it at the beginning, so you can work towards trying to achieve that. A vague goal like “I just want to play around with NoSQL” is fine for an individual developer, but a well-defined success criteria is going to be critical for convincing decision makers.
Understand your data
As I covered in the JSON data modeling post, it’s important for you to understand your data before you even start writing any code. You need to understand what you are going to model and how your application needs to function.
Migrating from a relational to a document database is not going to be a purely mechanical exercise. If you plan to migrate data, it’s better to start by thinking about how it would look independent of how it’s currently stored. Draw out a concept of it on a whiteboard without using “tables” or “documents”.
"Weeks of coding can save you hours of planning." – Unknown
— Programming Wisdom (@CodeWisdom) August 22, 2017
Identify the access patterns
I also covered this in my JSON data modeling post. Couchbase is very flexible in the way that it can store data. But, data access is also flexible. The design of your model should take that into account.
"Figure out your data structures, and the code will follow." – William Laeder
— Programming Wisdom (@CodeWisdom) January 24, 2018
In that blog post, I layed out some rules of thumb for nested/seperate documents. At a higher level, you can start with thinking about data access like this:
Key/value – The ability to get/change a document based on its key. This is the fastest, lowest latency method available in Couchbase.
N1QL query – N1QL is SQL for JSON data, available in Couchbase. It can query data just about any way you can imagine. Most importantly, you can query data based on something other than its key.
Full Text Search – When you need to query based on text in a language aware way. Great for user driven searches, for instance.
Map/Reduce – Writing a pure function to calculate query results ahead of time. N1QL is taking a lot of the workload away from M/R, but it’s still good for some specialized types of aggregation.
Geospatial – Querying of documents based on some geographical/location based information.
Analytics/reporting – Couchbase Analytics (currently in preview) can give you heavily indexed non-operational access to your data. You can run complex reports without impacting day-to-day users.
Review the architecure
At the end of your proof of concept, you can measure your results against the criteria that you created at the very beginning.
It might be a good idea to iterate on this proof on concept: you can apply what you’ve leaned in each subsequent iteration. If you keep the iterations short, you can learn what you’ve applied faster. This isn’t just true of Couchbase, by the way, but anything!
"When to use iterative development? You should use iterative development only on projects that you want to succeed." – Martin Fowler
— Programming Wisdom (@CodeWisdom) November 22, 2017
Finally, if your proof of concept is a success (and I know it will be), then it’s time to prepare for production. Take the time to review the architecture, the decisions you’ve made, what worked well, what didn’t work well, and so on. The more you document, the better off the rest of your team and organization will be on the next project.
Creating a proof of concept with these five steps will help make you successful! All that’s left to do is get started: