Иван, спасибо за столь подробный разгон по гипотетике!
Полностью поддерживаю мысль про стоимость PUT-запросов в S3 – реальная бомба под бюджет. Даже на средней нагрузке куча мелких файлов может вынести счёт за облако в стратосферу, в прямом и переносном смысле.
По ощущениям, без какой-то умной буферизации/агрегации батчей жить будет нереально – либо это будут сотни тысяч $$ за месяц только на storage API calls.
Кстати, а есть ли у вас мысли, можно ли как-то ещё "смягчить" эту проблему, кроме классической буферизации? (например, более агрессивная упаковка батчей, или какие-то спец-режимы загрузки?)
Ещё раз огромное спасибо за такое подробное роазъяснение!
Иван, спасибо огромное за столь развернутые ответы! 🙌
Чисто из любопытства: если бы вдруг можно было полностью убрать партиции и лидеров, построив Kafka чисто на S3 – насколько сильно это изменило бы архитектуру?
У меня есть опыт работы с AWS Customer Engineering team. Ничего не хочу сказать про упомянутого в статье человека, да и AWS CET, в целом, отличные ребята, но у меня закрадывается подозрение, что туда порой набирают именно тех, кто только что окончил трех-часовые bootstrap курсы на Udemy.
Хорошая статья для новичков. Но, для запросов get я бы предпочёл нативную интеграцию API Gateway -> DynamoDB. Плюсы такой интеграции - минимальный latency, нет glue code (читай не платим за лямбду), ну и, в конце концов, это красиво ;) Но, это мое, чисто субъективное, мнение.
Возможно ли после создания аккаунта через бота @Telegraph получить его access_token, чтобы была возможность постить и по API, и на девайсе? Либо, можно ли создать бота через API и подключить его в боте?
Сорри, может не вижу очевидного ))
А если серьезно, то пока предпосылок к беспокойству нет. Равно как и предпосылок к неистовой радости.
Для собственного успокоения стоит задуматься о быстром переходе к другой платежной системе.
Для разбора xls пользуюсь классом excel_reader2.
Все безумно просто и понятно.
На практике проверялись файлы в несколько мегабайт и с количеством строк до 30000.
одно «но». это в случае, когда для всех сайтов таблицы общие. у меня была задача один и тот же контент представить на разных доменах с отличающимся дизайном.
Если вы используете различные темы для сайтов, то не мешало бы определить их напрямую в settings.php и настроить выполнение регулярных процедур cron.php минимум на раз в сутки.
@Ivanhoeа вы в на Current в UK не собираетесь? Был бы рад пообщаться.
Иван, спасибо за столь подробный разгон по гипотетике!
Полностью поддерживаю мысль про стоимость PUT-запросов в S3 – реальная бомба под бюджет. Даже на средней нагрузке куча мелких файлов может вынести счёт за облако в стратосферу, в прямом и переносном смысле.
По ощущениям, без какой-то умной буферизации/агрегации батчей жить будет нереально – либо это будут сотни тысяч $$ за месяц только на storage API calls.
Кстати, а есть ли у вас мысли, можно ли как-то ещё "смягчить" эту проблему, кроме классической буферизации? (например, более агрессивная упаковка батчей, или какие-то спец-режимы загрузки?)
Ещё раз огромное спасибо за такое подробное роазъяснение!
Иван, спасибо огромное за столь развернутые ответы! 🙌
Чисто из любопытства: если бы вдруг можно было полностью убрать партиции и лидеров, построив Kafka чисто на S3 – насколько сильно это изменило бы архитектуру?
Привет! Спасибо большое, что заглянули в обсуждение! Если будет возможность, хотел бы уточнить пару моментов:
Через сколько версий, по вашему мнению, diskless-топики будут готовы к стабильному продакшену?
Какие юзкейсы лучше всего подходят под такую архитектуру? Где бы вы не советовали её использовать?
Какие сейчас наблюдаются средние задержки доставки сообщений на прототипах?
Какой объём событий рассчитан на Batch Coordinator? Можно ли его будет горизонтально масштабировать?
Заранее спасибо за ответы! Даже если не на всё сразу, всё равно очень ценно услышать ваше мнение.
Если кто-то уже экспериментировал с diskless-топиками (или Tiered Storage), расскажите, как ощущения? Интересно посмотреть на реальный опыт.
У меня есть опыт работы с AWS Customer Engineering team. Ничего не хочу сказать про упомянутого в статье человека, да и AWS CET, в целом, отличные ребята, но у меня закрадывается подозрение, что туда порой набирают именно тех, кто только что окончил трех-часовые bootstrap курсы на Udemy.
Хорошая статья для новичков. Но, для запросов
getя бы предпочёл нативную интеграцию API Gateway -> DynamoDB. Плюсы такой интеграции - минимальный latency, нет glue code (читай не платим за лямбду), ну и, в конце концов, это красиво ;) Но, это мое, чисто субъективное, мнение.Сорри, может не вижу очевидного ))
А если серьезно, то пока предпосылок к беспокойству нет. Равно как и предпосылок к неистовой радости.
Для собственного успокоения стоит задуматься о быстром переходе к другой платежной системе.
Извините, если потревожил чувства.
Все безумно просто и понятно.
На практике проверялись файлы в несколько мегабайт и с количеством строк до 30000.
В деталях не разбирался, ибо другие задачи подгоняют.