@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
Fix a couple typos in "why so many databases?" document
Summary: One missing word, one `0` that should be a `)`, simplify a couple of mega-clauses to improve readability?
Test Plan: ((O)) . ((O))
Reviewers: michaeljs1990, chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15252
+15
-16
+15
-16
src/docs/flavor/so_many_databases.diviner
+15
-16
src/docs/flavor/so_many_databases.diviner
···
54
54
This storage design is aimed at large installs that may need more than one
55
55
physical database server to handle the load the install generates.
56
56
57
-
The primary reason we a database per application is to allow large installs to
58
-
scale up by spreading database load across more hardware. A large organization
59
-
with many thousands of active users may find themselves limited by the capacity
60
-
of a single database backend.
57
+
The primary reason we use a separate database for each application is to allow
58
+
large installs to scale up by spreading database load across more hardware. A
59
+
large organization with many thousands of active users may find themselves
60
+
limited by the capacity of a single database backend.
61
61
62
62
If so, they can launch a second backend, move some applications over to it, and
63
63
continue piling on more users.
···
80
80
===================
81
81
82
82
This design is also easier for us to work with, and easier for users who
83
-
want to work with the raw database data to understand and interact with.
83
+
want to work with the raw data in the database.
84
84
85
85
We have a large number of tables (more than 400) and we can not reasonably
86
86
reduce the number of tables very much (each table generally represents some
87
-
meaningful type of object in some application0. It's easier to develop with
87
+
meaningful type of object in some application). It's easier to develop with
88
88
tables which are organized into separate application databases, just like it's
89
89
easier to work with a large project if you organize source files into
90
90
directories.
91
91
92
92
If you aren't developing Phabricator and never look at the data in the
93
-
database, you probably don't benefit from this organization. However, if you
93
+
database, you probably won't benefit from this organization. However, if you
94
94
are a developer or want to extend Phabricator or look under the hood, it's
95
-
easier to find what you're looking for and work with the tables and data when
96
-
they're organized by application.
95
+
easier to find what you're looking for and work with the tables when they're
96
+
organized by application.
97
97
98
98
99
-
Databases Have No Cost
100
-
======================
99
+
More Databases Cost Nothing
100
+
===========================
101
101
102
-
In almost all cases, creating databases has zero cost, just like organizing
103
-
source code into directories has zero cost.
104
-
105
-
Even if we didn't derive enormous benefits from this approach at scale, there
106
-
is little reason //not// to organize storage like this.
102
+
In almost all cases, creating more databases has zero cost, just like
103
+
organizing source code into directories has zero cost. Even if we didn't derive
104
+
enormous benefits from this approach at scale, there is little reason //not//
105
+
to organize storage like this.
107
106
108
107
There are a handful of administrative tasks which are very slightly more
109
108
complex to perform on multiple databases, but these are all either automated