revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-18 21:02:41 +01:00
Code Issues Releases Wiki Activity

Fix a couple typos in "why so many databases?" document

Browse source 
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
This commit is contained in:
epriestley 2016-02-11 13:47:53 -08:00
parent f5c8a2fb18
commit 8661170819
1 changed files with 15 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
src/docs/flavor/so_many_databases.diviner
View file

@ -54,10 +54,10 @@ Operating at Scale
This storage design is aimed at large installs that may need more than one This storage design is aimed at large installs that may need more than one
physical database server to handle the load the install generates. physical database server to handle the load the install generates.
The primary reason we a database per application is to allow large installs to The primary reason we use a separate database for each application is to allow
scale up by spreading database load across more hardware. A large organization large installs to scale up by spreading database load across more hardware. A
with many thousands of active users may find themselves limited by the capacity large organization with many thousands of active users may find themselves
of a single database backend. limited by the capacity of a single database backend.
If so, they can launch a second backend, move some applications over to it, and If so, they can launch a second backend, move some applications over to it, and
continue piling on more users. continue piling on more users.
@ -80,30 +80,29 @@ Ease of Development
=================== ===================
This design is also easier for us to work with, and easier for users who This design is also easier for us to work with, and easier for users who
want to work with the raw database data to understand and interact with. want to work with the raw data in the database.
We have a large number of tables (more than 400) and we can not reasonably We have a large number of tables (more than 400) and we can not reasonably
reduce the number of tables very much (each table generally represents some reduce the number of tables very much (each table generally represents some
meaningful type of object in some application0. It's easier to develop with meaningful type of object in some application). It's easier to develop with
tables which are organized into separate application databases, just like it's tables which are organized into separate application databases, just like it's
easier to work with a large project if you organize source files into easier to work with a large project if you organize source files into
directories. directories.
If you aren't developing Phabricator and never look at the data in the If you aren't developing Phabricator and never look at the data in the
database, you probably don't benefit from this organization. However, if you database, you probably won't benefit from this organization. However, if you
are a developer or want to extend Phabricator or look under the hood, it's are a developer or want to extend Phabricator or look under the hood, it's
easier to find what you're looking for and work with the tables and data when easier to find what you're looking for and work with the tables when they're
they're organized by application. organized by application.
Databases Have No Cost More Databases Cost Nothing
====================== ===========================
In almost all cases, creating databases has zero cost, just like organizing In almost all cases, creating more databases has zero cost, just like
source code into directories has zero cost. organizing source code into directories has zero cost. Even if we didn't derive
enormous benefits from this approach at scale, there is little reason //not//
Even if we didn't derive enormous benefits from this approach at scale, there to organize storage like this.
is little reason //not// to organize storage like this.
There are a handful of administrative tasks which are very slightly more There are a handful of administrative tasks which are very slightly more
complex to perform on multiple databases, but these are all either automated complex to perform on multiple databases, but these are all either automated