RavenDB has been around for a little over a decade and is currently used by thousands of customers, including fortune 500 companies like Toyota and Verizon, but it hasn’t always been smooth sailing. Like any other software, RavenDB has had its growing pains, particularly in the early days when the company was made up of just a handful of developers.
User feedback has always played an important role in our development. Many of RavenDB’s features were added due to popular demand, and our customers have helped us find countless obscure bugs by using our software in ways we never could have imagined.
Need help with your NoSQL migration? Look no further than our "NoSQL Migration Essentials" Refcard. We walk through the primary steps for moving out of a relational database, plus important design principles to understand and consider in your migration process.
Readers will review key concepts that range from denormalizing and modeling data to defining access patterns, designing primary keys and indexes, and creating an entity relationship diagram — all demonstrated with a simple site application example. As a bonus, readers can use the included JSON structure at the end to interact with a NoSQL playground.
Benchmarking will help you fail fast and recover fast before it’s too late.
Teams should always consider benchmarking as part of the acceptance procedure for any application. What is the overall user experience that you want to bake into the application itself? Ensure that you can support scaling your customer base without compromising user experience or the actual functionality of the app.
Introduction
In this article we’ll discuss how RavenDB indexes documents and how it differentiates itself from MongoDB, another NoSQL document database, as well as the relational database, PostgreSQL.
When it comes to indexing, RavenDB favors “eventual consistency” which means that it optimizes for high throughput read and write scenarios and attempts to return results to queries as fast as it can. These results may be “stale” until the index incrementally rebuilds to catch up to any new document changes. In RavenDB, you may also explicitly wait for non-stale results. On the other hand both MongoDB and PostgreSQL favor consistency (unless read on a secondary replica) but this means indexes impact read/write performance.
There are two main categories of databases in use in the developing world today, commonly referred to as SQL and NoSQL. In this article, we will compare an SQL vs. NoSQL database based on its pros and cons.
SQL, or Structured Query Language, is the universally known query language for relational databases. SQL databases make it simpler to work with structured data in a database through CRUD operations. CRUD stands for create, retrieve (or read), update, and delete – the primary operations for manipulating data.
In this post, we will learn how to create a MongoDB Projection. Basically, projections allow us to retrieve selective fields of a document while querying a collection.
If you are new to MongoDB, you can check out this detailed post about MongoDB CRUD Operations. This is because the CRUD operations form the basis for other complicated operations.
Since NoSQL Databases are widely used and preferred among developers, because of their close relation to the Agile methodology, we decided to focus on their functionality in this article. At first, we need to define how we see NoSQL abbreviation, considering that there are several different versions for that. In the battle of the meanings, we have literally the database without SQL usage, and "not only SQL." Surely, we’d prefer to cognize the second option, but not anti-definition, given that SQL is running in any backend and traditionally is not eliminated.
The NoSQL databases create more intuitive methods of storing data, allowing to model the structured linkage that will be closer to the application’s form. They require fewer transformations when saving or retrieving with NoSQL APIs. Furthermore, NoSQL databases can fully utilize the Cloud to ensure minimal outage. As you can notice, NoSQL DB seems to be beneficial and more flexible than traditional storing. Let’s discover this difference in further detail.
TLDR; Choosing the Right Mode for DynamoDB Scaling
Making sense of the multitude of scaling options available for DynamoDB can be quite confusing, but running a short checklist with a calculator can go a long way to help.
- Follow the flowchart below to decide which mode to use.
- If you have historical data of your database load (or an estimate of load pattern), create a histogram or a percentile curve of the load (aggregate on hours used) – this is the easiest way to observe how many reserved units to pre-purchase. As a rule of thumb purchase reservations for units used over 32% of the time when accounting for partial usage and 46% of the time when not accounting for partial usage.
- When in doubt, opt for static provisioning unless your top priority is avoiding being out of capacity – even at extreme costs.
- Configure scaling limits (both upper and lower) for provisioned autoscaling. You want to avoid out-of-capacity during outages and extreme costs in case of rogue overload (DDOS anyone?)
- Remember that there is no upper limit on DynamoDB on-demand billing other than the table’s scaling limit (which you may have requested raising for performance reasons). Make sure to configure billing alerts and respond quickly when they fire.
The Long Version: Configuring DynamoDB Tables
Before we dive in, it’s useful to be reminded of DynamoDB different service models and their scaling characteristics: DynamoDB tables can be configured to be either “provisioned capacity” or “on-demand”, and there’s a cooldown period of 24 hours before you can change again.
For some time, products have been leaning towards NoSQL databases because of the number of advantages that they provide compared to Relational databases (RDBMS), especially in today’s distributed systems. There is always a pressure of delivering things faster to make it live to end users. But does that mean relational databases won’t be able to compete with NoSQL databases, provided Relational Databases are still best-known for adhering to the ACID property?
Here, I am going to explore the possibilities from Relational Databases perspective and how they come a long way to compete with NoSQL Databases. I am going to compare two managed databases from AWS, DynamoDB and Aurora, to see if it's really worth giving credit to one type of database over another.
Six thousand years ago, the Sumerians invented writing for transaction processing -
Gray & Reuter
By any measure, MongoDB is a popular document-oriented JSON database. In the last dozen years, it has grown from its humble beginnings of a single lock per database to a modern multi-document transaction with snapshot isolation. MongoDB University has trained a large number of developers to develop on the MongoDB database.
There are many JSON databases now. While it's easy to start with MongoDB to learn NoSQL and flexible JSON schema, many customers choose Couchbase for performance, scale, and SQL. As you progress in your database evaluation and evolution, you should learn about other JSON databases. We're working on an online training course for MongoDB experts to learn Couchbase easily. Until we publish that, you'll have to read this article. :)
When you need to query documents using SQL, there are two options available in Couchbase. The Query service and the Analytics service. Our blog, N1QL: To Query or To Analyze? provides a detailed overview of both services. I highly recommend reading it before this one. This article aims to expand on the previous blog by adding some concrete, hands-on examples. For each example we’ll cover how to write the query in both services and we’ll look at the performance differences. The goal is that readers will walk away with more knowledge to help quickly identify patterns and use cases that best fit each service.
Summary
Before jumping into examples. Let’s refresh ourselves on the high-level key characteristics of the two services.
Organizations who want to take advantage of the many benefits of NoSQL databases, often find that they have two challenges:
- How to convert their RDBMS schemas to leverage the schema-less document model.
- Learn a new API/Query to access the data.
Some also find the confusion with the NoSQL name. The abbreviation stands for 'Not only SQL', but it can also be misinterpreted it as 'No to SQL', thus accepting that in order to use NoSQL database, organizations will not only have to convert their relational data model into the document model, but also get training on whichever APIs for the NoSQL database that they will select.
When searching for information on what instance type to use, the answer is typically, "it depends." This article boils down instance types with both general data on EC2 types as well as in-depth analysis of KeyDB performance and selection for different types.
The focus of this article will be using KeyDB as an in-memory database. There will be future articles on using KeyDB with FLASH storage, as well as with some of KeyDB-Pro's features, such as FLASH persistence and advanced querying, where many more cores can be taken advantage of under query intensive workloads (O(n) heavy operations, such as KEYS). When AWS Graviton2's are available, we will publish those results too.
The word “database” instantly creates a picture of a table having rows and columns. Typically, any system architecture has a relational database management system (RDBMS) to store data. Data in an RDBMS is stored in tables containing rows and columns, and tables are connected to each other via relational models.
Examples of traditional RDBMSs include Oracle, MySQL, Microsoft SQL Server, DB2, etc. These databases have been in the market for a substantial amount of time, as they are highly efficient and deliver great performance.
Azure Cosmos DB
Introduction
Cosmos DB can be considered one of the most lethal weapons in Azure’s arsenal. It comes with a bunch of features that makes this service stand out among its various database offerings.
Recently, I utilized it for a flash sale requirement, where the hits-per-second requirement was more than 6k, the application was storing the users and orders details from multiple regions in real-time.
Fork of Redis
This article discusses several changes we have made to the EXPIRE command and how it works. This article shows that these somewhat controversial features are feasible. We have added the ability to expire individual members of a set with the EXPIREMEMBER command and have also enabled active deletion to operate in near real-time, which has big advantages for those who rely heavily on using expires in production. Throughout the work with the EXPIRE command, we have actually achieved 5-10% memory savings.
You might also like:
How to Expire Objects in Data Storage
This work has been done in KeyDB (by EQ Alpha Technology), which is an open source, high-performance fork of Redis, where we are able to implement features that may never become a part of Redis. We hope the two projects can continue to grow and learn from each other.
Quick start on DynamoDB
My intention is to make it loud and clear that learning Dynamo DB is simple and easy to use. Before we jump right into it, I would like to familiarize you with the following. This article can be considered a quick reference for the DynamoDB starters.
You may also like:
Should You Use DynamoDB? (Part 1)
This will help to unlearn the RDBMS mindset and give you enough torque for learning and implementing this quickly.
Analyzing US lobbying data in Neo4j
Overview
In a previous post, I loaded a subset of federal lobbying data into Neo4J; almost 19,000 filings from 2019 Q1.
The database schema created by my project includes 6 distinct nodes and 7 distinct relationships.
