Package: Evaluate impact of database decomposition
From &6289 (closed)
Background
The main goal of the grouptenant scale decomposition efforts is to split the database into two, for the first iteration, to address database scalability concerns. The first iteration focuses on a database for CI and a database for the rest of the functionality. There are likely customers that depend on all of the data coming from a single database. This issue is to gather information, determine the impact of decomposing the database and create issues to resolve those dependencies to work with the new architecture.
Implementation
- Architecture overview &6168 (closed).
- For the first iteration -
- All
ci_*
tables will be moved into a second logical database. - All the other tables remain in one logical database.
-
Migration plan of
ci_*
tables.
- All
- The most part of implementation is based on Rails 6 multi DB support so in simple terms we configure Rails to know which DB to use for each Rails model.
- Remove all foreign keys that cross-join from/to CI.
- Make schema migrations aware of multiple databases.
Request
- Determine whether the impact is on the critical path of the first iteration.
- Find a solution as the details become clear.
Examine how data is extracted from the database then think about how decomposed databases could impact your features.
- Do you see potential impacts from the decomposition PoC !62092 (closed)?
- Do you connect to the database directly?
- Does your feature require data joins from the two logical databases?
- Does your ActiveRecord query span tables in the two logical databases?
/cc @sgoldstein @trizzi