aws

By Franck Pachot

.
I have written about some NoSQL myths in previous posts ( and here) and I got some feedback from people mentioning that the test case was on relatively small data. This is true. In order to understand how it works, we need to explain and trace the execution, and that is easier on a small test case. Once the algorithm is understood it is easy to infer how it scales. Then, if readers want to test it on huge data, they can. This may require lot of cloud credits, and I usually don’t feel the need to do this test for a blog post, especially when I include all the code to reproduce it on a larger scale.

overview

To continue on the UUID performance thread, I was recently asked by a customer how joins perform with various data types. I had not run a specific test, but suspected perform would be driven mostly by the size of the data types.

I wanted to verify my assumptions with real test data that shows the core performance of joins with CockroachDB.

the schema, data, and queries

For this test, two tables were created. The first table had one million rows and the second table had 200k matching primary keys for UUID, STRING, and INTEGER data types.

schema:

create table u1 (id uuid primary key);
create table u2 (id uuid primary key);

create table s1 (id string primary key);
create table s2 (id string primary key);

create table i1 (id integer primary key);
create table i2 (id integer primary key);

data load:

By Franck Pachot

.
I’ve written a blog post about serverless databases and here is an example of Amazon RDS Aurora PostgreSQL in serverless mode:

By Franck Pachot

.
When I’m writing about a product I like to be precise about the name, the upper and lower case, and even more: do you know that was taking special care of writing Oracle 12cR2 before then non-italic came with 18c? And that’s also the reason I’m not writing a lot about VMware as it takes me 5 minutes to put the uppercase right

• amazon
• aws
• cloud

By Franck Pachot

.
https://blog.dbi-services.com/wp-insides/uploads/sites/2/2020/09/IMG_201... 600w" sizes="(max-width: 300px) 100vw, 300px" />

By Franck Pachot

.
There are many NoSQL databases. And, because SQL is an ISO standard, “No SQL” also means “No Standard”. Many have a similar API and similar objects, but with completely different names. Today, NoSQL databases are used as an additional datastore for some well-defined use cases for which a hashed key-value store fits better than a relational table. And it quickly became “Not Only SQL” as it is complementary to RDBMS databases using SQL. But at the origin, the idea was to replace the RDBMS databases, refusing the SQL API, and then inventing a “No SQL” data store. When you want to replace something rather than proposing something new, you often adopt the same language to make it look similar. And this why, in my opinion we find some relational database terms like “Table” and “Index”. But they have a different meaning. Here is a dictionary where I try to explain the DynamoDB artifacts and differentiate from their Relational and SQL meaning.

By Franck Pachot

.
That’s common to any data structure, whether it is RDBMS or NoSQL, indexes are good to accelerate reads but slow the writes. This post explains the consequences of adding indexes in DynamoDB.

By Franck Pachot

.
DynamoDB is a cloud-native, managed, key-value proprietary database designed by AWS to handle massive throughput for large volume and high concurrency with a simple API.

By Franck Pachot

.
In The myth of NoSQL (vs. RDBMS) “joins dont scale” I explained that joins actually scale very well with an O(logN) on the input tables size, thanks to B*Tree index access, and can even be bounded by hash partitioning with local index, like in DynamoDB single-table design. Jonathan Lewis added a comment that, given the name of the tables (USERS and ORDERS). we should expect an increasing number of rows returned by the join.

In this post I’ll focus on this: how does it scale when index lookup has to read more and more rows. I’ll still use DynamoDB for the NoSQL example, and this time I’ll do the same in Oracle for the RDBMS example.

By Franck Pachot

.
J’essaie quelque chose de nouveau. Je publie beaucoup en anglais (blog, articles, présentations) mais cette fois quelque chose de 100% francophone. En sortant du confinement, on reprend les transports (train, voiture,…) et c’est l’occasion de se détendre en musique mais aussi de s’informer avec des podcasts. J’ai l’impression que c’est un format qui a de l’avenir: moins contraignant que regarder une video ou ou lire un article ou une newsletter. Alors je teste une plateforme 100% gratuite: Anchor (c’est un peu le ‘Medium’ du Podcast).