I just took a quick look at the ORES database schema an noticed a few things. Maybe not all of them are applicable, but please have a look at them.
This is especially important as ORES is going to create multiple `ores_classification` rows for each revision in Wikidata's `recentchanges` table (thus many rows and especially a lot of writes/ reads).
* `ores_classification` and `ores_model` need to have a primary key (that is a **must** before deployment for all tables).
* `ores_classification.ores_model` and `ores_classification.ores_model_version` could probably be removed in favor of a key pointing to `ores_model`. (Especially in case there are significantly less rows expected in `ores_model` than in `ores_classification`)
** For that you probably want to have one table in `ores_model` for each version of each model (and not just one for the current versions).
** If you don't do that, please still make sure you rename one of them to not have the same field names in more than one table.
* `ores_classification.ores_rev` should be unsigned to match rev_id
* You might want to use different name prefixes for fields in both tables (and not just the generic `ores_`). See also my point about `ores_model` and `ores_model_version` above.
* The index `ores_is_predicted` probably is not of much use alone and should be dropped (queries will use `ores_winner` wont they?). This obviously depends on what queries you plan to do.
Files I reviewed:
https://github.com/wikimedia/mediawiki-extensions-ORES/blob/8a08f7f0a28030aa9f607a1ae3c037e9a521dbf8/sql/ores_model.sql
https://github.com/wikimedia/mediawiki-extensions-ORES/blob/8a08f7f0a28030aa9f607a1ae3c037e9a521dbf8/sql/ores_classification.sql