In the evolving landscape of database technology, choosing the right database management system is crucial for the efficiency and scalability of applications. This article presents a detailed comparison of the performance between Microsoft's CosmosDB and MS SQL Server. We'll examine how each database performs under various load conditions and share some interesting findings.
In this article, I will introduce NoSQL concepts and show how they are related to Elasticsearch, and we will consider this search engine as a NoSQL document store.
This is a series of articles dedicated to the optimal choice between different systems on a real project or an architectural interview.
This topic seemed relevant to me because such tasks can be encountered both at work and at an interview for System Design Interview and you will have to choose between these two types of DBMS. I plunged into this issue and will tell you what and how. What is better in each case, what are the advantages and disadvantages of these systems and which one to choose, I will show with several examples at the end of the article.
SQL or NoSQL?
In this article, I will tell you about a-few-years journey of scaling the Elasticsearch cluster in production environment, which is one of the vital elements of the iPrice technology stack.
I will describe challenges we encountered and how we approached them.
In the first part of You don't know Redis, I built an app using Redis as a primary database. For most people, it might sound unusual simply because the key-value data structure seems suboptimal for handling complex data models.
In practice, the choice of a database often depends on the application’s data-access patterns as well as the current and possible future requirements.
Redis was a perfect database for a Q&A board. I described how I took advantage of sorted sets and hashes data types to build features efficiently with less code.
Now I need to extend the Q&A board with registration/login functionality.
I will use Redis again. There are two reasons for that.
Firstly, I want to avoid the extra complexity that comes with adding yet another database.
Secondly, based on the requirements that I have, Redis is suitable for the task.
Important to note, that user registration and login is not always about only email and password handling. Users may have a lot of relations with other data which can grow complex over time.
Despite Redis being suitable for my task, it may not be a good choice for other projects.
Always define what data structure you need now and may need in the future to pick the right database.
As a side hustle, I teach tech recruiters web and software development technologies using plain English. It helps them with understanding job specs and resumes and it makes all of us, tech people, happier.
I run a weekly newsletter and often get feedback from recruiters via email or LinkedIn DMs.
I thought that I could try to collect feedback using the “Reactions” feature just like LinkedIn or Facebook does. It’s not as informative as personalised messages but is a simple feature that may incentivize more people to provide some general feedback.
Either way, it’s worth trying and as a software developer, I can’t wait to implement it.
This tutorial is about implementing a feature that will be used in real life on my project.
Originally posted on DEV.to
In my previous post, I touched on the point that Redis is more than just an in-memory cache.
Most people do not even consider Redis as a primary database. There are a lot of use cases where Redis is a perfect choice for non-cache related tasks.
In this article, I will demonstrate how I built a fully functional Q&A board for asking and upvoting the most interesting questions. Redis will be used as a primary database.
I will use Gatsby (React), Netlify serverless functions and Upstash Serverless Redis.
Upstash has been a good choice so far and I decided to try it out in a more serious project. I love everything serverless and how it makes things simpler for me.
Serverless will be a great choice for most tasks however you need to know the pros and cons of the tech you are using. I encourage you to learn more about serverless to get the most out of it.
Academic data warehouse design recommends keeping everything in a normalized form, with links between. Then the roll forward of changes in relational math will provide a reliable repository with transaction support. Atomicity, Consistency, Isolation, Durability — that's all. In other words, the storage is explicitly built to safely update the data. But it is not optimal for searching, especially with a broad gesture on the tables and fields. We need indices, a lot of indices! Volumes expand, recording slows down. SQL LIKE can not be indexed, and JOIN GROUP BY sends us to meditate in the query planner.
