Search

Top 60 Oracle Blogs

Recent comments

aws

CockroachDB troubleshooting series… define the process

After working with customers for about 18 months now, I am starting a blog series to write up the common issues seen while running CockroachDB. Diagnosis and treatment of issues when running on distributed database architectures like CockroachDB, closely mirror the process used in the medical community.

There are observed symptoms which leads to a diagnosis and finally a treatment to resolve the condition. Good troubleshooting methodology can help frame the problem which leads to better overall outcomes. This process is outlined below:

DynamoDB Scan: the most efficient operation

By Franck Pachot

.
The title is provocative on purpose because you can read in many places that you should avoid scans, and that Scan operations are less efficient than other operations in DynamoDB. I think that there is a risk, reading those message without understanding what is behind, that people will actually avoid Scans and replace them by something that is even worse. If you want to compare the efficiency of an operation, you must compare it when doing the same thing, or it is an Apple vs. Orange comparison. Here I’ll compare with two extreme use cases: the need to get all items, and the need to get one item only. And then I’ll explain further what is behind the “avoid scans” idea.

I have created a table with 5000 items:

Amazon Aurora: calling a lambda from a trigger

By Franck Pachot

.
You may want your RDS database to interact with other AWS services. For example, send a notification on a business or administration situation, with a “push” method rather than a “pull” one from a Cloud watch alert. You may even design this call to be triggered on database changes. And Amazon Aurora provides this possibility by running a lambda from the database through calling mysql.lambda_async() from a MySQL trigger. This is an interesting feature but I think that it is critical to understand how it works in order to use it correctly.

Scaling CockroachDB key generation… uuid, serial, and sequences

Overview

Primary keys are critical in any RDBMS in order to ensure the validity of data. Unlike other distributed SQL databases, CockroachDB is not sharded by primary key to distribute the data. Data is divided to ranges and distributed automatically among nodes in the cluster. CockroachDB ranges are sorted by the primary key values. So, while the value doesn’t define the distribution, the sorting of the values can have implications if you use sequences that increment values in a counter-like fashion. This will put stress on a single RANGE of data which scaling of a distributed application.

Aurora Serverless v2 (preview) – CPU

By Franck Pachot

.
This follows my previous post https://blog.dbi-services.com/aurora-serverless-v2-ram/ ‎which you should read before this one. I was looking at the auto-scaling of RAM and it is now time to look at the CPU Utilization.

I have created an Aurora Serverless v2 database (please don’t forget it is the beta preview) with auto-scaling from 4 ACU to 32 ACU. I was looking at a table scan to show how the buffer pool is dynamically resized with auto-scaling. Here I’ll start to run this same cpu() procedure in one, then two, then tree… concurrent sessions to show auto-scaling and related metrics.

Aurora Serverless v2 (preview) – RAM

By Franck Pachot

.
What is Aurora Serverless? That’s the RDS Aurora name for auto-scaling: instead of provisioning an instance size (from the burstable db.t3.small with 2 vCPU and 2GB RAM to db.r5.16xlarge with 64 vCPU and 512 GB RAM) you define a range in term of ACU /Aurora Capacity Unit). ACU is about CPU + RAM. This blog post will focus on RAM.

Database announcements at re:Invent 2020

By Franck Pachot

.
This year is not very nice for conferences as everything is virtual and we miss the most important: meeting and sharing with people. But the AWS re:Invent is actually a great experience. As an AWS Data Heros, I received an Oculus Quest 2 to teleport to the virtual Neon City where we can meet and have fun in Virtual Reality (but incredibly real-life chatting):

DynamoDB Scan (and why 128.5 RCU?)

By Franck Pachot

.
In the previous post I described the PartiSQL SELECT for DynamoDB and mentioned that a SELECT without a WHERE clause on the partition key may result in a Scan, but the result is automatically paginated. This pagination, and the cost of a Scan, is something that may not be very clear from the documentation and I’ll show it here on the regular DynamoDB API. By not very clear, I think this is why many people in the AWS community fear that, with this new PartiQL API, there is a risk to full scan tables, consuming expensive RCUs. I was also misled, when I started to look at DynamoDB, by the AWS CLI “–no-paginate” option, as well as its “Consumed Capacity” always showing 128.5 even for very large scans. So those examples should, hopefully, clear out some doubts.

Cross-cloud PMM: which TCP ports to open

By Franck Pachot

.
I recently installed Percona Monitoring & Management on AWS (free tier) and here is how to monitor an instance on another cloud (OCI), in order to show which TCP port must be opened.

DynamoDB PartiQL – part II: SELECT

By Franck Pachot

.