Использовать больше потоков
Я бы посоветовал инвертировать соотношение потоков / доменов от 1/6 до значения, близкого к 30/1.Большая часть времени, необходимого для извлечения больших объемов данных из SimpleDB, будет потрачена на ожидание.В этой ситуации увеличение числа потоков значительно улучшит вашу пропускную способность.
Одним из ограничений SimpleDB является ограничение размера ответа на запрос в 1 МБ.Это означает, что удаление 50 МБ в одном домене займет не менее 50 вариантов (оригинал + 49 дополнительных страниц).Это должно происходить последовательно, потому что NextToken из текущего ответа необходим для следующего запроса.Если каждый выбор занимает более 2 секунд (что не редкость при больших ответах и большом объеме запросов), вы тратите 2 минуты на каждый домен.Если каждый поток должен выполнить итерацию по каждому из 6 доменов по очереди, это займет около 12 минут.Один поток на домен должен легко сократить это до приблизительно 2 минут.
Но вы должны быть в состоянии сделать намного лучше, чем это.SimpleDB оптимизирован для параллелизма.Я бы попробовал 30 потоков на домен, давая каждому потоку часть часа для запроса, так как в конце концов это данные журнала.Например:
SELECT * FROM domain WHERE timestamp between '12:00' and '12:02'
(очевидно, вы будете использовать значения меток реального времени). Все 30 запросов могут быть запущены без ожидания каких-либо ответов.Таким образом, вам все равно нужно сделать не менее 50 запросов на домен, но вместо того, чтобы делать их все последовательно, вы можете получить гораздо больше параллелизма.Вам придется самостоятельно проверить, сколько потоков обеспечивает наилучшую пропускную способность.Я бы посоветовал вам попробовать до 60 на домен, нарушив условия выбора с шагом в одну минуту.Если это работает для вас, то у вас будут полностью параллельные запросы, и, скорее всего, вы удалили все последующие страницы.Если вы получаете 503 ошибки ServiceUnavailable, уменьшите потоки.
Домен является базовой единицей масштабируемости для SimpleDB, поэтому хорошо, что у вас есть удобный способ разделения данных.Вам просто нужно воспользоваться преимуществами параллелизма.Вместо 13 минут я бы не удивился, если бы вы смогли получить данные за 13 секунд для приложения, работающего на EC2 в том же регионе.Но фактическое время, которое потребуется, будет зависеть от ряда других факторов.
Затраты на рассмотрение
В качестве дополнительного примечания я должен упомянуть стоимость того, что вы делаете, даже если у вас нетТ поднял вопрос.CreateDomain и DeleteDomain - тяжелые операции.Обычно я бы не советовал использовать их так часто.Плата за использование ящика составляет около 25 секунд каждый раз, поэтому создание и удаление по одному каждый час в сумме составляет около 70 долларов в месяц только для управления доменом.Вы можете хранить на порядок больше данных в домене, чем те 50 МБ, которые вы упомянули.Таким образом, вы можете захотеть позволить данным накапливаться больше, прежде чем удалять.Если ваши запросы включают метку времени (или могут быть сделаны так, чтобы включать метку времени), производительность запросов может не пострадать, если в домене будет лишний ГБ старых данных.В любом случае, GetAttributes и PutAttributes никогда не пострадают от снижения производительности при большом размере домена, только запросы не используют выборочный индекс.Вы должны проверить свои запросы, чтобы увидеть.Это всего лишь предположение, я понимаю, что создание / удаление является концептуально более чистым.
Кроме того, одновременная запись 200 атрибутов является дорогостоящей из-за причуды в формуле использования блока.Использование поля для записи пропорционально количеству атрибутов, возведенных в степень 3!Формула в часах:
0.0000219907 + 0.0000000002 N^3
Для базового сбора плюс плата за атрибут, где N - количество атрибутов. В вашей ситуации, если вы напишите все 200 атрибутов в одном запросе, плата за использование ящиков составит около 250 долларов за миллион предметов (470 долларов за миллион, если вы напишите 256 атрибутов). Если вы разбите каждый запрос на 4 запроса с 50 атрибутами каждый, вы в четыре раза увеличите свой объем PutAttributes, но сократите расходы на использование ящиков на порядок до примерно 28 долларов за миллион элементов. Если вы можете разбить запросы, возможно, это стоит сделать. Если вы не можете (из-за объема запросов или просто характера вашего приложения), это означает, что SimpleDB может оказаться крайне непривлекательным с точки зрения затрат.