dug 16 дек 2009 в 14:26

Работа с большими объёмами данных и хабраэффект

5 мин

1.9K

Google App Engine*

+45

Комментарии 49

Violinist 16 дек 2009 в 15:05

Спасибо Вам за подробную статистику.

dug 16 дек 2009 в 15:22

да статистика — моё второе имя ;) забыл про браузеры привести, но это и без меня наверняка сколько угодно раз посчитано

AlexVS85 16 дек 2009 в 15:06

Спасибо!
не знал что у GAE есть бесплатный пакет, будет время погуглю на эту тему,
но если кто уже пробовал какие там ограничения/недостатки, простенький сайтик (WordPress, PHP, GD, ..) типа thai-massage.kiev.ua/ на нём будет работать?

dzmitryc 16 дек 2009 в 15:13

PHP там нет — есть питон и ява.
Но можете погуглить «any-cms-is-google-app-engine-compatible» — первый результат — 9 цмс-ок.

zw0rk 16 дек 2009 в 15:18

Формально там есть PHP, через quercus. Однако, целесообразность и отношение профит/ресурсоемкость на один запрос для такого «решения» под большим вопросом.

dbarashev 16 дек 2009 в 16:24

Самое существенное ограничение для переноса простенького сайтика — это то что на GAE нет реляционной СУБД. Для тех приложений на которые GAE рассчитан это не showstopper и с этим можно жить, но нужно привыкать к несколько иному стилю обращения с данными.

В смысле ограничений бесплатной квоты, несколько десятков тысяч pageviews в день в квоту уложатся.

oleg_podsadny 16 дек 2009 в 18:18

Я делал свой микро-цмс. Была идея сделать сайт чисто на сервисах гугл, картинки к фотогалерее хостятся на пикасе, а ссылки на них подтягиваются через gdata api. В общем-то на гае можно что-то приличное даже сделать сочетая карту, календарь, документы, картинки, аналитику (да почти все гуглосервисы). Я рассматриваю ГАЕ как хороший клей для веб сервисов для мобилок. Все равно более 1000 записей экран и перфоманс андроида/айфона отображать не позволит.

dzmitryc 16 дек 2009 в 15:09

Гм. По-вашему выходит «хабраэфект» — 3-4 запроса в секунду?
Порядка 40 запросов в секунду тянет слабый VPS (и там работает связка nginx — java — mysql, ява, естественно, не просто статику отдаёт. про спринг/хибер я в то время ещё не знал).

А вообще — здорово.
В то время, как я просто «хочу попробовать что-нибудь сделать на гугл-апп-энджине», Вы показываете технологию, подогреваете интерес — спасибо :)

dug 16 дек 2009 в 15:14

Да, «хабраэффект» это 3-4 запроса в секунду. Тут со мной согласен автор упомянутой статьи, поэтому я более-менее в цифре уверен. Так что тем, чьи стайты не выдерживают упоминания на хабре стоило бы задуматься.

У GAE очень клёвая документация. Разве что вопрос с этим ограничением в 1000 записей нифига не раскрыт, только упомянут.

opeg 16 дек 2009 в 17:27

статику, можно и больше вытянуть, адинамически собираемые страницы при помоци скриптов после 5 страниц в секунду начинаются серьёзные оптимизации.

для полной загрузки одной насыщенной информацией страницы в требуется несколько десятков запросов
например
яндекс — 25 запросов
гугл — 7
рбк — 180

dzmitryc 16 дек 2009 в 18:02

Вы должны были обратить внимание, что речь шла о запросах к скрипту (то есть к динамике). А статика (картинки, css, скрипты) может хоть в стократном соотношении отдаваться с лёгких зеркал тем же nginx-ом.

BarsMonster 16 дек 2009 в 18:05

Да, хаброэффект — это 3-4 запроса в секунду. НО! Если если пользователи остаются на сайте и кликают раз 10-100, получим 40-400 запросов в секунду… А если на сайте что-то дежелое есть (типа видео) — вот все и лежит )

dug 16 дек 2009 в 21:56

Я немного запутался, вы, кажется, имеете отношение к статье, на которую я ссылался, да? Тут ситуация немного другая: само появление на главной к нагрузке не приводило, нужен был именно переход пользователей. Но эти пользователи переходили и во всё подряд там тыкали ;) Видимо поэтому цифры получились похожие.

Я даже удивился, при довольно скромной проявленной реакции (60 что ли голосов всего) 6.5 тысяч уникальных посетителей.

Сайт конечно совсем простенький, но на тот момент (до перехода на memcach) запросов 10 каждый зашедший пользователь к базе генерировал.

BarsMonster 16 дек 2009 в 22:08

Да, я писал «дедушку» вашей статьи :-)
А голоса — что на них смотреть, многие не имеют акка на хабре, многим лень кликать :-)

НЛО прилетело и опубликовало эту надпись здесь

dug 16 дек 2009 в 15:16

Сэр, в статье больше тысячи слов, и вы кроме этой цифры ничего любопытного не отметили?

НЛО прилетело и опубликовало эту надпись здесь

dug 16 дек 2009 в 21:51

Сэр, говорят же, 15 тысяч записей при фактическом ограничении на выборку в 1000 записей. Статья про это, а не про нагрузку. Графики я привёл для того чтобы показать как количество запросов распределяется в динамике.

НЛО прилетело и опубликовало эту надпись здесь

dug 16 дек 2009 в 22:29

Тогда понятно. Статья не про нагрузку, статья про статистику. «Хабраэффект» довольно смешное слово, никакого эффекта, о чём неоднократно уже выссказано. На GAE пишете?

НЛО прилетело и опубликовало эту надпись здесь

dbarashev 16 дек 2009 в 15:16

Согласившись с неудобством работы с данными в GAE вообще, и не особо богатым мониторингом ресурсопотребления, позволю заметить, что:

Во-первых в реляционной СУБД нет номера строки. Бывают создаваемые администратором ключи (возможно, суррогатные), которые могут быть или не быть отсортированными. То же самое можно делать и с GAE, если знать про некоторые тонкости генерирования очередного значения.

Во-вторых, если для анализа достаточно логов запросов, то их можно скачать при помощи appcfg

dug 16 дек 2009 в 15:20

Ну номер строки — абстрактно. Я же могу сделать в mysql «limit 8000, 100», а в GAE — не могу.

Про во-вторых, это всё сферические кони, в другом проекте статистика будет очень другая и лог запросов не поможет, хотя то, что можно скачать лог запросов я действительно не знал, спасибо.

dbarashev 16 дек 2009 в 16:19

Что-то мне подсказывает, что если запрос нетривиальный, то внутри MySQL будет происходить то же самое, то есть получит всё и вырежет нужное окошко. Так что врядли тут есть какое-то существенное отличие (если игнорировать другие существенные отличия :)

dug 16 дек 2009 в 16:23

А по-моему есть. MySQL этим всем заниматься будет сам, а в GAE сервер базы данных вернёт всё клиенту, то есть этот отступ — не его дело вобоще: спрошено, он выборку построит, дальше сами. А нетривиальные вопросы, кстати, тоже не по части GAE ;)

dbarashev 16 дек 2009 в 16:28

Ээээ… The fetch() method skips the first offset results, then returns the rest (limit results). Тот же самый LIMIT, или я чего-то не понимаю?

dug 16 дек 2009 в 16:33

Вот я и говорю: мутно и невнятно (в документации). От туда же:

«Приложение извлекает из хранилища данных offset + limit результатов. Первые offset результатов не пропускаются самим хранилищем данных.»

что в переводе на русский звучит так: The first offset results are not skipped by the datastore itself.

Я где-то в интернете находил фразу о том, что этим занимается уже клиент СУБД, после чего всё встало на свои места и стало понятно как быть.

dbarashev 16 дек 2009 в 16:36

Мне кажется что это претензии к переводчикам документации, умудрившимся datastore перевести как «приложение». Читайте англоязычную версию — там тоже иногда не фонтан, но всё ж таки текст адекватнее.

Violinist 16 дек 2009 в 15:27

А кто может сказать на телефоны каких операторов в Украине отправляется код подтверждения при регистрации и при этом успешно доходит?)

Jeteir 16 дек 2009 в 15:35

На МТС доходит точно, и точно не доходит на Билайн. Остальные — с переменным успехом (с неясной корреляцией от времени года).

Violinist 16 дек 2009 в 15:37

Билайн и Киевстар попробовал — не доходило, думал может вообще нельзя.

stoune 16 дек 2009 в 16:01

Попробуйте повторно. Я на Киевстаре зарегистрировался без проблем ещё когда по приглашениям вход был. Да и не должно там проблем быть, вон календарь регулярно мне СМС-ки кидает.

dug 16 дек 2009 в 15:56

надо график построить :)

aknizubr 16 дек 2009 в 15:44

Страница поддерживаемых операторов
www.google.com/support/calendar/bin/answer.py?answer=37226&hl=en#U

Ercitix 16 дек 2009 в 18:02

Регистрировался с Life, все получилось без проблем. Смс моментальна пришла.

Ercitix 16 дек 2009 в 18:04

*моментально )

intenter 16 дек 2009 в 15:37

Небольшой хинт для организации пейджинга. Если не стоит задачи выбирать по 1000 записей, то можно получать PAGE_SIZE+1 записей и на основании результата определять есть ли данные на следующей странице.

Вообще пейджинг на GAE — та еще задача. Впрочем, в Google давно уже обещают механизм для этого сделать какой-нибудь.

mrskam 16 дек 2009 в 15:49

Курсоры уже есть, читайте доку. Пока еще неофициальные, но уже работают.

dug 16 дек 2009 в 16:05

Так сходу нашлось в java, в питоне тоже работает?

mrskam 16 дек 2009 в 16:08

Да, with_cursors(), как-то так называется

dug 16 дек 2009 в 15:58

Ну если у нас страница — 100 записей, то получить 11-ю страницу уже не получится.

mrskam 16 дек 2009 в 16:09

Получится, надо использовать __key__

Dalairen 16 дек 2009 в 16:22

Да, я придира, но транслитерация «булшыт» полностью верна, однако, «булщит» читается лучше.))
А вообще сервис как минимум забавен.)
Вижу первые.

kutu 16 дек 2009 в 18:43

для более быстрого извлечения 1000+ записей используйте сортировку по __key__

ещё немного статистики:
у меня есть регулярный пик продолжительностью два часа по 10-12 запросов в секунду, проверяет хеш и выдает из мемкеша немного данных, после чего 40% процессорного времени исчерпывается, ошибок почти не бывает (максимум до 10 и то это не критично для меня)