Distributed SQL For Dummies MariaDB Special

Edition Andrew C. Oliver & Ted Coombs pdf

download

https://ebookfinal.com/download/distributed-sql-for-dummies-
mariadb-special-edition-andrew-c-oliver-ted-coombs/

Explore and download more ebooks or textbooks

at ebookfinal.com
We have selected some products that you may be interested in
Click the link to download now or visit ebookfinal.com
for more options!.

Employer Branding For Dummies Glassdoor Special Edition

Garibaldi

https://ebookfinal.com/download/employer-branding-for-dummies-
glassdoor-special-edition-garibaldi/

Ransomware Defense For Dummies Cisco Special Edition

Lawrence Miller

https://ebookfinal.com/download/ransomware-defense-for-dummies-cisco-
special-edition-lawrence-miller/

Distributed Systems Principles and Paradigms Andrew S.

Tanenbaum

https://ebookfinal.com/download/distributed-systems-principles-and-
paradigms-andrew-s-tanenbaum/

Unified Analytics For Dummies Databricks Special Edition

Ulrika Jägare

https://ebookfinal.com/download/unified-analytics-for-dummies-
databricks-special-edition-ulrika-jagare/
Macs For Dummies 10th Edition For Dummies Computer Tech
Edward C. Baig

https://ebookfinal.com/download/macs-for-dummies-10th-edition-for-
dummies-computer-tech-edward-c-baig/

iPad For Dummies For Dummies Computer Tech 2nd Edition

Edward C. Baig

https://ebookfinal.com/download/ipad-for-dummies-for-dummies-computer-
tech-2nd-edition-edward-c-baig/

Mutual Fund Investing For Canadians For Dummies 1st

Edition Andrew Bell

https://ebookfinal.com/download/mutual-fund-investing-for-canadians-
for-dummies-1st-edition-andrew-bell/

Washington D C For Dummies Dummies Travel 4th Edition Tom

Price

https://ebookfinal.com/download/washington-d-c-for-dummies-dummies-
travel-4th-edition-tom-price/

CISSP for Dummies 6th Edition Lawrence C. Miller

https://ebookfinal.com/download/cissp-for-dummies-6th-edition-
lawrence-c-miller/
Distributed SQL For Dummies MariaDB Special Edition
Andrew C. Oliver & Ted Coombs Digital Instant
Download
Author(s): Andrew C. Oliver & Ted Coombs
ISBN(s): 9781394159796, 139415979X
File Details: PDF, 3.10 MB
Year: 2023
Language: english
These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Distributed
SQL
MariaDB Special Edition

by Andrew C. Oliver and

Ted Coombs

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Distributed SQL For Dummies®, MariaDB Special Edition

Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2023 by John Wiley & Sons, Inc.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without
the prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com,
Making Everything Easier, and related trade dress are trademarks or registered trademarks of
John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not
be used without written permission. MariaDB and the MariaDB logo are registered trademarks of
MariaDB. All other trademarks are the property of their respective owners. John Wiley & Sons,
Inc., is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: WHILE THE PUBLISHER AND AUTHORS HAVE

USED THEIR BEST EFFORTS IN PREPARING THIS WORK, THEY MAKE NO REPRESENTATIONS
OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF
THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES REPRESENTATIVES, WRITTEN
SALES MATERIALS OR PROMOTIONAL STATEMENTS FOR THIS WORK. THE FACT THAT AN
ORGANIZATION, WEBSITE, OR PRODUCT IS REFERRED TO IN THIS WORK AS A CITATION AND/
OR POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE PUBLISHER
AND AUTHORS ENDORSE THE INFORMATION OR SERVICES THE ORGANIZATION, WEBSITE, OR
PRODUCT MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. THIS WORK IS SOLD WITH
THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING PROFESSIONAL
SERVICES. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR
YOUR SITUATION. YOU SHOULD CONSULT WITH A SPECIALIST WHERE APPROPRIATE. FURTHER,
READERS SHOULD BE AWARE THAT WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED
OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.
NEITHER THE PUBLISHER NOR AUTHORS SHALL BE LIABLE FOR ANY LOSS OF PROFIT OR ANY
OTHER COMMERCIAL DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, INCIDENTAL,
CONSEQUENTIAL, OR OTHER DAMAGES.

For general information on our other products and services, or how to create a custom For
Dummies book for your business or organization, please contact our Business Development
Department in the U.S. at 877-409-4177, contact info@dummies.biz, or visit www.wiley.com/
go/custompub. For information about licensing the For Dummies brand for products or services,
contact BrandedRights&Licenses@Wiley.com.
ISBN: 978-1-394-15978-9 (pbk); ISBN: 978-1-394-15979-6 (ebk). Some blank pages in the
print version may not be included in the ePDF version.

Publisher’s Acknowledgments

Some of the people who helped bring this book to market include the
following:
Project Manager: Client Account Manager:
Carrie Burchfield-Leighton Jeremith Coward
Sr. Managing Editor: Rev Mengle Special Help: Patrick Bossman,
Managing Editor: Camille Graves Lewis Carr, Alejandro Duarte

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Table of Contents
INTRODUCTION................................................................................................ 1
About This Book.................................................................................... 1
Icons Used in This Book........................................................................ 2
Conventions Used In This Book........................................................... 2
Beyond the Book................................................................................... 2

CHAPTER 1: Getting to Know Distributed SQL.................................... 3

Understanding the Need for Distributed SQL................................... 3
Managing scale................................................................................. 4
Scaling with sharding....................................................................... 5
Evaluating Existing Client-Server Options.......................................... 6
Single writer multiple replicas........................................................ 7
Multiple writer system..................................................................... 7
Standby instance.............................................................................. 8
Asynchronous replication............................................................... 8
Introducing Distributed SQL................................................................ 8
Writing to a distributed SQL database.......................................... 9
Scalability and availability in a distributed SQL database........... 9
Indexing with Xpand...................................................................... 10
Balancing the load with Xpand..................................................... 11
Shared nothing architecture........................................................ 11
Understanding Distributed SQL Topographies............................... 12
Disaster recovery........................................................................... 12
Alternatives to distributed SQL.................................................... 13

CHAPTER 2: Distributed SQL in the Real World................................ 15

Technical Use Cases............................................................................ 15
Ecommerce Use Cases........................................................................ 16
Finance Use Cases............................................................................... 16
IoT and Manufacturing Use Cases.................................................... 17
Gaming Use Cases............................................................................... 18

CHAPTER 3: Getting Started with Distributed SQL........................ 19

Deciding on the Right Solution.......................................................... 19
Hosting on-premises..................................................................... 20
Cloud hosting................................................................................. 20
Using the Docker Instance of Xpand................................................. 21
Activate Xpand by Deploying with SkySQL....................................... 21

Table of Contents iii

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Crafting the Perfect Schema.............................................................. 23
Keys and slices............................................................................... 23
Tables big and small...................................................................... 25
REPLICAS=ALLNODES.................................................................... 26
Range queries................................................................................. 27
JSON................................................................................................. 28

CHAPTER 4: Creating Distributed SQL Applications..................... 29

Java........................................................................................................ 31
Creating the main application...................................................... 33
Running the application................................................................ 35
JavaScript.............................................................................................. 36
Creating the main application...................................................... 36
Running the application................................................................ 38
Python................................................................................................... 39
Creating the main application...................................................... 39
Running the application................................................................ 42

CHAPTER 5: Deciding if Distributed SQL Is Right for You......... 43

Determining When Distributed SQL Isn’t the Answer..................... 43
Exploring Why You May Need Distributed SQL............................... 44

CHAPTER 6: Ten Tips for Success with Distributed

SQL Applications......................................................................... 47
Load Data in Parallel........................................................................... 47
Disable the Rebalancer....................................................................... 48
Apply Concurrency When Load Testing............................................ 48
Use MaxScale for Load Balancing..................................................... 48
Use AUTO_UNIQUE to Generate Unique Keys................................. 49
Use Columnar Indexes to Increase Aggregation and
Analytical Query Efficiency................................................................. 49
Use Parallel Replication for Multiple Regions.................................. 50
Use SkySQL for Simplicity................................................................... 50
Add Nodes for More Performance.................................................... 51
Use MariaDB Support......................................................................... 51

iv Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Introduction
D
istributed SQL is a relatively new technology that provides a
modern way to scale large databases while maintaining ACID-
level consistency, high availability, and disaster ­recovery. In
database systems, ACID (atomicity, consistency, ­isolation, ­durability)
refers to a standard set of properties that ­guarantees database trans-
actions are reliably processed. Other ­scaling solutions for large data-
bases such as NoSQL don’t allow for the same ­consistency and ease
of querying with industry-standard SQL.

Xpand, the distributed SQL database from MariaDB, gives you

cloud-level scalability while lowering the work your data team
needs to perform in managing a growing database. In this book,
you discover where distributed SQL fits among other scaling
methods and how it’s an improvement over methods such as
sharding that require skill and manhours to maintain.

Automated balancing data across nodes eliminates hotspots, or

overworked nodes, common in sharding methods of scaling. The
built-in rebalancer continuously balances the data across nodes by
using a unique indexing scheme to assure that data is organized in
a way that distributes read-and-write loads between nodes.

Maintaining slices of data distributed among the nodes provides a

powerful method of fault tolerance. You can lose a node, and the
system simply redistributes data among the existing nodes, rely-
ing on replicated slices on the remaining nodes.

Use distributed SQL in the cloud with SkySQL and allow your
database to take advantage of the cloud-centric architecture that
makes adding nodes simple and inexpensive. SkySQL allows for
simple distributed SQL database management in a powerful and
secure web client.

About This Book

This book is an introduction to a new and modern way of scaling
large databases. This important resource for data and IT profes-
sionals, developers, and IT managers helps you understand the
basic principles of using distributed SQL and acts as a guide for
developers to get started quickly using many of the commonly
used application development languages.

Introduction 1

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Icons Used in This Book
Like most For Dummies books, you’ll find some icons in the mar-
gins that help you spot important information highlighted in this
book. Here is what they mean:

The Tip icon points out helpful information. This content may
help you save time or money.

The Remember icon marks particular information that you may

want to file away for later use or help you recall important details
at a later date.

The Technical Stuff icon points out bits of information of a more

technical nature. Depending on your level of expertise, you may
want to skip these points.

The Warning icon alerts you to information that may save you
from making decisions that are harmful or helps you avoid pitfalls.

Conventions Used In This Book

A book like this is not as wide as a computer screen. When you see
this character — ↩ — it means the line of code is too long and
carries over to the next line.

Beyond the Book

Entire volumes could be written about the topics covered in this
small book, so if you want information beyond what this book
offers, check out these additional resources:

»» mariadb.com/products/enterprise/xpand
»» mariadb.com/docs/products/mariadb-xpand
»» mariadb.com/products/skysql

2 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Recognizing the need for distributed SQL

»» Looking into client-server options

»» Introducing distributed SQL

»» Getting to know distributed SQL

topologies

Chapter 1
Getting to Know
Distributed SQL

C
lient-server databases such as Oracle, PostgreSQL, Microsoft
SQL Server, MySQL, and MariaDB were originally designed to
handle smaller data sets at lower throughput and scale.
Increasing scale or throughput requires the capability of a single
machine. These databases now achieve high availability by replicat-
ing the entire database to more machines. NoSQL databases such as
Cassandra and MongoDB focused on scale but with reduced capa-
bilities, especially with regards to joins, transactional integrity, and
SQL — the most ­popular standard query language. This chapter
explains how ­distributed SQL addresses scale, integrity, and availa-
bility while maintaining the feature set of a full relational database.

Understanding the Need for

Distributed SQL
This section provides an overview of some of the methods of
achieving high availability (HA) and scalability. HA and s
­ calability
don’t always achieve the same thing. You discover how HA is
achieved by using distributed SQL databases and how to best
design a highly available system that best meets your needs.

CHAPTER 1 Getting to Know Distributed SQL 3

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Managing scale
Scaling a database requires potentially handling multiple issues:

»» The overall size of the database: Even with attached

storage managing, querying or writing a large database
requires more resources in terms of memory and compute.
»» Managing a lot of client traffic in terms of reads: This
requires more network and compute just to manage client
connections and traffic in addition to the memory to handle
read operations.
»» Managing writes: Writes are more difficult to manage than
reads because they must be consistent across any copies.
This makes scaling writes more difficult. In addition to scale,
most high-traffic databases are also required to be highly
available and minimize downtime.

Distributed SQL databases manage scale not by adding more CPU,

memory, or network resources to a single machine, but by slic-
ing up the database and dividing it automatically among multiple
machines. This enables

»» Larger database sizes

»» Faster read-throughput under load
»» Higher write volume
Think of it this way. If you were moving from one home to another,
you have to move all your stuff. All your friends agree to help you
move. You could rent one giant moving truck and load your fur-
niture into it, or you could rent a lot of smaller trucks. While the
large truck may use less fuel than several smaller trucks, your
friends step on each other loading the truck bed — meaning they
contend for resources. With the smaller trucks, you could have
each of your friends load one truck by themselves and drive to the
new place and unload it. The smaller trucks allow more work to
be done in parallel. The only catch is there is more coordination
required — overhead in dividing the work and directing it to the
right place.

If you have a small apartment and not a lot of stuff, the

­single-moving truck method is probably the best. It uses less fuel,
requires less coordination and you’ll probably get done quicker.

4 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 What if you have a house on the scale of the Winchester Mansion
(160 rooms)? In that case, you may not even be able to rent a big
enough moving truck! Renting a lot of smaller ones with more
help is the only feasible method of handling that much load.

The difference between the analogy of trucks and computers is

that until the advent of the cloud there wasn’t an easy way to rent
the small trucks let alone the larger trucks. Cloud has created a
flexible business model for computer rental that enables you to
easily rent a very large truck or more than one truck and coordi-
nate them with ease.

This is also the case with databases. Smaller loads may do bet-
ter with a traditional client-server database such as MariaDB
Server, but larger loads with more traffic are probably better with
MariaDB Xpand, a distributed SQL database. Using Xpand in the
Cloud makes it possible for workloads to be rapidly and affordably
scaled, including across regions and globally.

Scale is the one reason to use a distributed database, but it’s not
the only reason. Availability is another. The one thing computing
can guarantee is that things will break. Faults can happen on a
single machine, network device, or even the powerlines that feed
them. For modern services, especially on the scale of a large bank
or SaaS company, losing service for any period of time is unthink-
able. Distributed SQL databases store redundant copies of data on
additional machines in additional locations (such as cloud avail-
ability zones).

Scaling with sharding

Distributed SQL isn’t the only way to scale. One of the ways
larger databases have been supported is by sharding MariaDB and
MySQL databases. This is a method by which databases are par-
titioned and distributed across multiple machines. The smaller
pieces allow queries and writes to use more resources. While this
allows databases to scale, it introduces new problems, such as
complexity, difficulty querying, and application specificity.

When a system needs a larger database size, or better read/write

performance, you can split tables based on values in a column —
for example, creating a database partition built on customers
based on zip code ranges or on customers’ last names alphabeti-
cally. This is known as sharding.

CHAPTER 1 Getting to Know Distributed SQL 5

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Some databases, such as Oracle, can automatically partition a
database on these values. Other databases may require application
developers to manually divide the data. While sharding is a good
way to share resources, the partitions must also be replicated to
ensure availability.

Sharding isn’t the optimal way to meet increasing demand. Archi-

tecting and maintaining shards requires ongoing human effort
and makes an application brittle. Unless your business has suf-
ficient engineering resources to apply outside your core area of
business expertise, a different solution is needed.

Query performance may suffer in a partitioned system because

data must be rejoined in queries that cross partitions. A problem
with sharding techniques is hotspots, where more traffic goes to
one node than another because of the uneven nature of how the
data is partitioned. For example, if you’re partitioning on last
name, more Smiths exist than Chadwicks.

Sharding isn’t used for availability; it’s used for scalability but is
sometimes used along with high availability techniques to allow
for larger database sizes. When you’re choosing a method for high
availability, decide which tradeoffs, such as risk, performance,
and complexity, that you can live with. When making your deci-
sion, you should also take into consideration feasibility issues like
data size and network topography.

Evaluating Existing Client-Server Options

You may already be using some of the methods we discuss in this
section to achieve high availability. Each method is discussed
to help you determine which is best suited for your system by
weighing the drawbacks of each.

Older books and documentation may use terms like master to

refer to database nodes that do writes, slave for read replicas, and
multi-master for database systems with multiple writer nodes.
The industry is transitioning away from these terms now because
they’re offensive and inaccurate.

In this book, we use primary or writer and replica or read node.

6 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Single writer multiple replicas
When traditional databases such as Microsoft SQL Server, MySQL,
or MariaDB Server need to handle heavy read with fewer write
operations, it’s common to configure a cluster where one node
handles the writes while reads are directed to other nodes. Often,
writes are handled synchronously, meaning all read replicas must
complete updates before a write transaction commits. As long as
an application client isn’t interested in a new or updated row,
they won’t have to wait. Any client interested in a row locked
in the transaction may block until the transaction commits.
Because this blocking occurs until all replicas acknowledge the
update, it may take longer than on a single-instance database.

Database sizes are limited in a single writer multiple replica setup

because a copy of all data exists on every single node. A fault-­
tolerance downside of this method is that when a primary instance
fails, writes aren’t possible. A way around this is to employ a
database proxy such as MariaDB MaxScale, where a read replica
can be promoted to become the new primary instance and assume
responsibility for writes.

Systems that fit on a single node without splitting the data are
extremely economical and efficient. Replicas give you high availa-
bility and read-scale but don’t work well in systems where a large
number of write operations exist or the data set grows too large.

Multiple writer system

For traditional databases such as Oracle or MySQL, which need
HA specifically for writes, a multi-primary system is often used.
This type of system strictly provides HA but not scalability. Every
write is sent to every writer node. When two primary nodes exist,
the write performance is less than a single-node system because
writes have to be written to both nodes and coordinated. It’s
fault-tolerant because if a write node goes down, the other takes
over its responsibilities.

You achieve an advantage over a single writer system with mul-

tiple replicas because of lower failover time. A multiple writer
system configuration can be combined with other techniques
although the complexity of such a system normally requires addi-
tional hardware or software.

CHAPTER 1 Getting to Know Distributed SQL 7

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Standby instance
Using a synchronously replicated standby instance is a variation
of a multiple-writer system. Instead of having writes go to two
(or more) nodes and replicate to each node, writes go to one node,
and a copy is sent to a standby node. If the primary goes down, the
standby becomes the new primary.

The advantage of a standby instance is that it’s simpler to oper-

ate, and there’s no chance of a transaction collision, which is con-
flicting writes occurring on two nodes, both attempting to lock
similar data. Standby instances are strictly for availability and
offer no performance advantage over a single-node system. In
fact, there is some overhead to assure consistency between the
primary and standby nodes.

Asynchronous replication
The other methods we talk about in this section assume that
absolute transactional integrity is required with no chance of data
loss during failures. For some data sets, performance is more
important than transactional integrity. It’s possible to config-
ure replicas with lower levels of assurance than full transactional
acknowledgment. In these cases, your system may be okay with
simply receiving a message that the data was sent or received
instead of waiting for the data to be committed.

Introducing Distributed SQL

Distributed SQL is a database that slices and distributes data and
indexes across multiple nodes to achieve read and write scale and
maintain availability. In this way, the data, writes, and reads are
spread evenly throughout the cluster.

Most distributed SQL databases are compatible with MySQL and

MariaDB or PostgreSQL but operate differently. Tables are auto-
matically partitioned into multiple slices. In MariaDB Xpand,
rows are assigned to slices based on a hash of a subset of their
columns (the primary key by default in Xpand). Figure 1-1 shows
how those slices are then distributed to multiple nodes in the
cluster. Each slice has at least one copy, called a replica, which
exists on a separate node from the original copy.

8 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 FIGURE 1-1: Every slice has a replica on one of the other nodes.

Writing to a distributed SQL database

When data is written to a distributed SQL database, the write is for-
warded to each node to which that row of data is assigned. Multiple
writes are handled concurrently. When the transaction commits,
writes are coordinated with the replica (or replicas) of that slice.
When queries are executed, the system automatically determines
which nodes contain the slices of data being requested and distrib-
utes the query work across the cluster.

Scalability and availability in a

distributed SQL database
Distributed SQL databases achieve scalability through distribut-
ing data and work across the cluster. They achieve availability by
ensuring there’s an additional copy of each slice stored some-
where in the cluster. For cloud environments, the replicas are
usually divided across separate availability zones (AZs). If a node
fails, the writes and reads are directed to another node with the
necessary replica. During failover a new copy of the slices on the
dead node is created and redistributed across the cluster. If a node
recovers, the data is redistributed among the nodes.

Availability zone is a term used by cloud service providers to refer

to a separate data center located in the same region. Software is
often aware of AZs and ensures that redundant copies are stored
in separate AZs as opposed to two replicas stored in the same
AZ. Older documentation uses the term rack aware to refer to the
same technical concept.

Distributed SQL achieves better distribution of load than other

sharding/partitioning schemes because data is algorithmically
assigned to slices via hash values, shown in Figure 1-2, and is
distributed evenly across the cluster.

CHAPTER 1 Getting to Know Distributed SQL 9

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 FIGURE 1-2: Data is assigned to slices using a hash value for even distribution.

Like sharding schemes, hotspots can occur. To combat hotspots,

distributed SQL systems detect them and either rerank the rep-
licas (changing the primary) or move the slice to another node.
These distributed SQL systems are superior to other ­single-writer
and multi-writer systems in the following ways:

»» Single-writer systems with multiple replicas because writes

are also distributed and perform better
»» Multi-writer systems because both reads and writes are
distributed and across more nodes

A single node system will usually perform better than a distrib-

uted SQL database for a single small transaction on a system not
under load because of the overhead involved in distributing reads
and writes. Execution of a single simple query may also be bet-
ter on non-distributed databases because of the cost of gathering
data from multiple nodes especially when using joins. Distributed
databases outperform non-distributed databases with high scale
data volume or throughput.

Indexing with Xpand

Unlike older databases where each node had its own siloed index,
Xpand indexes enable you to find query matches across multiple
nodes. This way, queries no longer need be run across every node,
only those with matching data.

Distributing the work of queries across multiple nodes and only

those with the appropriate data increases performance and
scalability.

10 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Balancing the load with Xpand
Distributed SQL databases use different methods to balance the
load across the nodes by detecting when a node is overused and
responds by moving the data to even out the load. In addition to
traditional load balancing reads and writes, MariaDB redistrib-
utes data when a node gets too busy by using one of the following
methods:

»» Rerank the replicas changing which nodes are assigned

reads for a particular slice.
»» Move the slice to a different node.
»» Reslice the data so it’s distributed across additional nodes.
The data distribution spreads writes, reads, and queries across the
cluster of nodes for greater performance and availability. Xpand
stores data redundantly on multiple nodes and can ensure data
is replicated across multiple AZs. Xpand also automatically re-
protects data if a node or zone fails.

Traditional replication techniques don’t scale reads, only writes.

Shared nothing architecture

Distributed SQL systems are usually shared-nothing architec-
tures that scale linearly. For a large database, or for a system of
scale, performance under load will be higher in a distributed SQL
system. From an availability standpoint, distributed SQL data-
bases can be configured to ensure there are as many (or more)
replicas as there are AZs. This performance is generally superior
to what’s achieved with standbys or multi-writer systems. Check
out ­Figure 1-3 to see how rebalancing is automatic.

FIGURE 1-3: When there is a node fault, rebalancing is automatic.

CHAPTER 1 Getting to Know Distributed SQL 11

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Understanding Distributed SQL
Topographies
When deciding how to deploy a distributed SQL database, consider
the following:

»» How much fault-tolerance do you need?

»» How many AZs does your region offer?
»» What kind of disaster recovery should your database
support?

Most distributed SQL databases support defining how many rep-

licas of each slice should be created. Fault tolerance requires at
least two. Most users configure replicas to two; some use three
for increased fault tolerance. Replicas can be configured to ensure
redundant nodes are distributed across AZs. There must be the
same number of nodes in each zone or an error occurs, as shown
in Figure 1-4.

FIGURE 1-4: A fault based on an unequal number of nodes.

In MariaDB Xpand, you can add a node to a zone with the follow-
ing code:

ALTER CLUSTER nodeid [, nodeid] ... ZONE zone

Disaster recovery
For disaster recovery, some distributed SQL databases support
synchronous replication between regions. Synchronous replica-
tion delivers recovery point objective — zero data loss. It is true
there is severe write performance penalties. So many systems use
highly efficient parallel replication combined with regular back-
ups. In the event of a disaster, the application can failover to a
different geographic region.

12 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 MariaDB Xpand supports parallel asynchronous replication as
well as parallel backup. These capabilities use multiple nodes in
the cluster to replicate data. This capability is essential for high
throughput systems that need frequent backups or those that
replicate to a disaster recovery region.

Alternatives to distributed SQL

Oracle RAC and Oracle Clusterware combine multiple techniques,
including partitioning in an automated system. Copies of data are
moved across the cluster and ownership is transferred based on
the workload. Compared with distributed SQL, it’s a more com-
plicated system that achieves some of the same results but at a
higher price point.

WHAT ABOUT AMAZON RDS,

AMAZON AURORA, AND GOOGLE
ALLOY?
Amazon RDS is a system for deploying Oracle, MySQL, MariaDB, and
PostgreSQL on Amazon Web Services. It can configure a single writer
with standby instances as well as multiple replicas. It uses Amazon
EBS (a shared/distributed storage architecture) in order to achieve
higher performance.

Amazon Aurora deploys instances of MySQL or PostgreSQL with

multi-writer and/or replica systems. Amazon makes changes to
MySQL and PostgreSQL to move more database functionality to
Amazon’s proprietary EBS storage system to achieve higher
performance.

Google Alloy deploys instances of PostgreSQL. It’s a similar architec-

ture to Amazon Aurora but with capabilities specific to Google Cloud.

CHAPTER 1 Getting to Know Distributed SQL 13

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Understanding when distributed SQL
is used

»» Look into technical use cases

»» Examining specific industry use cases

Chapter 2
Distributed SQL in
the Real World

D
istributed SQL is used for systems of record at high scale
with high availability. Many use cases in many industries
have these requirements. In this chapter, you look at a few
of those use cases across multiple industries.

Technical Use Cases

Distributed SQL has many uses but some of the technical ones
provide high availability in critical systems such as those used to
log in, authorize, and authenticate. Applications have ­historically
used protocols like Lightweight Directory Access ­ Protocol
(LDAP) to query user databases such as Active Directory for
­authentication and authorization. These work for many i­nternal
business needs but tend not to scale to requirements such as those
in ­Software-as-a-Service (SaaS) applications, Internet of Things
applications, or consumer facing services.

Distributed SQL to the rescue. High availability and scalability

enable rapid user registration, authentication, and authorization,
all critical to the end-user to get things done.

CHAPTER 2 Distributed SQL in the Real World 15

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Discovering Diverse Content Through
Random Scribd Documents
CATHEDRAL: SPANDRIL OF CENTRAL GATE. THE LAST JUDGMENT.
LEON.

PLATE 29
CATHEDRAL: SPANDRIL OF CENTRAL GATE. THE LAST JUDGMENT.
LEON.

PLATE 30
CATHEDRAL: DETAIL OF THE RIGHT GATE.
LEON.
 PLATE 31

CATHEDRAL: DETAIL OF THE GATE OF THE CHAPEL OF SAN ANDRÉS.

LEON.

PLATE 32
CATHEDRAL: VARIOUS STATUES FROM THE CROSS AISLE.
LEON.

PLATE 33
CATHEDRAL: DETAIL OF THE RIGHT-HAND PORTICO.
LEON.
 PLATE 34

CATHEDRAL: THE BACK OF THE CHOIR.

LEON.

PLATE 35
CATHEDRAL: THE CHOIR STALLS.
 LEON.

PLATE 36

CATHEDRAL: THE CHOIR STALLS.

LEON.

PLATE 37
CATHEDRAL: DETAIL OF THE CHOIR.
LEON.

PLATE 38
CATHEDRAL: CHOIR STALLS. THE GUARDIAN ANGEL OF PARADISE, AND
THE ARCHANGEL ST. MICHAEL.
LEON.

PLATE 39
CATHEDRAL: CHOIR STALLS. NOAH, ADAM AND EVE.
LEON.

PLATE 40
CATHEDRAL: CHOIR STALLS. THE ARCHANGEL GABRIEL AND ABRAHAM.
LEON.
PLATE 41
CATHEDRAL: CHOIR STALLS. ISAAC AND JACOB.
LEON.

PLATE 42
CATHEDRAL: CHOIR STALLS. ESAU.
LEON.

PLATE 43
CATHEDRAL: CHOIR STALLS. SAMSON.
LEON.

PLATE 44
CATHEDRAL: CHOIR STALLS. ST. MATHIAS AND ST. MARK.
LEON.

PLATE 45
CATHEDRAL: CHOIR STALLS. ST. LUKE AND ST. BARTHOLOMEW.
LEON.
PLATE 46
CATHEDRAL: CHOIR STALLS. ST. ANDREW AND ST. PETER.
LEON.

PLATE 47
CATHEDRAL: CHOIR STALLS. SANTIAGO ALFEO AND ST. PHILIP.
LEON.

PLATE 48
CATHEDRAL: CHOIR STALLS. ST. JOHN THE EVANGELIST AND SANTIAGO.
LEON.
PLATE 49
CATHEDRAL: CHOIR STALLS. SAINT MARY MAGDALENE AND SANTO
DOMINGO.
LEON.

PLATE 50
CATHEDRAL: IN THE CHOIR. ST. NICODEMUS AND VALOUR.
LEON.

PLATE 51
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookfinal.com