Visit https://ebookfinal.

com to download the full version and

explore more ebooks

Distributed SQL For Dummies MariaDB Special

Edition Andrew C. Oliver & Ted Coombs

_____ Click the link below to download _____

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

Explore and download more ebooks at ebookfinal.com

Here are some suggested products you might be interested in.
Click the link to download

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 [email protected], or visit www.wiley.com/
go/custompub. For information about licensing the For Dummies brand for products or services,
contact BrandedRights&[email protected].
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.
 Ecommerce Use Cases
Ecommerce handles an incredible amount of data. Some tables
tend not to change often but must be able to handle a great many
read operations. Additionally, transactionally intense operations,
such as purchasing, require high availability and scalability.

Ecommerce is a perfect fit for the strengths of distributed

SQL. These strengths include the capability to handle high data
load, number of users, and transactional integrity.

Lookup tables such as product catalog data, particularly if they’re

small data sets, can be copied in their entirety to all the nodes.

Some catalogs use semi-structured data types. When this data

no longer fits neatly into tables, you can use JSON fields. JSON
gives you similar flexibility in storing unstructured data offered
by NoSQL databases, but with the strengths of using a relational
SQL database.

In today’s ecommerce, up-to-date pricing information is critical

and sourced from many systems, even crawling other ecommerce
sites leading to a high number of transactions. These potentially
large data sets are also the subject of real-time analytical queries.
Unlike other distributed SQL databases, MariaDB Xpand provides
a columnar index that increases the speed of range and analytical
queries.

Finance Use Cases

Financial Services companies are early adopters of distributed
SQL technology to handle their high-throughput read and write
transactions, large data sets, and zero downtime requirements.
Typical financial data sets are ledgers that include financial
trading systems such as those used in buying and selling stock
to cryptocurrency. These systems often include the anti-fraud,
Know Your Customer (KYC) systems where an additional feed is
sent in real-time to counter fraud. In these cases, transactional
integrity and ability to serve as a system of record is critical. Sys-
tems such as these require efficient range queries and real-time
analytical queries.

16 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IoT and Manufacturing Use Cases
There are a multitude of uses for distributed SQL in the Internet
of Things (IoT) use cases found in manufacturing, energy explo-
ration, power generation and distribution, and transportation and
logistics systems. Data from sensors and asset tracking require a
high number of write operations and fewer read operations. These
data sets are commonly accessed by range queries.

JSON is the field type of choice for semi-structured data, common

in sensor data and shop floor control systems.

Device information tracking is common in electric companies and

smart grids. These were the original IoT. These complex systems
track everything from the meter to the transformer, often wire-
lessly, and reconfigure the network based on system conditions in
real-time. Telemetry data from these devices is write-heavy and
control systems rely on range queries to determine both current
and past network status for system analysis and troubleshooting
out-of-range conditions.

Another example of transaction-heavy applications are call data

record systems of telecommunication networks. These records
are used in customer billing and communications ­ network
­analysis. Due to the billions of cellular ­customers, these trans­
actions are high volume and write-intensive. ­Furthermore, they
must be processed in near-real-time. ­Telecommunications net-
works must be highly available and be able to handle an incred-
ible number of write operations. Read operations aren’t as
intensive.

Like telecommunication networks, smart networks also generate

mountains of data for network reconfiguration and data security.
5G networks in particular act like smart grids and process data
in real time. One of the issues with networks distributed across
a wide area is latency. Your application may need to process data
in real time as well as at the edge of the network closer to your
clients.

CHAPTER 2 Distributed SQL in the Real World 17

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Gaming Use Cases
Gaming is a serious and large business worldwide. Games require
low latency and can involve massive amounts of data coming in at
high throughput. Distributed SQL allows games to handle a lot of
concurrent reads and updates and ensure that the system is avail-
able globally at all hours of the day and night.

Distributed SQL database systems can handle multiple zone fail-

ures without a loss of availability.

Games require storing security information, handling login and

authorization. Beyond that they have a lot of reference data
(cards, player types, roles, game pieces) that may need to be rep-
licated to every node and joined against player data. Ultimately,
games revolve around players, their actions, and objectives. Each
of these results in data being read, stored, or updated, meaning
high read and write throughput.

18 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
»» Deciding whether to cloud host

»» Using Docker

»» Deploying with SkySQL

»» Designing the ideal schema

Chapter 3
Getting Started with
Distributed SQL

S
electing the correct deployment model and designing proper
schemas optimize your use of a distributed SQL database
and your investment of time and resources. This chapter
looks at reasons to deploy on-premises or in the cloud. It also
describes how to craft schemas, including the key field necessary
to ensure proper data distribution and other issues particular to
distributed databases.

Deciding on the Right Solution

Distributed SQL is a good solution for applications and services that
require absolute availability with read and write scale (check out
Chapter 1 for more info on why and Chapter 2 for where it matters).
MariaDB Xpand also includes columnar indexes that make opera-
tional analytics and ad hoc queries work efficiently, making dis-
tributed SQL a good choice for even more use cases. However, after
a team decides to use distributed SQL, it must also choose a deploy-
ment model and location.

Many distributed SQL databases are available on-premises or

in the cloud. When deciding on a cloud solution, a team must

CHAPTER 3 Getting Started with Distributed SQL 19

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 also decide if it wants to host the solution itself or purchase a
­database-as-a-service solution. This decision is based on whether

»» Requirements necessitate an on-premises solution

»» Your organization has recently procured suitable
infrastructure
»» Requirements can’t be met using a vendor-hosted solution
»» Overall cost considerations
»» Your team has sufficient expertise to care for and maintain a
distributed database

Hosting on-premises
Hosting on-premises allows a team more flexibility in terms of
how a system is set up, which resources it’s assigned, if it can
meet specific regulatory requirements. Occasionally, on-premises
systems are used due to more stringent latency or data sovereignty
requirements or because, in an industry like manufacturing, the
system is as reliable as the shopfloor systems. However, on-
premises systems must ensure that adequate backup and upgrade
procedures are in place. Additionally, it’s important to make sure
that there are sufficient zones or protections for redundancy. For
instance, you can use separate racks or ideally a separate building
with sufficient isolated resources.

Choosing to host on-premises comes with the added burdens of

installation, configuration, management, and continued moni-
toring of the infrastructure and DBMS. You may also need to
purchase additional hardware and software, undertake extensive
capacity planning, and plan, build, and secure the physical data
center.

Cloud hosting
Self-hosting a distributed database in the cloud allows for more
flexibility but also allows the database to grow and shrink as
needed. Instead of procuring more infrastructure than needed,
the organization can use pay as you go. However, it still requires
some of the same expertise as well as backup and upgrade proce-
dures. But, it’s easier to ensure deployment in separate availabil-
ity zones, and many of the redundancies the system would need
are built into the cloud infrastructure.

20 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 A database-as-a-service deployment is much simpler than on-
premises or self-hosted and will generally follow best practices
for that particular database. In the case of MariaDB Xpand, data-
bases can be deployed to AWS and Google Cloud using MariaDB’s
database-as-a-service system called SkySQL. SkySQL allows you
to manage many aspects of your database system, including sys-
tem upgrades.

SkySQL has multiple security certifications including SOC 2 Type

II, which can alleviate compliance concerns. With SkySQL, orga-
nizations can allow MariaDB to take care of backup and upgrade
procedures and even use MariaDB’s staff as adjunct database
administrators for query tuning and other concerns.

While database-as-a-service deployment is much easier, the

drawback is losing some degree of control and flexibility because
many offerings provide one-size-fits-all or limited options for
configurations, scaling, and types of availability.

Using the Docker Instance of Xpand

The MariaDB Xpand docker image is a convenient way to get
started and familiar with Xpand. The docker image is a single
node Xpand and isn’t appropriate for performance or production
use, but it’s ideal as a development and learning sandbox. It’s also
excellent for compatibility testing of existing applications. When
you’re ready to try a full cluster, you could deploy using SkySQL
or initiate a trial.

To discover more, visit mariadb.com/downloads/community/

xpand.

Activate Xpand by Deploying

with SkySQL
You can use MariaDB SkySQL to deploy Xpand in just a few steps:

1. Create a SkySQL account.

Visit the SkySQL official website at https://cloud.mariadb.
com and register for a MariaDB ID and account.

CHAPTER 3 Getting Started with Distributed SQL 21

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 2. Start services.
After you register an account, click Access SkySQL.
3. Click Launch New Service, choose the Xpand Distributed
SQL topology, and then you can select options for cloud
provider, instance size, and storage size.
For this case, Figure 3-1 shows the 3-node option, but there
are 1-, 3-, or 6-node options to choose from in the panel.

FIGURE 3-1: View your service details in SkySQL.

4. Click Security Access and add your own IP so you can

access it from your own device.

After you set up your account to deploy Xpand, you have a couple
of connection options:

»» Connect via Command Line Interface (CLI). Click Connect

to Service, download the certificate, and follow the instruc-
tions on screen. You’re connected to MariaDB Xpand server.
»» Connect via DBeaver. Similar to other options, you fill in the
information for host, port, user, password, and path to the
certificate authority. In DBeaver, you do that through the
graphical user interface (GUI).

Most options are in the Main tab in the Connection Setting screen,
as shown in Figure 3-2. The path to the CA certificate is in the
SSL tab.

22 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 3-2: The database connection detail dialog box.

Crafting the Perfect Schema

Schemas define the fields and data formats that comprise tables
within your database. Schemas are composed primarily of

»» The definitions of tables

»» The primary keys that define a unique row in the table
»» The foreign key that relates two tables
»» The indexes that ensure queries run efficiently
In a distributed database, you also have an additional distribution
key that helps determine how tables and indexes are distributed
throughout the cluster.

This section overviews how to construct keys and slices with a

distributed SQL database, including with mixed data such as JSON.

Keys and slices

Traditional relational databases often use autoincrement fields
or database sequences to create a surrogate primary key. These

CHAPTER 3 Getting Started with Distributed SQL 23

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 aren’t efficient on even high-traffic, client-server databases but
are a bigger problem on a high-scale distributed database. The
performance issue is the database must synchronize threads in
order to assure monotonically incremental values. In order to
work around this, some developers have used BINARY(16) fields
and generated universally unique identifiers (UUIDs). These avoid
the issue of thread synchronization with an extremely low risk
of duplicates, but because UUIDs fill the keyspace randomly at a
distance, they index poorly.

MariaDB Xpand offers AUTO_UNIQUE and AUTO_­INCREMENT.

AUTO_UNIQUE outperforms AUTO_­INCREMENT. ­AUTO_INCRE-
MENT guarantees rows get keys incremented by one in exactly the
order they’re inserted. AUTO_UNIQUE generates unique values
but doesn’t guarantee sequential order. Unlike generated random
UUIIDs, the keys generated by AUTO_UNIQUE are close together
and index well.

AUTO_UNIQUE can be used to create a unique key when a table’s

primary key isn’t available. Each value generated by the data-
base is guaranteed to be unique. AUTO_UNIQUE looks a lot like
a sequence but doesn’t guarantee the value will be sequential in
transactional order.

The following create statement generates a table with an

AUTO_UNIQUE field:

CREATE TABLE hq_sales.invoices (

invoice_id BIGINT(0) UNSIGNED AUTO_UNIQUE NOT ↩
NULL,
branch_id INT NOT NULL,
customer_id INT,
invoice_date DATETIME(6),
invoice_total DECIMAL(13, 2),
payment_method ENUM('NONE', 'CASH', 'WIRE_ ↩
TRANSFER', 'CREDIT_CARD', 'GIFT_CARD'),
PRIMARY KEY(invoice_id)
);

In addition to the primary key, distributed SQL databases use a

distribution key. This field or set of fields is hashed in order to
determine which slice of the database the row will be assigned to.
By default, the key will be the first column and the primary key.

24 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 However, for some data it makes sense to pick a different set of
fields in order to avoid hotspots based on usage patterns or the
data itself. When picking a key, ensure the field or set of fields
has a high number of distinct values (NDV). This means if a table
has STATE_CODE (referring to states in the United States) and is
used as a distribution key, the table can’t be divided into 100 slices
(because there are only 50 states and a handful of districts and
territories), so pick a key that has enough NDV.

The following code is a create statement, generating a table with

the primary key used to distribute the table and multiple fields
used to distribute the index “user_id_posted_on_idx”:

CREATE TABLE user_posts (

post_id int AUTO_INCREMENT,
user_id int,
posted_on timestamp,
data blob,
PRIMARY KEY (`post_id`) /*$ DISTRIBUTE=1 */,
KEY `user_id_posted_on_idx` (`user_id`, ↩
`posted_on`) /*$ DISTRIBUTE=2 */
);

This key helps the database pick which nodes get which record or
index entry.

Tables big and small

One of the advantages of distributed SQL databases over NoSQL
databases is their ability to support joins. However, the cost of
joins in any distributed database is higher than in a client-server
database. Depending on the distributed SQL solution, these can be
more or less efficient, but nothing is as efficient as joining on a
single server.

Excessive schema normalization isn’t generally a good prac-

tice on a client-server database, but it’s even more important
to be ­judicious on a distributed database. Generally, distributed
SQL databases are for larger tables with a lot of data, shown in
­Figure 3-3, not many small tables.

If the system must track each address associated with a person in

a one-to-many relationship, it makes sense to use the format on
the right of Figure 3-3. However, if this is just the person’s cur-
rent shipping address, the form on the left will perform better.

CHAPTER 3 Getting Started with Distributed SQL 25

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 FIGURE 3-3: Consider using larger tables over many small tables.

It can help to understand how queries work. For Xpand, simple

queries (point selects) and inserts scale nearly linearly. Queries
are broken down into fragments and each fragment may require
at most one network hop (unless the data happens to be local).
However, joins require more work. Data must move to the node
that needs it next and then aggregate with data on another node
in which it’s joined.

Because data is divided among multiple nodes, Xpand is able to

use parallel processing. When more processor cores are available,
overall query processing is sped up. To be efficient, data is usually
forwarded to only one node.

REPLICAS=ALLNODES
Some tables are frequently accessed as reference data. It’s more
efficient to distribute these tables to every node in the cluster. Con-
sider doing this for tables that are relatively small (<10 megabytes
[MB]), rarely updated, read from frequently, and are frequently
joined with other tables. To do this, specify REPLICAS=ALLNODES
like the following code:

CREATE TABLE tbl_name (col_names) [REPLICAS = ↩

ALLNODES]
ALTER TABLE tbl_name [REPLICAS = ↩
ALLNODES]

26 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Using this feature allows joins against reference data to avoid a
hop and to happen locally on a single node making for more effi-
cient queries. The tradeoff is that writes to this data are slow (due
to the fact that all nodes have to be updated).

Range queries
Queries that use operators like < and > or keywords like between
are range queries. These types of queries can be more efficient if a
columnar index is used instead of a row index. Columnar indexes
essentially turn the table sideways because data in a column is
often repetitive, so it compresses better than a row index. A lot of
compressed values can be traversed more quickly, so this works
well for range queries.

Columnar indexes can be used for a single column or for a set of

columns and used in combination with standard row indexes. In
addition to making range queries more efficient, they can be used
for ad hoc queries where a perfect index doesn’t exist; this use
outperforms an imperfect index or full table scan. When using
columnar indexes, load data into the table before creating the
columnar index with the following code:

CREATE COLUMNAR INDEX idx_invoices_date_total

ON hq_sales.invoices (invoice_date, ↩
invoice_total);
CREATE TABLE hq_sales.invoices (
invoice_id BIGINT UNSIGNED NOT NULL,
branch_id INT NOT NULL,
customer_id INT,
invoice_date DATETIME(6),
invoice_total DECIMAL(13, 2),
payment_method ENUM('NONE', 'CASH', 'WIRE_ ↩
TRANSFER', 'CREDIT_CARD', 'GIFT_CARD'),
PRIMARY KEY (invoice_id),
COLUMNAR INDEX idx_invoices_date_total ↩
(invoice_date, invoice_total)
);

CHAPTER 3 Getting Started with Distributed SQL 27

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 JSON
Most modern relational database support JSON. The ANSI SQL
2016 standard even incorporates it. Distributed SQL databases
aren’t different, but how they support it and to what extent var-
ies. In Xpand, JSON is stored in its native format.

There is a drawback to using JSON in Xpand because the Query

Results Cache (QRC) must be disabled (set global qrc_enabled =
false;). This eliminates a performance optimization from the
database.

Some examples that include JSON data in Xpand are as follows:

»» To create a JSON table, use the following code:

create table files (id int primary key auto_ ↩
increment, doc json);

»» To insert data using JSON, use the following code:

insert into files (doc) values ('{"foo": ↩
{"bar": 1}, "baz": [1,2,3,4]}');

insert into files (doc) values ('{"foo": ↩

{"bar": 2}, "baz": [3,4,5]}');

»» To add a JSON column, use the following code:

alter table files add column foobar json;

28 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
»» Developing applications with Java

»» Growing your JavaScript ecosystem

»» Writing distributed SQL applications with

Python

Chapter 4
Creating Distributed
SQL Applications

X
pand fully supports most popular languages, frameworks,
and technologies. In fact, you can generally use the
same tools and technologies that you use to connect to
MariaDB and MySQL. This chapter overviews three of the more
popular frameworks in which you can create distributed SQL
applications.

But before you jump into the sections in this chapter, you may
want to check out Chapter 3 (if you haven’t already). The infor-
mation in this chapter is based on the SkySQL setup in Chapter 3.

This chapter outlines some of the important parts of connecting

to, querying, inserting into, and deleting from an Xpand database.
The examples are provided in Java, JavaScript, and Python. You
can grab the complete examples from GitHub by cloning from the
command line with

git clone https://github.com/mariadb-developers/ ↩

xpand-dummies

Or you can use your favorite git user interface (UI).

CHAPTER 4 Creating Distributed SQL Applications 29

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Regardless of the language you chose, ensure you have: installed
the mariadb client utilities, connected to your SkySQL Xpand
instance, and created the tables the examples depend on. These
are the steps necessary to do that:

1. Install MariaDB client utilities.

On Linux or Windows, follow the instructions from the
documentation at mariadb.com/docs/connect/clients/
mariadb-client.
If you’re on a Mac, follow the instructions at mariadb.com/
resources/blog/installing-mariadb-10-1-16-on-mac-
os-x-with-homebrew to install via Homebrew. (Note: This
will also install MariaDB Server, but you don’t have to run the
server.)
2. Connect to Xpand.
Connect to Xpand by using the following command:

mariadb --host YOURHOST --port YOURPORT --user ↩

YOURUSER --default-character-set=utf8 ↩
-A -p --ssl-ca ~/Downloads/skysql_chain.pem

3. Create the ORDERS database.

From the mariadb prompt, type “CREATE DATABASE orders;”
and “use orders;”
4. Create the ORDERS table.
Create the ORDERS table with the following SQL statement:

CREATE TABLE orders (

order_id BIGINT(0) UNSIGNED AUTO_UNIQUE ↩
NOT NULL,
customer_id INT NOT NULL,
order_date DATETIME(6),
order_created TIMESTAMP,
entered_by TINYTEXT
);

30 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 5. Create the ORDER_ITEMS table.
Create the ORDER_ITEMS table with the following SQL
statement:

CREATE TABLE order_item (

item_id BIGINT(0) UNSIGNED AUTO_UNIQUE ↩
NOT NULL,
order_id BIGINT(0) UNSIGNED NOT NULL,
line_num INT NOT NULL,
product_id INT NOT NULL,
Description TINYTEXT
);

Java
Java is one of the most common languages for developing appli-
cations with distributed SQL databases, especially MariaDB
Xpand. The code you see in this section demonstrate the processes
of connecting to your created database, inserting, querying, and
deleting rows using the Java Database Connectivity (JDBC) appli-
cation programming interface (API).

Before you code and compile the example, ensure you have the
following:

»» Java software development kit (SDK): On MacOS, you can

install via Homebrew with the following command:

brew install java

Make sure you follow the instructions at the end of the

process for adding the Java development kit (JDK) to your
path.
On Red Hat Enterprise Linux and CENTOS-based Linux
distributions, use

sudo yum install java-11-openjdk-devel

CHAPTER 4 Creating Distributed SQL Applications 31

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 »» Maven: Maven is a popular build tool. On MacOS, you can
install it with Homebrew by using this command:

brew install maven

On RHEL/CENTOS, use the following command:

sudo yum install maven

Most Java developers use an Integrated Development

Environment (IDE) such as IntelliJ IDE or Eclipse. You can find
them here:

• www.jetbrains.com/idea/download
• www.eclipse.org/downloads
»» A directory structure: Create a directory to hold your
overall project and a subdirectory structure matching src/
main/java/com/example.

MAVEN POM FILE

To build a project, you need a Maven build file (pom.xml), an
Application.java file, and the appropriate directory structure. You can
create the Maven build file called pom.xml in the project directory by
using your favorite editor.

The most important part for building an application that connects to

Xpand is the JDBC driver dependency:

<dependencies>
<dependency>
<groupId>org.mariadb.jdbc</groupId>
<artifactId>mariadb-java-client ↩
</artifactId>
<version>3.0.8</version>
</dependency>
</dependencies>
You can find a complete example of creating the Maven build file
here: github.com/mariadb-developers/xpand-dummies/blob/
main/java/pom.xml.

32 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Creating the main application
Create the main Java application by using your favorite editor at
src/main/java/com/example/Application.java. You can find the
complete listing at the following:

https://github.com/mariadb-developers/xpand-
dummies/blob/main/java/src/main/java/com/example/
Application.java

To connect to the database, construct a properties object that

supplies your database username and password and directs the
database driver to find your downloaded SSL certificate chain
(downloaded from SkySQL). Follow this code:

Properties connConfig = new Properties();

connConfig.setProperty("user", "YOURUSER");
connConfig.setProperty("password", "PASSWORD$");
connConfig.setProperty("useSsl", "true");
connConfig.setProperty("sslMode", "verify-full");
connConfig.setProperty("serverSslCert", ↩
"/path/to/your/skysql_chain.pem");

After you’ve entered that code, supply your server, port, and data-
base name along with the properties object to the Java JDBC driver
manager. You do that by following this code:

connection = DriverManager.getConnection(
"jdbc:mariadb://YOURSERVER:YOURPORT/orders",
connConfig);

Data can be inserted by constructing an SQL insert statement.

The statement inserts a row into the created orders table with
two parameterized values and inserts the current date and time
into the order_date and order_created fields. The code to insert this
statement looks like this:

String SQL_INSERT_ORDERS = """

INSERT INTO ORDERS (customer_id, order_date, ↩
order_created, entered_by)
VALUES (?, CURDATE(), CURTIME(), ?) """;

CHAPTER 4 Creating Distributed SQL Applications 33

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 A prepared statement can be constructed inside of a Java try/catch
block. The parameterized values are supplied in order by calling
the appropriate “set” functions on the statement object. Finally,
executeUpdate() tells the database to execute the statement.

PreparedStatement stmtOrders = connection. ↩

prepareStatement(SQL_INSERT_ORDERS, Statement. ↩
RETURN_GENERATED_KEYS);
stmtOrders.setInt(1, 1);
stmtOrders.setString(2, "andy");
stmtOrders.executeUpdate();

Deletes and updates are done in a similar way but with a different
SQL statement. For example, the following statement deletes an
order line item:

DELETE FROM order_item WHERE order_id = ? AND ↩

line_num = ?

Selects are done similarly. A query joins the ORDERS and ORDER_
ITEM table based on the order id. It returns all rows from the
ORDER_ITEM table in the database. The query looks like this:

String SQL_QUERY_ORDERS_ITEMS = """

SELECT o.order_id, o.customer_id, o.order_date, ↩
o.order_created, o.entered_by,
i.item_id, i.line_num, i.product_id, i.description
FROM orders o INNER JOIN order_item i ON o.order_ ↩
id = i.order_id""";

A statement is constructed, and a ResultSet object is created from

the statement by executing the statement and supplying the
query. The Resultset is used to iterate through the returned rows.
The code used is as follows:

try (Statement stmtQuery = connection. ↩

createStatement()) {
try (ResultSet rs = stmtQuery.executeQuery(SQL_ ↩
QUERY_ORDERS_ITEMS)) {
while (rs.next()) {

34 Distributed SQL For Dummies, MariaDB Special Edition

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 orderid = rs.getLong("ORDER_ID");
customerid = rs.getInt("CUSTOMER_ID");
orderdate = rs.getDate("ORDER_DATE");
ordercreated = ↩
rs.getDate("ORDER_CREATED");
enteredby = rs.getString("ENTERED_BY");
itemid = rs.getLong("ITEM_ID");
linenum = rs.getInt("LINE_NUM");
productid = rs.getInt("PRODUCT_ID");
description = ↩
rs.getString("DESCRIPTION"));
}
}
}

JDBC is a low-level method of supplying SQL statements to the

database for querying and manipulating data. Most developers
use object-relational mapping tools such as Hibernate, JOOQ,
and MyBatis along with frameworks such as Spring Data and
the Jakarta Persistence API (JPA). The good news is that if you’re
already familiar with these tools then you’re already familiar with
working with a distributed SQL database like MariaDB Xpand.

Running the application

Build and run the application using Maven with the following
code:

mvn compile exec:java -Dexec.mainClass="com. ↩

example.Application"

If everything is installed correctly, you should see some output

on your screen. You can also query the database from the com-
mand line to see the results. Each successful run results in one
row added to the orders table and two rows added to the order_item
table. However, one row is also deleted from the order_item table
leaving only one row in each table.

CHAPTER 4 Creating Distributed SQL Applications 35

These materials are © 2023 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Exploring the Variety of Random
Documents with Different Content
The Project Gutenberg eBook of A history of
the Brazil
 This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

Title: A history of the Brazil

comprising its geography, commerce, colonization,
aboriginal inhabitants, &c. &c. &c.

Author: James Henderson

Engraver: C. Shoosmith

Release date: January 24, 2024 [eBook #72778]

Language: English

Original publication: London: Longman Hurst Rees Orme and

Brown, 1821

Credits: Karin Spence and the Online Distributed Proofreading

Team at https://www.pgdp.net (This file was produced
from images generously made available by The
Internet Archive/American Libraries.)

*** START OF THE PROJECT GUTENBERG EBOOK A HISTORY OF

THE BRAZIL ***
 On Stone by C. Shoosmith from a Sketch by Jas. Henderson.
Printed by Rowney & Forster.
DON JOHN VI. KING OF PORTUGAL & BRAZIL, & HIS ATTENDANTS AT RIO DE
JANEIRO.

HISTORY
OF

THE BRAZIL;
COMPRISING ITS
GEOGRAPHY, COMMERCE, COLONIZATION,
ABORIGINAL INHABITANTS,
&c. &c. &c.

By JAMES HENDERSON,
RECENTLY FROM SOUTH AMERICA.

ILLUSTRATED WITH TWENTY-EIGHT PLATES AND TWO MAPS.

LONDON:
PRINTED FOR THE AUTHOR,
AND PUBLISHED BY LONGMAN, HURST, REES, ORME, AND BROWN,
PATERNOSTER-ROW.

1821.
MARCHANT, Printer, Ingram-Court,
Fenchurch-Street, London.
 TO THE

RIGHT HONOURABLE

THE LORD VISCOUNT LOWTHER.

My Lord,
Were the writer of the following Work a well-known and admired
member of the Literary Community he would still be fortunate in the
permission of having it dedicated to your Lordship, as your
Lordship’s literary, scientific, and commercial knowledge, correct
judgement, and amiable qualities, more than the influence of
elevated birth and rank, would confer upon it increased
recommendation. But coming forward as I do, an unknown
contributor to the stock of general knowledge, I am peculiarly happy
in having so high a passport to the notice of the Public, in a Work
which professes to communicate new information respecting a
portion of South America, now more than ever interesting to the
commercial, political, and scientific worlds. Whatever faults it
possesses, the pains I have taken to obtain authentic information
will, I trust, render it not unworthy of their and your Lordship’s
notice. If the style in which I present the new fruit, gathered from
the branches of the tree of knowledge that are spread in a far
country, is not considered interesting, the fruit itself will be found, I
hope, acceptable and useful.
I have the honour to subscribe myself,
My Lord,
Your Lordship’s most faithful and devoted Servant,
JAMES HENDERSON.
London, August 1, 1821.
 NOTICE TO THE READER.

The object of this Work is to describe the state of the Brazil, from
its first discovery down to the present time;—to trace distinctly the
boundaries of the twenty-two provinces which it comprises, their
sub-divisions into comarcas or districts, and their rivers; to
enumerate the povoaçoes or establishments in each province,
consisting of cities, towns, (and the dates they were so erected by
his present Majesty, or previously,) freguezias, (parishes,) arraials,
aldeias, (villages,) presidios, (garrisons,) hermitages, &c. with the
nature of their agricultural productions, the composition of their
inhabitants, whether whites, mulattos, mamalucos, mesticos,
Christianized Indians, or Africans.
The numerous tribes of savage Indians, still existing in this region
are also described; with the mountains, minerals, and leading
objects in the animal and vegetable worlds. The state of the
government, revenue, society, and minor subjects are investigated,
and more particularly the present commercial relations between
Great Britain and the Brazil. The friendly assistance I experienced
from many persons in South America, as well as from some
governors and ex-governors of provinces, has furnished a portion of
the authentic materials of the Work.
My first intention in undertaking it was to have adhered to a
geographical and commercial account of the country, but as the
recent publication of Padre Manoel Ayres de Cazal, (in producing
which he had been many years engaged,) furnishing me, not only
with copious information upon the first subject, but also upon its
history, civil and natural, I conceived that it would not be
unacceptable to the British reader to give an abridged account of
each province, from their first colonization, combined with their
geography, productions, commerce, &c.
Upon the history of this country, however, the work of Mr.
Southey is complete, and does as much honour to the talent of that
gentleman as to his unwearied research. The labour, even with all
his facilities, which such an undertaking must have required, cannot
but have been very considerable.
Padre Cazal, who is a man of some talent, enjoyed decided
advantages, it will be allowed, from his ecclesiastical situation, in
arriving at full and authentic intelligence, as to the present condition
of the towns, productions, &c. derived from Government documents,
his own personal research, the diaries of Certanistas, (persons
traversing the interior,) and from numerous individuals, who might
not have been disposed to grant the same privileges to any one
differently circumstanced. In the many instances wherein I have had
opportunities of putting the veracity of his statements to the test I
have found them correct and impartial. No doubt can fairly exist as
to the perfect authenticity of the whole, additionally confirmed as it
is, by Mr. Southey’s having had recourse to the same authority in the
latter part of his third volume.
The general reader may not be peculiarly interested with that
portion of this publication which details the towns and their
productions, and in which monotony is unavoidable, although they
will be valuable as references for the merchant and many others, as,
with the evidently growing commerce of this fine country, already
taking off annually three million of British manufactures, each of
those places will progressively become more and more important.
The plates, which are amongst the best in their style, are
executed, by an able artist, upon stone, from sketches taken on the
spot; and the map is formed by myself from the materials of the
Work. The Appendix is explanatory of the objects in Zoology and
Phytology, which would not have been generally understood by their
native designations; and I must here apologize to the reader for not
presenting them in scientific nomenclature.
 CONTENTS.

CHAPTER I.
Page
Voyage from England to Rio de Janeiro 1

CHAP. II.
From the first discovery down to the arrival of the Royal Family there, and
its present division into provinces—The general character of the Indians 12

CHAP. III.
PROVINCE OF RIO DE JANEIRO.
Its colonization—contests with, the French and Tamoyo Indians—expulsion
of the French—foundation of St. Sebastian—boundaries—division into
comarcas—mountains—principal rivers—lakes—bays—capes—islands—
mineralogy—zoology—phytology—cities and towns—boundaries, towns,
and productions of the comarcas of Ilha Grande and Parahiba Nova—
boundaries of the comarca of Rio de Janeiro—the metropolis—situation
—English burial-ground—streets—royal mode of riding—compulsory
homage upon the occasion—churches—convents—Gloria Hill—female
convents—visit to one—fountains—visit to the aqueduct—squares—
palace—public buildings—public garden—library—manufactories—theatre
—roads leading from the city—palace of St. Christovao—troops of miners
and others from the interior—Gaza de Don Pedro—royal mill, shacara,
and stables—fire-works—Beija Mao—fidalgos and higher orders of
society—splendour of churches—royal chapel—religious festivals and
observances—funeral processions—catacombs—the host—state of
society—markets 31

CHAP. IV.
PROVINCE OF RIO DE JANEIRO—continued.
Population of the capital—negroes—nocturnal clamour of reptiles—vampire 72
hat—state of literature—jealousy—dead bodies—military—bank—revenue
—imposts—diamonds—visit to Campinha—tenure of lands—proof of
fertility—Swiss emigrants—visit to the cascades of Tejuca—commerce—
judicial procedure—pauta and convention—new exchange—foundation of
English church—towns, villages, and productions of the comarca of Rio
 de Janeiro—boundaries, productions, rivers, lakes, and povoaçoes of the
comarca of Cape Frio—boundaries, Indians, rivers, lakes, towns, and
sugar-works of the comarca of Goytacazes—boundaries, Coroado
Indians, and povoaçoes of the comarca of Canta Gallo

CHAP. V.
PROVINCE OF RIO GRANDE DO SUL.
Colonization—boundaries—climate—aspect and productions—contests
between Spaniards and Portuguese—divisionary line between these two
powers—opposition by the Indians of the seven missions—their defeat—
revived contests between Spaniards and Portuguese—mountains—rivers
—lakes—capes and ports—islands—mineralogy—phytology—zoology—
large fazendas for breeding cattle—mode of management—sheep-flocks
—use of the laço and balls—towns, nature of exports, villages, &c.
including those of the district of Monte Video 110

CHAP. VI.
PROVINCE OF PARANNA.
Boundaries—climate—productions—Matte the most lucrative—first
discoverers—proceedings of the Spanish Jesuits—Guarani Indians
formed into reduções, or villages—nature of those missions—expulsion
of the Jesuits—delivery of the missions to other ecclesiastics—their
decay—mountains—mineralogy—rivers and lakes—phytology—zoology—
towns, parishes, &c.—remaining establishments of the Jesuitical missions 134

CHAP. VII.
PROVINCE OF URUGUAY.
Foundation of aldeias, called missions, by the Spanish Jesuits for the Tappe
Indians—flourish till the expulsion of that sect—subsequent decay—war
between the Spaniards and Portuguese—conquest of the seven missions
by the latter power in 1801—governor sent—boundaries—mountains—
rivers—phytology—zoology—names and population of the seven
missions at their conquest 145

CHAP. VIII.
PROVINCE OF ST. CATHARINA.
Boundaries—colonization—productions—mountains—mineralogy—
phytology—zoology—rivers, lakes, and ports—towns, parishes, &c.—
agricultural establishments—population—islands—delightful climate 151
 CHAP. IX.
PROVINCE OF ST. PAULO.
Boundaries—first settlement—mountains—mineralogy—rivers and ports—
islands—phytology—zoology—Bugre Indians, dwellings and customs—
character of the Paulistas—division into comarcas—comarca of Curytiba
—towns and productions—comarcas of St. Paulo and Hitu—towns and
productions 162

CHAP. X.
PROVINCE OF MATTO GROSSO.
First explorers—gold discovered—two brothers appointed for the purpose
of exacting the fifths on gold—their atrocious conduct—people attracted
here by the fame of gold—destruction of a party by the Indians—
Payagoa and Guaycuru Nations discovered—their alliance—their fatal
attacks upon the Portuguese—their disunion—continued hostilities of the
Guaycurus—conflicts with them—attempts to make peace with the
Indians—treachery of the Guaycurus—severe drought—arrival of a
governor—promotes the navigation to Para—extent and boundaries—
division into districts.—District of Camapuania—mineralogy—phytology—
rivers—zoology—various Indian tribes—povoaçoes.—District of Matto
Grosso—mountains—mineralogy—phytology—zoology—rivers—capital.—
District of Cuiaba—mineralogy—phytology—zoology—rivers—povoaçoes
—Indians.—District of Bororonia—Indians—rivers—lakes.—District of
Juruenna—Indians—rivers—forts.—District of Arinos—Indians—rivers.—
District of Tappiraquia—Indians—rivers.—Lands of these districts fertile
and auriferous 189

CHAP. XI.
PROVINCE OF GOYAZ.
First discovery of gold—attempts of Bueno to find the Goya Territory—
settlements —boundaries—extent—mineralogy—zoology—phytology—
cattle and gold its exports—principal rivers—comarcas—Julgados.—
District of Cayaponia—limits—Indians—rivers.—District of Goyaz—limits—
mountains—capital—povoaçoes.—District of Nova Beira—limits—Indians
—rivers—povoaçoes—Indians reduced to peace—aldeias established for
them.—District of Tucantines—limits—rivers—Indians—povoaçoes.—
District of Parannan—limits—rivers—povoaçoes.—District of Rio das
Velhas—limits—rivers—Indians—povoaçoes 231
 CHAP. XII.
PROVINCE OF MINAS GERAES.
Boundaries—extent—climate—discoverers of its mines—mountains—rivers
—mineralogy—zoology—phytology—exports—comarcas and towns.—
Comarca of Villa Rica—limits—mountains—rivers—capital—povoaçoes.—
Comarca of Rio das Mortes—limits—mountains—rivers—povoaçoes.—
Comarca of Sabara—limits—mountains—rivers—lakes—povoaçoes.—
Comarca of Serro Frio—limits—rich in diamonds—mountains—rivers—
povoaçoes.—Diamond district—Tijuco—seat of diamond junta 258

CHAP. XIII.
PROVINCE OF ESPIRITO SANTO.
Extent—boundaries—misfortunes of its donatories—spirited resistance of
the Indians—partial cultivation—principally possessed by Indians—
mountains—mineralogy—zoology—descents of Indians to the coast—
phytology—rivers and ports—povoaçoes.—Island of Ascension 288

CHAP. XIV.
PROVINCE OF PORTO SEGURO.
Boundaries—prosperity of its first donatory—reversion to the crown in a
bad state—present partial cultivation—Indians—mountains—mineralogy
—zoology—phytology—rivers, lakes, and ports—povoaçoes—abrolhos 297

CHAP. XV.
PROVINCE OF BAHIA.
Boundaries—Caramuru—first donatory—cruel war of the Indians—the
capitania forsaken—return of the donatory—shipwreck—slaughter of all
but Caramuru—governor-general—foundation of St. Salvador.—Comarca
of the Ilheos—originally a capitania—extent—fertility—mountains—
mineralogy—phytology—zoology—rivers and lakes—povoaçoes.—
Comarca of Jacobina—extent—mineralogy—mountains—rivers—
phytology—zoology—povoaçoes.—Comarca of Bahia—extent—mountains
—mineralogy—phytology—zoology—islands—rivers—povoaçoes.—St.
Salvador—churches and convents—public buildings—Sepulchre of
Caramuru’s wife—negroes—commerce—produce—exports in 1817 and
1818—state of society—adoption of a new constitution 309

CHAP. XVI.
PROVINCE OF SEREGIPE D’EL REY.
Colonization—reduction of the Indians—extent—mountains rivers and lakes
—mineralogy—zoology—phytology—povoaçoes 347

CHAP. XVII.
PROVINCE OF PERNAMBUCO.
Voyage from Rio de Janeiro—first donatories—taken by the Dutch—
restoration—reversion to the crown—Indians—boundaries—mountains—
colony of negroes—mineralogy—zoology—phytology—rivers—islands—
comarcas of Ollinda, Recife, Alagoas—povoaçoes—ouvidoria of the
certain of Pernambuco—rivers—towns—Recife, or Pernambuco—Ollinda
—Mattutos—state of society—apathy—environs—revolution in 1817—
military government—adoption of a new constitution—holidays—produce
—inspection—sugar engenho—contribution-fund—population—Fribourg
House 355

CHAP. XVIII.
PROVINCE OF PARAHIBA.
Extent—capitania of Itamaraca—slow advancement—taken by the Dutch—
restoration—capes and ports—rivers—mountains—zoology—phytology—
povoaçoes—capital—British establishments—produce 394

CHAP. XIX.
PROVINCE OF RIO GRANDE DO NORTE.
Contests with Indians—conquest—taken by the Dutch—restored—extent—
sterility of soil—capes and ports—mineralogy—mountains—zoology—
phytology—rivers and lakes—povoaçoes—island of Fernando de Noronha 404

CHAP. XX.
PROVINCE OF SIARA.
Colonization—boundaries—Indians—taken by the Dutch—restored —
mountains—mineralogy—zoology—phytology—rivers and lakes—
povoaçoes 412

CHAP. XXI.
PROVINCE OF PIAUHY.
Boundaries—first settlers—cattle fazendas—mountains—mineralogy—rivers
—towns 424

CHAP. XXII.
 PROVINCE OF MARANHAM.
First donatory—shipwreck of persons intended for its colonization—
establishment of the French—retaken—foundation of capital—taken by
the Dutch—retaken—agricultural company—boundaries—rivers, ports,
and islands—mineralogy—phytology—zoology—Indians—povoaçoes—city
of Maranham—commerce—exports of produce 433

CHAP. XXIII.
PROVINCE OF PARA.
First settlement—contests with Indians—slavery of the Indians—their
liberation—Boundaries—mineralogy—phytology—zoology—ports and
rivers—Igaruana Indians.—District of Para-Proper—capital—buildings—
exports—English establishments—adoption of a new constitution—
towns.—District of Xingutania—limits—in possession of Indians—rivers—
towns.—District of Tapajonia—limits—rivers—Indians—towns.—District of
Mundrucania—rivers—principally possessed by the Indians—their
different customs—towns 448

CHAP. XXIV.
PROVINCE OF SOLIMOES.
Jurisdiction—origin of its name—boundaries and extent—partially known—
division into six districts—rivers—various Indians—customs—povoaçoes 477

CHAP. XXV.
PROVINCE OF GUIANNA.
Boundaries—islands—rivers—towns—Indians 485

CHAP. XXVI.
Conclusive observations 498

Appendix 501
 LIST OF SUBSCRIBERS.
A
Abbey, Richard, esq. Pancras-lane.
Ablet, Isaac, esq. Bucklersbury.
Ainslie, Dr. Dover-street.
Ainsworth, Thos. esq. solicitor, Manchester.
Allen, John, esq. Manchester.
Anderson, John, esq. St. Vincent’s Street, Glasgow.
Andrew, Jonathan, esq. Manchester.
Andrew, Thomas, esq. jun. Manchester.
Andrew, George, esq. Green-hill, Cheshire.
Andrew, Robert, esq. Green-Mount, Manchester.
Ansley, Alderman, 95, Park-street.
Ashton, John, esq. New Cannon-street, Manchester.
Ashton, Thomas, esq. Liverpool.
Atkinson, William, esq. Nicholas-lane.
Atkinson, Matthew, esq. Temple-Sowerby.
Austwick, ——, esq. Friday-street.

B
Becket, The Right Hon. John, Judge-Advocate, M.P. Downing-street.
Bamber, W. and Co. Messrs. Manchester.
Barnett, John, esq. City-road.
Barrow, Thomas, esq. Manchester.
Barton, Sir William, Henry-st. Liverpool.
Bateman, James, esq. Islington-house, Manchester.
Beardsworth, George, esq. High-street, Manchester.
Beck, Francis, esq. 12, Old Jewry.
Benkhausen, George, esq. Russian Vice-Consul, Winchester-street.
Bentham, William, esq. Gower-street.
Bentley, John, jun. esq. Stockport.
Bibby, John, esq. Liverpool.
Bielby, Hyde, and Co. Messrs. Birmingham.
Birkbeck, George, esq. M.P. Cateaton-st.
Birtless, Thomas, esq. Manchester.
Blackett, J. jun. esq. 20, London-street.
Blaikie, Robert, esq. 4, St. Hanover-street, Glasgow.
Blair, George, esq. Bolton.
Blanckenhagen, J. C. esq. King-street.
Bolling, Edward, jun. esq. Bolton.
Bolton, J. esq. Liverpool.
Bond, J. esq. Church-street, Stoke Newington.
Bone, Mrs. 10, Cambridge-row, Hackney.
Booth, Benjamin, esq. Manchester.
Booth, Thomas, esq. Liverpool.
Boothby, J. B. esq. Everton, near Liverpool.
Bonsor, Joseph, esq. Salisbury-square.
Bousfield, John, esq. Manchester.
Bowen, Charles, esq. Chandos-st. Cavendish-square.
Bradshaw, John, esq. Manchester.
Bradley, Thomas, esq. Mark-lane.
Bradock, J. esq. St. James’s Square, Manchester.
Brandt, Charles, esq. Manchester.
Broadbent, James, esq. Manchester.
Brocklebank, Thomas, esq. Liverpool.
Brotherston, J. esq. Liverpool.
Broughton, ——, esq. Mecklenburg-square.
Brown, Archibald, esq. Glasgow.
Brown, James, esq. 190, Cross, Glasgow.
Brown, S. esq. Liverpool.
Brown, James, esq. St. Mildred’s Court.
Brown, Robert, esq. 157, Cheapside.
Buchan, Lawrence, esq. Manchester.
Buchannan, John, esq. Liverpool.
Buckle, John William, esq. Mark-lane.
Burgess, Henry, esq. Manchester.
Brunton, Thomas, esq. Commercial-road.
Burra, Robert, esq. Watling-street.
Bury, James, esq. Lever-street, Manchester.
Butler, W. H. esq. Water-lane.

C
Campbell, Thomas, esq. 23, Old Burlington-street.
Campbell, Charles, esq. Bishopsgate-street.
Campbell, J. esq. Liverpool.
Cardale, W. esq. Bedford-row.
Carmalt, C. esq. 30, Bow-lane.
Capper, Thomas, esq. Beaufort-buildings, Strand.
Carrick, Robert, esq. banker, Glasgow.
Carruthers, John, esq. Leadenhall-street.
Case, John Ashton, esq. Liverpool.
Chance, W. and G. Messrs. Birmingham.
Chetwode, C. esq. Liverpool.
Christian, Professor, Gray’s Inn.
Christie, John and Robert, and Co. Messrs. Manchester.
Clark, John, esq. Crutched Friars.
Clarkson, Thomas, esq. Playford-hall, near Ipswich.
Coats, Edward, esq. 35, Bernard-street, Russell-square.
Cockshott, James, esq. Pernambuco.
Cohn, G. J. and Sons, Messrs. Manchester.
Collier, Josiah, esq. Manchester.
Collins, Edward, esq. Bell-street, Glasgow.
Collinson, Thomas, esq. Lombard-street.
Collinson, John, esq. 29, Lambeth Marsh.
Colquhoun, Archibald, esq. Turner’s Court, Glasgow.
Cook, James, esq. 40, Mincing-lane.
Cooke, Isaac, esq. Liverpool.
Cooper, John and F. Messrs. Old ’Change.
Cooper, T. W. esq. Harleyford-place, Kennington.
Cooper, Astley, esq. New-street, Spring-Gardens.
Copland, Robert, esq. Liverpool.
Copling, John, esq. Newgate-street.
Corbould, Charles, esq. 4, Carey-lane, Foster-lane.
Cotter, Lieutenant-Colonel, Pernambuco.
Courtney, Thomas, esq. Old Jewry.
Cowie, George, esq. Russell-square.
Crammond, A. L. esq. 11, Leadenhall-st.
Crole, D. esq. Old Broad-street.
Crosby, Rev. Robert, A. M. Hoxton-sq.
Croggon, William, esq. 64, Cornhill.

D
De Dubatchefsky, A. esq. Russian Consul-General, 28, Great Winchester-st.
Da Costa, A. J. esq. Portuguese Consul, Liverpool.
Dalgairns, P. esq. 5, Martin’s Lane.
Dalglish, Robert, esq. Glasgow.
Darch, Thomas, esq. Admiralty.
Davenport, James, and Co. Messrs. 82, Fleet-street.
Davison, John, esq. 37, Gutter-lane.
Dawson, Jonathan, esq. Stratford, Essex.
Dawes, John, esq. Threadneedle-street.
Dawson, Jonathan, esq. Manchester.
Dawson, Richard, esq. Liverpool.
De la Chaumette, L. J. esq. Angel-court.
Delisle, Z. esq. Church-st. Stoke Newington.
Delpla, Edward, esq. Liverpool.
Dempster, J. esq. Commercial-ct. Glasgow.
Denison, James, esq. South Lambeth.
Dent, William, esq. Wandsworth-common.
Devas, William, esq. Watling-street.
Dixon, William, esq. Liverpool.
Dixon, Francis, esq. Manchester.
Dixon, George, esq. Manchester.
Dobson, John, esq. 17, Bucklersbury.
Duff, William, esq. Liverpool.
Dugdale, Adam, esq. Manchester.
Dyson, Thomas F. esq. Liverpool.

E
Edgar, T. esq. 9, Billiter-square.
Edwards, Richard, esq. Seel-st. Liverpool.
Edwards, C. A. esq. Wandsworth.
Engstrom, Charles, esq. St. Mildred’s Ct.
Euing, W. R. esq. Liverpool.
Evans, Thomas, esq. Watling-street.
Eyes, Charles, esq. Liverpool.

F
Fitzwilliam, the Right Hon. the Earl, 4, Grosvenor-square.
Farrer, William, esq. Watling-street.
Fawcett, Peter, esq. Manchester.
Fawdington, William, esq. Manchester.
Fell, Richard, esq. Bolton.
Fielding, Jeremiah, esq. 64, Mosley-street, Manchester.
Fisher, John, esq. 23, Watling-street.
Fleming, T. esq. Water-st. Manchester.
Forrester, W. esq. 3, Crown-ct., Broad-st.
Fortunato, A. P. esq. Liverpool.
Fothergill, J. esq. Stockwell-place, Surrey.
Fox, E. B. esq. 80, Old Broad-street.
Freeze, J. H. jun. esq. Mecklenburgh-sq.
Frend, William, esq. Rock Life Assurance, Bridge-street.
Freshfield, J. W. esq. New Bank Buildings.
Fry, Joseph, esq. Liverpool.
Fullarton, A. esq. 37, Brunswick-pl. Glasgow.
Fyffe, J. esq. 4, Buchanan st. Glasgow.

G
Graham, Sir J. Bart. M.P. 1, Portland-pl.
Gallemore, Liddel, Messrs. and Co. Manchester.
Gardin, Alex. esq. George-sq. Glasgow.
Gardner, J. esq. 39, Miller-street, Glasgow.
Garnett, Abraham, esq. Liverpool.
Geary, Thomas, esq. Manchester.
Geller, John G. esq. Liverpool.
Gibbins, Bruton, esq. Birmingham.
Gilfillan, J. esq. Liverpool.
Gillespie, A. esq. America-square.
Godmond, C. esq. Blackheath.
Gordon, A. esq. H.M. Consul, Havre de Grace.
Gordon, James, esq. Manchester.
Goring, Joshua, esq. Liverpool.
Gowen, John, esq. Mark-lane.
Gray, B. esq. Crescent, Ancoats, Manchester.
Graham, W. jun. esq. Cochrane-st. Glasgow.
Graham, William, esq. Liverpool.
Grant, D. esq. Manchester.
Grant, George, esq. Liverpool.
Grant, William, esq. Manchester.
Grant, John, esq. Manchester.
Greaves, John, esq. Banker, Manchester.
Greenough, Peter and Sons, Manchester.
Greenway, Charles, esq. Manchester.
Guimaraens, G. J. F. esq. Liverpool.
Gumpel, Gustavus, esq. Manchester.

H
Horrocks, Samuel, esq. M.P. 9, Bread-st.
Haddan, John, esq. 52, Wellclose-square.
Haffinden, J. esq. 28, Queen’s Sq. Bloomsbury.
Hamman, John, esq. Bow-lane.
Hancock, John, esq. Liverpool.
Hankey, W. Alers, esq. Fenchurch-street.
Hankey, Thomas, esq. Fenchurch-street.
Hardacre, George, esq. 23, Birchin-lane.
Hardie, David, esq. Liverpool.
Hardie, James, esq. Manchester.
Hardman, Thomas, esq. Manchester.
Hardy, William, esq. Mincing-lane.
Harrison, Anthony, esq. Penrith.
Harrison, J. esq. Marsden-sq. Manchester.
Harrison, William, esq. 13, Little Tower-st.
Haselden and Willis, Messrs. Liverpool.
Hatch, Oliver, esq. Ely-place.
Heale, Richard, esq. Mincing-lane.
Helps, Thomas, esq. Wood-street.
Hemsley, Henry, esq. Amsterdam.
Henderson, R. esq. Glasgow.
Henderson, G. esq. 6, St. Enoch’s Square, Glasgow.
Henderson, J. esq. 11, Great St. Helen’s.
Henderson, J. esq. Shap, Westmorland.
Henderson, W. esq. Lowthian Gill, Cumberland.
Henderson, Robert, esq. Lowthian Gill.
Heyworth, O. esq. Liverpool.
Heyworth, John, esq. Greev’s Nook, near Rochdale.
Heyworth, James, esq. Liverpool.
Hill, Thomas, esq. Manchester.
Hill, W. esq. 17, Old Mill Gate, Manchester.
Hitchen, Jonathan, esq. Bolton.
Hodgson, Thomas, esq. Euston-square.
Hodgson, T. esq. Church-lane, Whitechapel.
Holliwell and Highfield, Messrs. Liverpool.
Holme, W. esq. Sackville-st. Piccadilly.
Hornby, J. T. and W. Messrs. Liverpool.
Horridge, T. G. esq. Fountain-st. Manchester.
Horrox and Son, Messrs. Manchester.
Horrox, Jackson, Messrs. and Co. Manchester.
Howard, L. esq. Long Room, Custom-House.
Hoyle, Thomas, jun. esq. Manchester.
Hulme, John, esq. Manchester.
Hunter, And. esq. 11, Candlerigs, Glasgow.
Hurry, William, esq. Liverpool.
Hurst, John, esq. Manchester.
Husey, N. esq. 91, Watling-street.
Hutcheson, C. esq. George-sq. Glasgow.
 I&J
Izon, Thomas, esq. Birmingham.
James, W. esq. M.P. Coulson’s Hotel, Brook-street.
Jackson, R. esq. Manchester. (2 copies.)
Jackson, John, esq. 1, Cannon-street, Manchester.
James, Thomas, esq. 17, Cheapside.
Jelf, George, esq. Norwood.
Jones, Richard, esq. 10, Aldgate.
Jones, Richard, esq. Four Yards, Manchester.
Josling, Thomas, esq. 34, Broad-street.

K
Kay, W. esq. Tring-Park, Hertfordshire, and Hampstead.
Kay, Joseph, Watling-street, Manchester.
Kearsley, John, esq. Liverpool.
Kemble, Henry, esq. Watling-street.
Kennedy, James, esq. Ancoats-lane, Manchester.
Kent, Samuel, esq. Mark-lane.
Kenworthy, W. esq. Pernambuco.
Kewley, P. esq. Liverpool.
Keymer, Titus, esq. Lawrence-lane.
Keyser, S. esq. 23, Finch-lane.
Kirtley, George, esq. Manchester.
Knight, James, esq. Rhual, near Mould, Flintshire.
Knight, Samuel, esq. Manchester.
Knight, Nathan, esq. Manchester.
Kolft, G. esq. Liverpool.

L
Lonsdale, The Right Hon. the Earl of, Charles-street, Berkeley-square.
Lonsdale, The Right Hon. the Countess of, Charles-street, Berkeley-square.
Lowther, The Hon. Col. M.P. Bruton-st.
Laing, Charles, esq. 26, Lawrence-Poulteney-lane.
Latham, Wm., esq. Liverpool. (2 copies.)
Lawrence, Isaac, esq. Balham-hill.
Lawrence, W. and E. and Co. Messrs. Liverpool, and 9, Trinity-sq. London.
Leake, L. and G. Messrs. Threadneedle-st.
Ledward, E. and C. Messrs. Liverpool.
Leech, Rev. J. L. A.M. Vicar of Askham.
Leigh, J. P. esq. Clapton.
Lewis, Edward, esq. and Co. Manchester.
Lindeman, Frederick, esq. H.M. Consul-General, Sicily.
Little, William, esq. Stock-Exchange.
Liverpool Union Book Society.
Lodge, H. R. esq. 11, Bow-church-yard.
Lomax, John, esq. Manchester.
Lomax, Richard, esq. 10, West-square.
Low, Andrew, esq. Liverpool.
Low, George, esq. Birmingham.
Lowe, John, esq. 5, Jeffrey’s Square.
Lowe, Arthur, esq. Liverpool.
Loyd, Edward, esq. Banker, Manchester.
Loyd, Lewis, esq. Lothbury.
Loyd, William, esq. Bread-street.
Lukin, C. jun. esq. 16, George-street, Mansion-house.
Lyne, W. and Sudell, T. Messrs. Liverpool.

M
Musgrave, Sir P. Bart. M.P. 39, Portland-p.
Macadam, P. esq. 26, Bell-street, Glasgow.
M’Cabe, Thomas, esq. Stoke-Newington.
M’Cartney, A. esq. Commercial Bank, Edinburgh.
M’Conochie, W. esq. Glasgow.
M’Farquhar, J. esq. York-st. Liverpool.
Macfie, D. esq. 36, Candleriggs, Glasgow.
Machell, John, esq. Low Plains, Penrith.
M’Keand, James, esq. Liverpool.
M’Keand, J. and J. Messrs. Manchester.
M’Kerrel, Henry, esq. Liverpool.
Maclachlan, D. esq. Parahiba.
M’Nair, John, esq. jun. Glasgow.
M’Neile, John, and Co. Messrs. Lawrence-Poulteney-lane.
M’William, R. esq. Liverpool.
March, William, esq. Broad-street.
March, T. and W. and Co. Messrs. 15, New Broad-street.
Marchant, Mr. W. Ingram-ct. Fenchurch-st.
Mardall, R. esq. 14, Little Tower-street.
Marris, Francis, esq. Manchester.
Marsh, John, esq. 66, Coleman-street.
Marshall, J. esq. York-street, Manchester.
Martin, William, esq. Hornsey.
Martindale, Richard, esq. 62, Cornhill.
Martindale, D. esq. Liverpool.
Masterman, John, esq. White Hart-court, Lombard-street.
Mathews, Samuel, esq. Salford.
Matley, Richard, esq. Manchester.
Matthie, H. esq. Liverpool.
Maubert, J. F. esq. Warnford-court.
Meirilles, A. esq. Liverpool.
Mellor, Thomas, esq. Liverpool.
Meyrick, E. esq. Spitalfields.
Middleton, R. D. esq. Wellington-place, Commercial-road.
Mieville, Andrew A. esq. Angel-court, Throgmorton-street.
Miles, Rev. John, St. Michael’s Rectory, Cornhill.
Miller, John, esq. Liverpool.
Miller, M. esq. Islington, Liverpool.
Milner, James, esq. Old Change.
Mitcalfe, William, esq. Gower-street, or Coal-Exchange.
Mitchell, William, esq. Mincing-lane.
Molyneux, Anthony, esq. Liverpool.
Monteath, J. esq. Buchanan-st. Glasgow.
Monteith, R. esq. Richmond-st. Glasgow.
Monteith, William, esq. 4, Blythwood-place, Glasgow.
Moon, Edward, esq. Liverpool.
Moore, Dr. Bolton.
Morgan, John, esq. ’Change-alley.
Morgan, W. esq. Pope’s Head-alley.
Morley, John, esq. West Smithfield.
Morrison, J. esq. 33, Glassford-st. Glasgow.
Morrison, W. esq. 14, Miller-st. Glasgow.
Moxon, J. D. esq. Liverpool.
Muir, J. esq. Ingram-Buildings, Glasgow.
Murphy, George, esq. Manchester.
Murray, G. esq. Ancoat’s Hall, Manchester.

N
Naylor, Jeremiah, jun. esq. Liverpool.
Needham, Samuel, esq. Liverpool.
Nesbitt, John, esq. Tokenhouse-yard.
Nevitt, William, esq. Liverpool.
Newall, A. esq. 4, Virginia-street, Glasgow.
Newman, Thomas, esq. Hertingfordbury, near Hertford.
Nicholson, William, esq. Lowther.
Noble, William, esq. 36, Foley-place.
Noble, J. esq. 8, Tokenhouse-yard.
Norris, Edward, esq. Manchester.

O
Oughton, James, esq. Manchester.

P
Packer, Richard, esq. Mile-end.
Packer, R. W. esq. Stepney-green.
Page, Charles, esq. 10, Austin-friars.
Park, John, esq. Liverpool.
Parker, W. esq. Manchester.
Parker, Robert, esq. Heaton Mersey, Manchester.
Parker, C. esq. Pettrill-green, Cumberland.
Parkins, J. W. esq. late Sheriff, Bridge-street.
Paterson, Alexander, esq. Manchester.
Paton, John, esq. Bow Church-yard.
Peck, Samuel, esq. Liverpool.
Peel, Edmund, esq. 30, Bucklersbury.
Penny, J. S. esq. Leaf-sq. Manchester.
Percival, R. jun. esq. 76, Lombard-street.
Pickering, Edward Rowland, esq. Clapham.
Platt, Dr. Bolton.
Pollard, J. esq. Manchester.
Potter, John, esq. Manchester.
Potter, Richard, esq. Manchester.
Powell, James, esq. Carey-street.
Price, Joseph, esq. 7, King-street.
Price, Buckley, esq. Manchester.
Pringle, George, esq. Stoke-Newington.
Pringle, Keneth, esq. Liverpool.
Pritt, G. A. esq. Liverpool.
Provand, Charles M. esq. 31, Miller-street, Glasgow.
Pullen, J. esq. late Under Sheriff, Fore-street.

R
Rainier, Daniel, esq. 11, ’Change-alley.
Rainforth, Dr. John, Bolton.
Ramsay, Dr. Pernambuco.
Ramsome, J. A. esq. Mosley-street, Manchester.
Ray, Joseph, esq. American Consul, Pernambuco. (20 copies.)
Reardon, Daniel, esq. Corbet-court, Grace-church-street.
Richardson, Christ. esq. Brunswick-sq.
Richardson, John, esq. Liverpool.
Richardson, Samuel, esq. Liverpool.
Ridgway, J. esq. Ridgmont, Lancashire.
Rigg, James, esq. King-st. Manchester.
Rignell, James, esq. Chelsea.
Rivaz, A. esq. Stoke-Newington.
Robinson, James, esq. Walbrook.
Rogers, S. esq. Watlands, near Newcastle, Staffordshire.
Roskell, R. and J. Messrs. Liverpool.
Rothschild, N. M. esq. Stamford-hill.
Row, J. esq. 2, Aldermary-church-yard.
Rowlandson, Rev. J. Shap, Westmorland.
Royle, Vernon, esq. Manchester.
Rushforth, Richard, esq. Manchester.
Rushton, W. esq. Liverpool.
Russell, Edward, esq. Maidstone.

S
Spencer, the Rt. Hon. the Earl of, St. James’s Place.
Strangford, the Rt. Hon. Lord, Minister, Constantinople.
Sadler, Joseph, esq. 2, Bow-lane.
Samuel, S. M. esq. 1, Hammet-street, America-square.
Samuel and Phillips, Messrs. 8, South-street, Finsbury-square.
Saner, James, esq. Sun-street.
Schwieger, G. E. F. esq. Highbury-terrace.
Scott, John, esq. Du Four’s Place.
Sealy, George T. esq. Liverpool.
Sheldon, S. esq. Milk-street.
Shepherd, H. esq. Union-street, Borough.
Sherman, J. R. esq. Lime-street.
Shore, Joseph, esq. Birmingham.
Slade, Rev. J. Bolton.
Smith, J. S. esq. Holloway-place.
Smith, R. esq. Finch-lane.
Smith, Charles, esq. High-street, Manchester.
Smith, John, esq. Piccadilly, Manchester.
Smith, Samuel, esq. 40, Commercial Sale Rooms, Mincing-lane.
Soulby, A. esq. St. Mary-hill.
Spenceley, J. H. esq. 20, Lawrence Poulteney-lane.
Spooner, T. esq. George-yard, Lombard-street.
Stable, Henry, esq. 115, Duke-street, Leicester-fields.
Stephenson, F. esq. Pope’s Head-alley.
Stevenson, George, esq. 42, Bow-lane.
Stirling, Charles, esq. Glasgow.
Stocks, Samuel, esq. Manchester.
Stuart, J. esq. St. Vincent-lane, Glasgow.
Stubbs, Thomas, esq. 16, Lad-lane.
Stwewardson, Thomas, esq. Adelphi.
Sydebotham, Charles, esq. Liverpool.
Symonds, John, esq. Old Jewry.

T
Thompson, W. esq. M.P. 12, Gloucester-place, Portman-square.
Tate, W. esq. Old Jewry.
Taylor, Thomas, esq. 7, Back-square, Manchester.
Taylor, J. esq. Bradford-house, Bolton.
Taylor, James, esq. Liverpool.
Tennant, John, esq. Henry-street, Liverpool.
Thomas, J. W. esq. Liverpool.
Thomas, W. esq. 1, Cateaton-street.
Thompson, J. esq. 44, Old Change.
Thorp, J. T. esq. Lord Mayor, London.
Thorp, Dr. King-street, Manchester.
Tinkler, W. esq. Putney, Surrey.
Tootal, Henry, esq. Manchester.
Townend, W. esq. Manchester.
Tristram, H. esq. 138, Leadenhall-street.
Turner, George, esq. Liverpool.
Turner, Brade, and Co. Messrs. Liverpool.

V
Varty, William, esq. Bishopsgate-street.

W
Waterhouse, Nicholas, esq. Liverpool.
Wemyss, General, 19, Cumberland-street.
Whalley, John, esq. 11, Bow Church-yard.
Wheeler, Samuel, esq. Surrey-square.
Wiegbers, J. esq. 23, Finch-lane.
Wilkinson, E. esq. Long Room, Custom-House.
Wilkinson, Thomas, esq. 8, Fitzroy-square.
Wilkinson, Robert, esq. Islington.
Wilde, James, esq. Manchester.
Williams, B. and T. Messrs. Manchester.
Williams, Thomas, esq. Liverpool.
Williamson and Watson, Messrs. Dublin.
Willis, Daniel, esq. Liverpool.
Wilson, Crighton, and Co. Messrs. Manchester.
Wilson, R. esq. Clement’s Lane.
Wilson, Thomas, esq. Staple Inn.
Wilson, Samuel, esq. Aldermanbury.
Windus, Thomas, esq. Stoke-Newington.
Winstanley, W. esq. 10, Paternoster-row.
Wingate, J. esq. 190, Trongate, Glasgow.
Wood, Philip, esq. Russell-square.
Woodhouse, W. esq. Liverpool.
Worthington, Thomas, esq. Mosley-street, Manchester.
Wright, George, esq. Birmingham.
Wright, Edmund, esq. Manchester.
Wright, H. esq. Ingram’s Buildings, Glasgow.
Wrighton, A. esq. Moor’s Place, Hope-street, Glasgow.
Wybergh, John, esq. Liverpool.
Wylie, John, esq. Liverpool.

Y
Yates, John, esq. Manchester.
 A MAP of the BRAZIL
Designed by Jas. Henderson
From the Materials of his
HISTORY of the BRAZIL.
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