Перемещение таблицы MySQL в AWS DynamoDB - как это настроить?

Question

У меня есть эта таблица на экземпляре RDS:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| id           | bigint(20)          | NO   | PRI | NULL    | auto_increment |
| match_id     | bigint(10) unsigned | NO   | MUL | NULL    |                |
| prop_type_id | bigint(10) unsigned | NO   |     | NULL    |                |
| title        | varchar(45)         | NO   | MUL | NULL    |                |
| odds         | double              | YES  |     | NULL    |                |
| status       | tinyint(4) unsigned | YES  |     | 1       |                |
| selection_id | bigint(15)          | YES  | MUL | NULL    |                |
| market_id    | bigint(15)          | YES  | MUL | NULL    |                |
| date_time    | datetime            | NO   |     | NULL    |                |
| available    | int(11)             | NO   |     | NULL    |                |
| source       | tinyint(4)          | YES  |     | NULL    |                |
+--------------+---------------------+------+-----+---------+----------------+

Лучшая настройка, которую мы нашли для индексов, это установить их в match_id, prop_type_id, selection_id и market_id.

В настоящее время размер БД составляет около 1,5 ГБ, и мы получаем от 100 до 500 запросов в секунду к этой таблице, и вскоре это будет намного выше. Около 75% из них являются избранными, остальные обновления и удаления. Данные довольно изменчивы. Это приводит к зависаниям с MyISAM и множеству взаимоблокировок с InnoDB.

Я уже пробовал SimpleDB и, кроме того, что на изменение кода Rails для работы с ним ушло около 18 часов, теперь простой выбор занимает от 1 до 6 секунд, и это не всегда согласованно. Мне пришлось сильно его кэшировать, но это главный недостаток - мы хотим, чтобы данные обновлялись в БД, а также на экране не чаще, чем каждые 8 ​​секунд или около того.

Хотелось бы перенести это на DynamoDB, который, надеюсь, может работать намного лучше в сценариях с большим трафиком.

Теперь проблема в том, что нам нужно искать на основе следующего: - id (это может быть что угодно, если они уникальны, но мы не всегда используем его при запросах) - match_id - prop_type_id - title - selection_id - market_id - статус (0..2)

В общем, мы запрашиваем либо по match_id и prop_type_id, либо по match_id, prop_type_id, market_id и selection_id. Запросы, основанные на заголовке, редки, но их нельзя избежать. То же самое для статуса.

Есть ли способ, которым мы могли бы смоделировать это для DynamoDB?

Я знаю, что они дополнительно поддерживают только 5 индексов, а также требуют, чтобы идентификатор был известен всегда. Как я должен знать идентификаторы без предварительного просмотра данных, я не знаю, но, возможно, я делаю все это неправильно?

Спасибо!

Answer 1

Как вы заметили, локальный вторичный индекс не соответствует вашему шаблону запроса.

В настоящее время вам нужно будет создать свой собственный индекс, используя несколько таблиц DynamoDB, а это означает, что вашему приложению необходимо выполнять запись как в основную таблицу, так и в таблицу, которая действует как индекс для вашей основной таблицы. Например, ваша основная таблица может иметь "id" в качестве ключа хеш-функции, а ваша индексная таблица может иметь "match_id" в качестве ключа хеш-функции и "id" в качестве ключа диапазона.

Answer 2

Но я думаю, что ваш случай подходит для DynamoDB.

Это можно сделать так:

Положил match_id а также prop_type_id в один составной атрибут и сделайте этот атрибут ключом диапазона. Между тем пусть Id в качестве хэш-ключа.

Затем вы можете настроить вторичный локальный индекс на market_id с selection_Id "проецируется" также. Затем вы можете настроить другой вторичный локальный индекс на Title также.