January 6, 2015
If you have read about Riak, or seen a member of the Basho team present, you have probably heard the phrase “Your data is opaque to Riak.” While this is not, strictly, true with the inclusion of distributed Data Types in Riak 2.0, it was a phrase that hinted at the core structure of Riak itself.
Riak is a Key Value data store.
In a relational database, data is organized by tables that are separate and unique structures. Within these tables exist rows of data organized into columns. As such, interaction with the database is by retrieving or updating entire tables, individual rows, or a group of columns within a set of rows.
In contrast, Riak has a much simpler data model. An Object is both the largest and smallest element of data. As such, interaction with the database is by retrieving or modifying the entire object. There is no partial fetch or update of the data.
Keys in Riak are simply a binary value (or a string) that are used to identify Objects. The Key/Value pair (or Object) is stored in a higher level namespace called a Bucket. And, with Riak 2.0, there is an extra layer of abstraction known as Bucket Types.
This Key/Value/Bucket model enables broad flexibility in modeling the applications data domain with Riak as the data store for persistence.
Another NoSQL model that many are familiar with is the document store. Unlike the Key/Value model the data store is aware of the structure of the objects stored. These objects, or documents, are grouped into “collections” — which is analogous to a relational “table” — and the datastore provides a query mechanism to search collections for objects with particular attributes. When the data that is being persisted is easily rendered as a JSON document, a document store can seem a natural fit. Some common use cases include product catalog data and content management systems.
The Basho Docs have a lengthy tutorial entitled Using Riak as a Document Store that walks you through the process of leveraging Riak as a document store for a CMS. There are many approaches to modeling, but the tutorial demonstrates the power of Riak 2.0 features by combining the maps data type and indexing that data with Riak Search.
When the data you are persisting can be represented as JSON, and you require the ability to query the data, Riak 2.0 is an excellent solution for persisting and modeling document data. The flexibility of the Key/Value model, combined with the power of Riak Search and Riak Data Types, provide you with a highly scalable, highly available document store with rich, full-text query capabilities. In addition, the inclusion of the maps data type means that you don’t have to write complex client side resolution logic when faced with network partitions. Riak Data Types handle that conflict resolution automatically.
A scalable, available document store that is operationally simple may seem compelling enough to use Riak. But when you combine the characteristics of Riak with the multi-datacenter replication capabilities of Riak Enterprise, now you have a solution that enables you to bring your data operations closer to the end user.
Scalable, available, operationally simple, and replicated. That’s the power of using Riak as a document store.
December 30, 2014
At Basho, we are proud of our documentation. All design, updates, and edits are done with our community top of mind and we encourage community participation. Given the pace at which our documentarian expert, Luc Perkins, is updating the content, it can be easy to fall behind in reading new and updated materials. So we have a holiday gift to help you out.
Below is our Top 10 suggested New Year’s reading list.
#10 – A Migrating from an SQL Database to Riak tutorial can help prepare you as embrace a new style of development and persistence.
#7 – Strong consistency has gone from having light documentation to being one of our best-documented open-source features. Strong Consistency docs are spread across the following:
#6 – We now have client-side security docs! There’s an introductory doc that walks you a bit through how client security works in Riak as well as client-specific docs for Java, Ruby, Python, and Erlang.
#5 – A new Erlang VM Tuning doc. This is still a work in progress. As we said at the beginning, we really encourage community involvement. What tuning have you done to optimize your Erlang environment?
In addition to the above, there is new documentation on the topics below.
Drum roll please….
#1 – Riak 2.0 – if you missed this you missed a lot.
We want to thank everyone in the community who participates in making the Basho documentation the most useful set of materials possible. Remember: to submit issues is human, to submit PRs is divine.
Happy New Year!
December 23, 2014
This is a continuation in our blog series covering Riak 2.0. Below are links to the previously covered blogs and we continue with a discussion on Values, Keys, Buckets and Bucket Types.
- Riak 2.0 – New Capabilities, New Use Cases, Available for Download
- Write it like Riak; Query it Like Solr
- Riak Security 2.0: Not Just a Firewall Anymore
- Distributed Data Types – Riak 2.0
- Strong Consistency in Riak 2.0
If you have tested Riak 2.0, or used it in production, you will also be aware of a new feature called Riak Bucket Types
The Using Bucket Types documentation covers the implementation, usage, and configuration of Bucket Types in great detail. Throughout the documentation there are code samples (e.g. Using Data Types) including code for creating the bucket types associated with each individual Riak Data Types.
Bucket types are a major improvement over the older system of bucket configuration. The ability to define a bucket configuration, and then change the configuration if necessary, for entire group of buckets, is a powerful new way to consider data modeling. In addition, bucket types are more reliable as buckets that have a given type (or configuration) only have their properties change when the type is changed. Previously, it was possible to change the properties of a bucket only through client requests.
In prior versions of Riak, bucket properties were altered by clients interacting with Riak…in contrast, bucket types are an operational concept. The
riak-admin bucket-type interface enables Riak users to manage bucket configurations at an operational level, without recourse to the Riak clients.
In versions of Riak prior to 2.0, all queries were made to a bucket/key pair as in the following example:
Now in Riak 2.0 with the addition of bucket types, there is an additional namespace on top of buckets and keys. The same bucket name can be associated with completely different data if it is used in accordance with a different bucket type.
If a request is made to a bucket/key pair without a specified bucket type,
default will be used in place of a bucket type. The following request are identical.
Bucket types allow groups of buckets to share configuration details. This allows Riak users, and administrators, to manage bucket properties more efficiently than in the older configuration systems that were based on bucket properties.
For a broader discussion of application data modeling, and using Riak as a data store, the Building Applications with Riak documentation covers these concepts, and more, in great detail.
Riak 2.0 was the culmination of substantial effort by the Basho team. A particular focus was adding functionality (like Riak Search) that had been requested by customer. In addition, this release further the Basho commitment to providing a scalable and available database that has the operational simplicity for which Riak is known.
It just works.
October 8, 2012
I’m proud to announce that today, Basho has delivered an overhaul to our existing documents to docs.basho.com. We streamlined the navigation, look and feel, and content. We also made some changes that will allow us to easily document future versions of Riak, without crushing legacy documents.
When I first investigated Riak for my book, I was impressed by the technical elegance of the project, but wished that the documentation better conveyed the beauty of the project. Today’s launch takes us one step closer to helping Riak users, and the merely curious, to discover the beauty I had — without resorting to reading the source code.
Crafting documentation isn’t the sexiest piece of an open source project, but it’s one of the vital ones. You can have amazingly well designed code (we do) that’s well tested (it is), but if users don’t know how to work it, your project will never grow beyond a curiosity for insiders and dedicated enthusiasts.
There is a lot to get excited about these changes. Here are a few of the gems:
Ground-up Information Architecting
The top goal of this rebuild was to make it easier to quickly find the information you’re looking for. We organized our existing wiki docs (which were growing a bit wild) into categories which would be of interest to various end users: beginners, developers and operators, and separated guides from references.
We have new avenues for finding docs, beyond the obvious primary navigation on the left. As you dive into the pages you may notice subtler forms. At the top of some longer docs, there exists a table of contents for fast navigation. And floating to the right is a version bar. This allows you to see versions of this document that apply to older versions of Riak.
Once you read through a document, most pages have a secondary “These May Also Interest You” list of links you might also want to read up on.
Most docs are also tagged with keywords. If you click one, you’ll be taken to an index of all documents with that same keyword for fast orthogonal navigation. Click on
One of the realities of managing docs is wrangling changes to the application between versions. If you’re not careful, your documentation can easily become out of date, or filled with warnings (note! this only applies to 1.2.x!). We were inspired by the way that Node.js managed their docs, keeping every previous version since the beginning of time and pointing the latest directory to the newest version.
This allows you to not only navigate back in time to older versions, but also helps reduce the chance of broken links and allows us to evolve the design over time without confusing those who are used to older document versions.
The docs don’t merely reflect Basho’s newer styles, but also an intent to give you the information you need to get things done. Collapsible nav is useful when reading out side-by-side docs (check out our Riak to Dynamo comparison work in progress).
A responsively designed site will shrink/hide items to take full advantage of smaller screens like iPads and smartphones.
The design has other goodies, too, like a straightforward landing page, clear code samples, and easy to read type and font sizes.
The navigation look and feel should also help clarify where you are in the documentation at all times, reducing the chance of getting lost.
Similar to the Riak wiki, the Riak documentation and code is open source, and is open for anyone to contribute. I also created a new FAQ Markup Language, called FML. All of our FAQs are written in this markup. The rest is largely markdown and Middleman’s frontmatter.
This isn’t out yet, but look for it within the week.
The old wiki site used Google to search through the static site, so we thought: why not use Riak?
We’re test driving the newest Riak Search functionality for some good reasons. Importantly, we use Riak Search to eat our proverbial dog food. But there’s a better reason: because the new search ended up being the best method for searching content with high uptime.
We wanted to search with facets, by version ranges for example. We wanted to extract metadata from each document’s frontmatter, so we created a custom extractor. Clearly we wanted full-text search. We wanted it to be fast and distributed, a core feature of the new search.
The new Riak Search leverages the real power of SOLR, with the benefit of Riak KV as a storage engine. One installation. One cluster to manage. No mess, no fuss.
We’re sorry to have to play teaser to this new search, but it will be out before you know it. (If you’re at RICON this week, you’ll be learning all about it.)
So many people made these docs possible, there are literally too many to name them all here. But special thanks go to John Newman for his amazing design skills, Seth Benton and Brian Shumate for amazing work and eyes to detail. Justin Pease and the CliServ team for their hand in a realistic view of what users actually need; Mark Phillips, Shanley Kane, and the rest of Marketing for a strategic vision for these docs; Sean Cribbs and the Basho Engineering Team for working on version 1.0 of the docs; Ryan Zezeski for the new search, and the rest of Basho and our community for supporting this project.
This isn’t the Oscars, so I’ll just add, thanks go to everyone who had a hand in making these, including the community who worked to build Riak docs v1.0. Writing documentation might seem easy, but it’s a massive undertaking—and this is just the beginning.