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