mirror of
https://github.com/sqlalchemy/sqlalchemy.git
synced 2026-05-17 14:17:29 -04:00
Mike Bayer
3088574414
* major additions to 1.4 migration doc; removed additional verbosity regarding caching methodology and reorganized the doc to present itself more as a "what's changed" guide * as we now have a path for asyncio, update that doc so that we aren't spreading obsolete information * updates to the 2.0 migration guide with latest info, however this is still an architecture doc and not a migration guide yet, will need further rework. * start really talking about 1.x vs. 2.0 style everywhere. Querying is most of the docs so this is going to be a prominent theme, start getting it to fit in * Add introductory documentation for ORM example sections as these are too sparse * new documentation for do_orm_execute(), many separate sections, adding deprecation notes to before_compile() and similar * new example suites to illustrate do_orm_execute(), with_loader_criteria() * modernized horizontal sharding examples and added a separate example to distinguish between multiple databases and single database w/ multiple tables use case * introducing DEEP ALCHEMY, will use zzzeeksphinx 1.1.6 * no name for the alchemist yet however the dragon's name is Flambé Change-Id: Id6b5c03b1ce9ddb7b280f66792212a0ef0a1c541
40 lines
1.8 KiB
Python
40 lines
1.8 KiB
Python
"""A basic example of using the SQLAlchemy Sharding API.
|
|
Sharding refers to horizontally scaling data across multiple
|
|
databases.
|
|
|
|
The basic components of a "sharded" mapping are:
|
|
|
|
* multiple :class:`_engine.Engine` instances, each assigned a "shard id".
|
|
These :class:`_engine.Engine` instances may refer to different databases,
|
|
or different schemas / accounts within the same database, or they can
|
|
even be differentiated only by options that will cause them to access
|
|
different schemas or tables when used.
|
|
|
|
* a function which can return a single shard id, given an instance
|
|
to be saved; this is called "shard_chooser"
|
|
|
|
* a function which can return a list of shard ids which apply to a particular
|
|
instance identifier; this is called "id_chooser".If it returns all shard ids,
|
|
all shards will be searched.
|
|
|
|
* a function which can return a list of shard ids to try, given a particular
|
|
Query ("query_chooser"). If it returns all shard ids, all shards will be
|
|
queried and the results joined together.
|
|
|
|
In these examples, different kinds of shards are used against the same basic
|
|
example which accommodates weather data on a per-continent basis. We provide
|
|
example shard_chooser, id_chooser and query_chooser functions. The
|
|
query_chooser illustrates inspection of the SQL expression element in order to
|
|
attempt to determine a single shard being requested.
|
|
|
|
The construction of generic sharding routines is an ambitious approach
|
|
to the issue of organizing instances among multiple databases. For a
|
|
more plain-spoken alternative, the "distinct entity" approach
|
|
is a simple method of assigning objects to different tables (and potentially
|
|
database nodes) in an explicit way - described on the wiki at
|
|
`EntityName <http://www.sqlalchemy.org/trac/wiki/UsageRecipes/EntityName>`_.
|
|
|
|
.. autosource::
|
|
|
|
"""
|