Масштабирование потока AWS Kinesis и улучшение производительности на потребительском конце
Часто, когда вам нужно показать так много точек на карте, вам лучше использовать серверный подход, в этой статье объясняется, когда использовать каждый:
Стратегии геокодирования: https://developers.google.com/maps/articles/geocodestrat
Предел на стороне клиента не соответствует «10 запросам в секунду», и поскольку он не объясняется в документах API Я не стал бы полагаться на его поведение.
1 ответ
Потребители Kinesis должны очень быстро потреблять данные, как если бы вы правильно использовали KCL, он фактически продает данные, которые он пересылает на потребительские процессы. Чтобы ответить на ваши вопросы:
- Убедитесь, что вы используете «push model» для своих потребителей. Это означает, что AWS позаботится о том, чтобы дозировать как можно больше записей, чтобы уменьшить IO сети и обеспечить быструю обработку. В моих приложениях он может загружать 700 записей за раз, обеспечивая тем самым быструю обработку. См. Ссылку здесь с деталями модели push / pull.
- Существуют решения ad-hoc для автомасштабирования осколков (не уверены, теперь теперь с кинезисом), но вы бы хотели отслеживать такие показатели, как MillsBehindLatest для каждого осколка, и это было бы на стороне потребителя. Однако это становится сложно, так как вам нужно проверить каждый осколок в потоке. Кроме того, вам также необходимо будет контролировать сторону производителя
. Мое мнение остается простым, просто предоставляя более чем достаточную емкость, так как Kinesis способен обрабатывать множество данных даже на нескольких осколках и обеспечении несколько экземпляров для обработки данных в разных зонах доступности. Увеличьте количество обломков / экземпляров, поскольку данные изменяются со временем.