**I) Preparation (nothing is being written yet)**
# update write logic so that it would write to both schemas (wb_terms and normalized one) on configuration (Task T219297 and T219295)
## Migration Plan 1 ##
**II) Property Terms migration (small footprint on time and size)**
# write a maintenance scripts for populating the normalized tables with property terms (Task T219894)
# turn on configuration for writing to both schemas for properties & run the maintenance script for properties (part of Checkpoint T219301)
```
estimated increase in disk space usage =
ratio of properties/entities * current disk usage of wb_terms (incl. indexes) as of March 2019 * ratio of data size before/after normalization (accord. to test run and incl. indexes)
estimated increase in disk space usage =
0.0001 * 846GB * 0.2 = ~17.5MB
```
so roughly we need extra of 18MB for property terms migration. this extra size is not expected to grow significantly before we manage to reach the point to drop the whole wb_terms.
migration time is hard to estimate, but is not expected to be long for properties. We will measure and use that time to later estimate item migration time.
**III) Item Terms migration (big footprint on time and size)**
# write a maintenance scripts for populating the normalized tables with item terms (part of Checkpoint T219122)
# turn on configuration for writing to both schemas for items & run the maintenance script for items (part of Checkpoint T219123)
```
estimated increase in disk space usage =
ratio of items/entities * current disk usage of wb_terms (incl. indexes) as of March 2019 * ratio of data size before/after normalization (accord. to test run and incl. indexes)
estimated increase in disk space usage =
0.9999 * 846GB * 0.2 = ~170GB
```
so roughly we need extra of 170GB for item terms migration. expected increased to this number may be significant.
migration time is to be estimated based on proeprty terms migration is over and measured.
**rollback plan**
Stopping migration and rolling back is straightfowrad in this plan. We only to stop the migration script and stop writing to new schema, and can drop new schema tables if necessary too.
## Migration Plan 2 ##
**on write** write to new schema and delete from old one
**on read** read from both schemas
this plan will also go through two phases, the first for property terms and the second for item terms.
when old wb_terms is empty, read only from new schema and drop wb_terms table eventually
This plan will actually not require extra space (other than usual dbms needs for schema/meta info on tables and indexes) and will result in reducing the total space usage over time.
It is hard to estimate the footprint of this plan on performance, which is likely to be a little higher than the original one. If I can think of a way to estimate I will share some numbers soon.
**rollback plan**
Stopping and rolling back here is more complicated. If performance degradation was the reason to rollback, then we might be very much stuck. Reason is that we cannot just stop as in "we stop dealing with new schema immediately and just switch back to write and read from old wb_terms", because we would have already deleted some data from wb_terms and moved them over to new schema.
So stopping here would mean to "migrate back" in which we: **on write** we write to old schema and delete from new schema, and **on read** we read from both until new schema is empty. That would not release us immediately from the degradation in performance as we would wish.