Comments 27
Спасибо, интересно! надо бы тоже заняться протухшими сессиями:)
Так вы каждую сущность вытаскиваете, анализируете и потом удаляете. Это всяко будет тупее чем SQL запрос.
а у вас там нет «сборщика мусора», чтобы протухшие сессии из базы выбивать автоматически?
У вас — это вы имеете ввиду ТС или о платформе?
Если о платформе — надо на крон вешать SessionCleanupServlet, который находится в SDK, и соответственно, расположен на каждом инстансе. Кажется есть тикет, где просят сделать полностью автоматическую чистилку для контейнера приложений.
Если о платформе — надо на крон вешать SessionCleanupServlet, который находится в SDK, и соответственно, расположен на каждом инстансе. Кажется есть тикет, где просят сделать полностью автоматическую чистилку для контейнера приложений.
UFO just landed and posted this here
В bigtable есть: www.google.com/search?sourceid=chrome&ie=UTF-8&q=bigtable+garbage+collection
Чтоб протащить его в megastore и в публичный доступ на GAE, наверное, нужны некоторые усилия :)
Чтоб протащить его в megastore и в публичный доступ на GAE, наверное, нужны некоторые усилия :)
Так а никто и не говорит, что map/reduce работает эффективнее. Да, там приличный оверхед, да, там кривые медленные алгоритмы, но зато оно реально масштабируемо, и при нынешних ценах на железо это зачастую оказывается важнее.
А речь и не про mapreduce, хотя в пожирании такого количества процессорного времени, вполне возможно, виновата конкретно эта реализация. Профайлинг покажет.
Речь о том, что в нынешних облаках программисту навязывается порочный стиль общения с БД, и ему приходится изобретать оптимизатор запроса самостоятельно — то что в реляционных СУБД нужно делать достаточно редко.
Речь о том, что в нынешних облаках программисту навязывается порочный стиль общения с БД, и ему приходится изобретать оптимизатор запроса самостоятельно — то что в реляционных СУБД нужно делать достаточно редко.
Скоро введут новое хранилище, возможно основанное на том, на чем сидит bigquery, там как-то очень быстро выполняются выборки на очень-очень больших объемах данных (count(*) на 60 млрд записях выполняется за 3-6 секунд), после также посмотрим, что будет со скоростью операций чтения-записи.
Вообще они с базой в последнее время очень хорошо поработали, скоро будет много вкусного (например разрешили проблему «взрывающихся индексов»).
А MP действительно с большим оверхедом, но с помощью него вы за линейное время сможете оперировать над массивом данных абсолютно любого размера, в отличии от мускуля и пр. Каждую технологию надо применять с умом.
Вообще они с базой в последнее время очень хорошо поработали, скоро будет много вкусного (например разрешили проблему «взрывающихся индексов»).
А MP действительно с большим оверхедом, но с помощью него вы за линейное время сможете оперировать над массивом данных абсолютно любого размера, в отличии от мускуля и пр. Каждую технологию надо применять с умом.
www.google.ru/search?q=appengine+java+sessions+cleanup первая же ссылка, не?
code.google.com/appengine/docs/java/datastore/queriesandindexes.html#Delete_By_Query — тоже не подходит?
code.google.com/appengine/docs/java/datastore/queriesandindexes.html#Delete_By_Query — тоже не подходит?
По поводу второй ссылки — хоть недавно лимит в 1000 и убрали, но 30 секунд на запрос никуда не делся, т.е ~25 секунд дается на использование внутреннего API. Это означает, что банально даже маленькую часть не успеем выбрать (практически все операции в store линейны по времени, ~40мс на запись весом 2 килобайта => 40.000 сек. на миллион записей), не говоря уже об удалении, что дает ~100мс на запись 2 кб =)
А по поводу первой ссылки — попробуйте :) Увидите, что за одно нажатие кнопки можно удалить 1000 записей. Нажимать кнопку 1400 раз мне не хочется :)
А за сколько отрабатывается одно нажатие? 1400 это не так и много, думаю получилось бы быстрее *) чем в статье…
Кнопку нажимать совсем необязательно. Если вызывать SessionCleanupServlet с параметром clear (как и пишет Jason по указанной ссылке), то, сделав соответствующий cronjob, срабатывающий, например, каждую минуту, можно было бы за сутки решить вашу проблему. При этом вы имели бы возможность контролировать расход CPU и в случе чего остановить обработку.
Я не пробовал, но почему-то думаю, что даже MySQL справится с… за несколько минут.
2 млн записей за минуту-полторы. Но если удалять их поштучно, как это делаете Вы, то пройдёт не один час.
Глазами поискал вывод, не нашёл. =( Так сколько USA-копеек-то это всё стоило?
после ввода обратно подсчета использования CPU при работе с datastore — удалять (ну и инсертить) стало ООЧЕНЬ дорого.
Можно было для сессий и memcache использовать.
контейнер приложений и использует мемкеш в связке с хранилищем. А чисто мемкеш нельзя — он у гугли не гарантирует сохранность данных на заявленное время, т.е. с небольшой вероятностью объект уже будет невозможно получить спустя очень небольшое время (секунды), хоть и клали мы его на полчаса, к примеру.
Sign up to leave a comment.
Чего стоит почистить datastore от сессий при помощи Mapper API