На мой взгляд оправдана — по многим причинам. Не только SEO но и психологическим — люди с большей вероятностью идут на сайт и пишут/регистрируются там если видят что он локальный. Мы в операционном плюсе, а значит можно считать это доказаным — для нас это себя оправдало. В общем так (нам) проще раскручиваться: с миру по нитки — нищему рубашка.
А смысл есть? Делали анализ не дешевле было бы хранить несжатым?
Насколько я понимаю выигрыш будет если данные хранятся долго и читаются редко. Было бы интересно увидеть анализ на эту тему. Что то вроде «при хранени 100KB обычного теста компрессия становится выгодной если вы храните дольше чем Х дней».
> Snappy is widely used inside Google, in everything from BigTable and MapReduce to our internal RPC systems.
Вполне вероятно оно уже там есть просто для нас прозрачно и не афишируется. Возможно с пользователя берётся и за время (CPU) комрессии-декомпрессии и за полный несжатый размер хранения данных.
Если же дать нам в руки то получится что за storage брать будут меньше.
Ну я не профессионал маркетинга, уверен быть не могу, но думаю интерес возможен.
Если сделать для простых пользователей чтобы они могли смотреть инфу по себе и своим друзьям и могли публиковать в ЖЖ, то так можно бесплатно пиариться.
А маркетологи возможно захотят делать какие-то срезы по ключевым словам например. Скажем я хочу узнать кто топовый блоггеры по тебе BMW и какая у них аудитория — за это и деньги могут заплатить.
Думайте о том какие проблемы вы можете решить. Мне кажется тут есть куда копать.
Если бы я начинал выяснять детали каждого голословного утверждения мне бы ни на что полезное времени бы не оставалось.
Ваше право доверять таким утверждениям. Я не вижу в них логики. Мне кажется с точки зрения Гугла им всё равно, по большому счёту, эффективно ваше приложение или нет — вы платите за потребляемые ресурсы. Они конечно же хотят помочь вам сделать приложение эффективным и выводят предупреждения, но они ничего не знают о его внутренней логике и не могут сделать вывод эффективно оно или нет (может быть очень много высокоэффективных действий). И не зря же они постоянно увеличивают предельное время исполнения запроса и в роудмапе есть long running requests.
Не знаю что он услышал от Михаила, но выводы расходятся с логикой, официальной политикой и road-map.
О какой масштабируемости можно было бы говорить если бы GAE несправлялся с отдачей картинок для главной Хабра? Почитайте какие решения строятся на гаешечке и поймёте что хабраэффект для него это просто детский лепет.
Хабраэффект имеет место быть в данном случае, но только потому что у автора закончилисась квота и никак не из-за технических ограничений платформы.
Думать заранее. Разделять деплойменты изменения схемы и функциональности приложения. В новой версии ветки if для поддержки старых версий. Дубликация данных — сохранение старых полей и их значений до тех пор пока не будет уверенности что всё ОК. И т.п.
Ну надо понимать что нет общих способов быстро откатить неограниченное количество транзакций.
С опытом приходит понимание как делать изменения в схеме (которой кстати нет) так чтобы могли жить старая и новая версии. Поначалу пару раз попал в такую проблему, но последние пол-года ни разу проблем не было.
В GAE покоряет простота deployment процесса и возможность версионности. Очень приятно осозновать что за пару секунд можно откатиться к предыдущей версии.
Ну и бесплатные лимиты очень приличные. У меня на сайтах примерно 600,000 показов страниц в месяц показываются бесплатно. И есть куда оптимизировать. Сами ограничения архитектуры подталкивают тебя в правильном направлении. Это очень здорово. И не надо думать о масштабируемости. Вернее надо, но не о низкоуровневых деталях, а в более высоких абстакциях.
Кстати стоит учитывать что стоимость записи прямо зависит от количества индексов.
Насколько я понимаю выигрыш будет если данные хранятся долго и читаются редко. Было бы интересно увидеть анализ на эту тему. Что то вроде «при хранени 100KB обычного теста компрессия становится выгодной если вы храните дольше чем Х дней».
> Snappy is widely used inside Google, in everything from BigTable and MapReduce to our internal RPC systems.
Вполне вероятно оно уже там есть просто для нас прозрачно и не афишируется. Возможно с пользователя берётся и за время (CPU) комрессии-декомпрессии и за полный несжатый размер хранения данных.
Если же дать нам в руки то получится что за storage брать будут меньше.
И всё такие если серьёзно подойти то что-то полезное я думаю можно сделать. Вопрос конечно окупаемости как всегда.
Если сделать для простых пользователей чтобы они могли смотреть инфу по себе и своим друзьям и могли публиковать в ЖЖ, то так можно бесплатно пиариться.
А маркетологи возможно захотят делать какие-то срезы по ключевым словам например. Скажем я хочу узнать кто топовый блоггеры по тебе BMW и какая у них аудитория — за это и деньги могут заплатить.
Думайте о том какие проблемы вы можете решить. Мне кажется тут есть куда копать.
Ваше право доверять таким утверждениям. Я не вижу в них логики. Мне кажется с точки зрения Гугла им всё равно, по большому счёту, эффективно ваше приложение или нет — вы платите за потребляемые ресурсы. Они конечно же хотят помочь вам сделать приложение эффективным и выводят предупреждения, но они ничего не знают о его внутренней логике и не могут сделать вывод эффективно оно или нет (может быть очень много высокоэффективных действий). И не зря же они постоянно увеличивают предельное время исполнения запроса и в роудмапе есть long running requests.
Не знаю что он услышал от Михаила, но выводы расходятся с логикой, официальной политикой и road-map.
То что его приложение стало выдавать HTTP 500 ещё ни о чём не говорит. Могли быть его внутренние проблемы или проблемы с базой или ещё что-то.
> Приложение было ограничено как неэффективное.
Можно ссылку на описание где и как GAE «ограничивает приложения как неэффективные»?
Вы же не контролируете жизнь инстанса так что делать выводы о «прошло недостаточно времени» не совсем корректно.
Хабраэффект имеет место быть в данном случае, но только потому что у автора закончилисась квота и никак не из-за технических ограничений платформы.
Не просто, но возможно.
С опытом приходит понимание как делать изменения в схеме (которой кстати нет) так чтобы могли жить старая и новая версии. Поначалу пару раз попал в такую проблему, но последние пол-года ни разу проблем не было.
Ну и бесплатные лимиты очень приличные. У меня на сайтах примерно 600,000 показов страниц в месяц показываются бесплатно. И есть куда оптимизировать. Сами ограничения архитектуры подталкивают тебя в правильном направлении. Это очень здорово. И не надо думать о масштабируемости. Вернее надо, но не о низкоуровневых деталях, а в более высоких абстакциях.
Кстати стоит учитывать что стоимость записи прямо зависит от количества индексов.