Comments 34
«Сервис для работы с большими файлами.»
Наконец то!
Наконец то!
0
XMPP, как я поинмаю, чтобы к Google Wave прицепить?
0
Поскольку Google Wave построен на базе XMPP, то скорее всего вы правы. Из рабочих вариантов пока явно Google Talk напрашивается, а для Wave скорее всего сделают отдельный сервис на основе XMPP API.
0
Прикольный двигателет, как у Дима Червяка.
+2
О, можно будет сделать jabber-бота? Или пока будет поддерживаться только отправка собщений?
0
Скорее всего можно будет, не вижу ни каких проблем
0
Об этом не пишут. Мое мнение, что будет только отправка. Идея встроить в App Engine сервисы, которые могли бы обрабатывать входящие e-mail (не как клиент к gmail, а как сервер) и XMPP боты выглядит очень привлекательно, но в то, что это будет скоро реализовано, верится с большим трудом.
0
А можно оттуда выгрузить код, который ранее загрузил? (чтобы поправить и обновить)
0
Не представляю что еще можно подразумевать в пункте 6 (Дамп всех неперехваченных исключений будет фиксироваться и отображаться в административной панели) кроме того, что уже реализовано сейчас: не то что неперехваченные исключения, вообще все нештатные ситуации с легкостью читаются в специальном разделе логов.
+1
Дополню по презентациям из google io (из разделов The Future):
Презентация Java:
• Task queues
• Full text search
• Incoming e-mail
• XMPP
• Large file storage and retrieval
• Datastore export tools
Презентация Offline Processing:
— Coming soon
• Release of Task Queue API in App Engine Labs
• Python-only at first, Java soon after
— Java support in the works
• Web hooks interface
• JMS integration
— More API features
• Queue management functions (e.g., flush)
• Queue contents viewing in admin console
• Notification of queue events (e.g., empty)
— Batch processing
• Task API good for small datasets (< 100k rows)
• More tools required for parallelization, high throughput processing of Datastore entities
• Need rich features for aggregations, statistics
— Map Reduce
• Plan to eventually support MapReduce abstraction
• Need more tools: intermediary storage, sorting, etc
• Want it to work with small (50k entities) and very large (> 1TB) datasets
Презентация Java:
• Task queues
• Full text search
• Incoming e-mail
• XMPP
• Large file storage and retrieval
• Datastore export tools
Презентация Offline Processing:
— Coming soon
• Release of Task Queue API in App Engine Labs
• Python-only at first, Java soon after
— Java support in the works
• Web hooks interface
• JMS integration
— More API features
• Queue management functions (e.g., flush)
• Queue contents viewing in admin console
• Notification of queue events (e.g., empty)
— Batch processing
• Task API good for small datasets (< 100k rows)
• More tools required for parallelization, high throughput processing of Datastore entities
• Need rich features for aggregations, statistics
— Map Reduce
• Plan to eventually support MapReduce abstraction
• Need more tools: intermediary storage, sorting, etc
• Want it to work with small (50k entities) and very large (> 1TB) datasets
0
Позволил себе перевести. Перевод очень вольный, сильно не ругать :)
Презентация Java:
• Очереди задач
• Полнотекстовый поиск
• Входящая электронная почта
• XMPP
• Хранение и получение больших файлов
• Инструменты экспорта хранилищ данных
Презентация Offline Processing:
— Скоро
• Релиз Task Queue (очередь задач) API в App Engine Labs
• Сначала Python, Java после
— Поддержка Java в работе
• Интерфейс Web hooks
• Интеграция Java Message Service
— Дополнительные функции API
• Функции управления очередью
• Просмотр содержимого очереди в консоле администратора
• Уведомление о событиях очереди
— Пакетная обработка
• Task API хороша для небольших наборов данных (<100K строк)
• Дополнительные инструменты, необходимые для параллелизации, высокая пропускная способность обработки хранилищ данных
• Необходимость в богатых возможностях агрегирования и статистики
— Map Reduce
• План, в конечном итоге поддерживать MapReduce абстракцию
• Нужно больше инструментов: промежуточного хранения, сортировки и т. д.
• Необходим для работы с небольшими (50K) и очень крупными (> 1TB) данными
Презентация Java:
• Очереди задач
• Полнотекстовый поиск
• Входящая электронная почта
• XMPP
• Хранение и получение больших файлов
• Инструменты экспорта хранилищ данных
Презентация Offline Processing:
— Скоро
• Релиз Task Queue (очередь задач) API в App Engine Labs
• Сначала Python, Java после
— Поддержка Java в работе
• Интерфейс Web hooks
• Интеграция Java Message Service
— Дополнительные функции API
• Функции управления очередью
• Просмотр содержимого очереди в консоле администратора
• Уведомление о событиях очереди
— Пакетная обработка
• Task API хороша для небольших наборов данных (<100K строк)
• Дополнительные инструменты, необходимые для параллелизации, высокая пропускная способность обработки хранилищ данных
• Необходимость в богатых возможностях агрегирования и статистики
— Map Reduce
• План, в конечном итоге поддерживать MapReduce абстракцию
• Нужно больше инструментов: промежуточного хранения, сортировки и т. д.
• Необходим для работы с небольшими (50K) и очень крупными (> 1TB) данными
+3
интересно, а когда же апл стор введет поддержку карточек Visa Electron (сколько я а iTunes не старался регнуться визу электрон от сбербанка он не распознает) вот такая пища к размышлению.
0
Никогда не введет, ибо это невозможно. По российским банковским «правилам» Electron является только ATM без возможности оплаты в сети. Виза в 2004 помоему рекомендовала исправить ситуацию, но многие наши банки положили на это с прибором. И до сих пор многие российские Electron карты не биллятся в сети. Привяжите к своей карте онлайн-банкинг с виртуальным счетом или смените карту.
0
Обидно, но в моей организации з\п начисляется либо на визу электрон либо на сберкнижку… так что виза электрон лучший вариант для меня :(
можно поподробнее про Онлайн-банкинг, привязку к нему и будет ли ап стор кушать эту привязку?
если можно чтобы не разводить тут флуд, ответь в ЛС пожалуйста.
можно поподробнее про Онлайн-банкинг, привязку к нему и будет ли ап стор кушать эту привязку?
если можно чтобы не разводить тут флуд, ответь в ЛС пожалуйста.
0
На самом деле не очень понятнен вопрос про Apple store в контексте AppEngine.
А по сути — надо идти в банк и просить подключить онлайн-банкинг и виртуальный счет для платежей в интернете. Они все расскажут и покажут. Будет ли appstore принимать деньги с вирт.сбербанковского счета — скорее всего да, узнавайте в банке. Ни разу с appstore не сталкивался и услугами сбербанка не пользовался.
А по сути — надо идти в банк и просить подключить онлайн-банкинг и виртуальный счет для платежей в интернете. Они все расскажут и покажут. Будет ли appstore принимать деньги с вирт.сбербанковского счета — скорее всего да, узнавайте в банке. Ни разу с appstore не сталкивался и услугами сбербанка не пользовался.
0
// либо на визу электрон либо на сберкнижку
Очень странно. Именно Электрон? А обычная Виза почему не подходит? Бухгалтерии должно быть совершенно пох — они же на счет в банке деньги переводят, а не на карту.
Или просто заведите себе вторую карту. Моя сбербанковская стандартная Виза проходит везде в инете, где бы ни платил.
Очень странно. Именно Электрон? А обычная Виза почему не подходит? Бухгалтерии должно быть совершенно пох — они же на счет в банке деньги переводят, а не на карту.
Или просто заведите себе вторую карту. Моя сбербанковская стандартная Виза проходит везде в инете, где бы ни платил.
0
у нас гос учреждение с своими правилами к сожалению и по правилам которые мне пришлось подписать я имею право иметь только 1 счет банка (виза электро в моем случае) и я не могу иметь побочный заработок, вот такая фигня…
0
Есть жёны, родственники, домашние питонцы))
Что мешает оформить счёт на них?
Что мешает оформить счёт на них?
0
жены нет, родственники оч далеко.
0
Что за бред, никакими правилами не может быть запрещено привязка виртуального счета к карте, это личная карта и в пределах онлайн-банкинга перенос денег между счетов это личное дело. В конце концов по второй счет будете знать только вы, и привяка обоих будет к карте. На крайняк надо пойти в бухгалтерию (к директору) и рассказать плаксивую историю что не можете купить хлебушка в интернете на кровные денюшки. Ибо русский электрон не биллится в инете. Идите в банк и привязывайте e-банкинг. В сбербанке он назывется помоему «Сбербанк @nline»
0
Рекомендую взглянуть на открытый и свободный MongoDB ( www.mongodb.org/ ) всем интересующимся Google App Engine (GAE). MongoDB выглядит почти идентично Datastore в GAE, ничуть не уступая, а местами превосходя его по функционалу (взять то же хранение файлов и курсоры, которые в MongoDB уже давно есть, удобный API). Те же возможности + масштабируемость. Естественно, такой вариант только для тех, кто сам может (и хочет) обеспечить хостинг. Зато и ограничений платформы — никаких.
0
В этом плане более перспективна связка hadoop+hbase+jdo
0
Это уже вопрос вкуса. Скажу по себе — я недели две убил на изучение всех подобных проектов — а их немало. Это HBase, Cassandra, Redis, Hypertable, CouchDB, Project Voldemort, Tokyo Cabinet. Какие-то проекты строят mapreduce-схему на базе Hadoop, какие-то — сами. Кто-то опирается на HDFS, а кто-то — на свою схему хранения (например, Tokyo Cabinet).
Я пришёл к выводу, что на данный момент MongoDB наиболее развит, так как:
* Он быстр: www.mongodb.org/display/DOCS/Performance+Testing Кому-то может показаться важным и то, что он написан на C++ (Хотя я считаю мифом, что Java или Erlang-приложения работают медленнее).
* Он прекрасно документирован — и по объёму документации, и по полноте, и по качеству написания. По сравнению с документацией MongoDB, у HBase и прочих её нет совсем.
* Он поддерживает индексы. Даже по внутренним полям документов со сложной, вложенной структурой. Например, я могу создать индекс по полю info.weight.max в документе вида {'name':'товар',… 'info':{'weight':{'max':10...}...}}, а потом искать и сортировать по такому индексу. Индексы обновляются автоматически.
* Он поддерживает достаточно сложные запросы (например: {'tags':{"$in":[«gae»,«хостинг»]}, «pubdate»:date}), умея делать всё то же самое, что и GAE «из коробки». А ведь большая часть подобных проектов не выходит за рамки хранилищ вида «ключ-значение». Кстати, в приведённом примере идёт поиск по индексу, составленному по массиву, причём кроме IN поддерживаются операции NIN (Not IN) и ALL.
* Даже для вложенных документов допустимы атомарные операции inc, set и push (у массивов).
* Он также линейно масштабируется. Причём может автоматически менять мастер-сервер при его падении (automatic fail-over).
* А ещё он просто и приятно устанавливается :) Чтобы начать его использовать — достаточно всего 2-3 минут.
Не хочу разводить священных войн. Лично на меня MongoDB произвёл очень хорошее впечатление. Настолько хорошее, что я даже решил сесть и написать для него Django-бекенд ( bitbucket.org/kpot/django-mongodb/ )
Я пришёл к выводу, что на данный момент MongoDB наиболее развит, так как:
* Он быстр: www.mongodb.org/display/DOCS/Performance+Testing Кому-то может показаться важным и то, что он написан на C++ (Хотя я считаю мифом, что Java или Erlang-приложения работают медленнее).
* Он прекрасно документирован — и по объёму документации, и по полноте, и по качеству написания. По сравнению с документацией MongoDB, у HBase и прочих её нет совсем.
* Он поддерживает индексы. Даже по внутренним полям документов со сложной, вложенной структурой. Например, я могу создать индекс по полю info.weight.max в документе вида {'name':'товар',… 'info':{'weight':{'max':10...}...}}, а потом искать и сортировать по такому индексу. Индексы обновляются автоматически.
* Он поддерживает достаточно сложные запросы (например: {'tags':{"$in":[«gae»,«хостинг»]}, «pubdate»:date}), умея делать всё то же самое, что и GAE «из коробки». А ведь большая часть подобных проектов не выходит за рамки хранилищ вида «ключ-значение». Кстати, в приведённом примере идёт поиск по индексу, составленному по массиву, причём кроме IN поддерживаются операции NIN (Not IN) и ALL.
* Даже для вложенных документов допустимы атомарные операции inc, set и push (у массивов).
* Он также линейно масштабируется. Причём может автоматически менять мастер-сервер при его падении (automatic fail-over).
* А ещё он просто и приятно устанавливается :) Чтобы начать его использовать — достаточно всего 2-3 минут.
Не хочу разводить священных войн. Лично на меня MongoDB произвёл очень хорошее впечатление. Настолько хорошее, что я даже решил сесть и написать для него Django-бекенд ( bitbucket.org/kpot/django-mongodb/ )
+1
Я пока поверхностно на такие системы посмотрел. Просто показалось, что в будущем hbase и hadoop будет лучше поддерживаемой системой — станет в будущем менстримом. По hadoop и hbase кстати книга есть (только-только вышла) на amazon, на торрентах можно в евиде скачать.
А так я отсюда начинал смотреть blog.oskarsson.nu/2009/06/nosql-debrief.html
А так я отсюда начинал смотреть blog.oskarsson.nu/2009/06/nosql-debrief.html
0
Плюс на HBase прикручивается JDO и всё становится почти как на AppEngine :)
0
HBase нельзя сравнивать с тем, что мы имеем в App Engine или с MongoDB. И утверждать, что «HBase круче MongoDB» — это то же самое, что говорить «NTFS круче MySQL».
HBase — это лишь довольно низкоуровневое хранилище. Это копия Bigtable, которая представляет из себя «sparse, distributed, persistent multi-dimensional sorted map». Да, там можно даже что-то хранить. И оно даже будет быстро оттуда извлекаться по ключу. Но на практике пользоваться таким вариантом в повседневной веб-разработке — невозможно.
Поэтому в Google App Engine вы работаете не с Bigtable (HBase), а с системой, построенной ПОВЕРХ Bigtable. («Google Megastore»?). Именно она даёт возможность легко и быстро работать с данными, в т.ч. создавать индексы, сложные запросы и прочее.
Вот MongoDB — это как раз аналог Megastore + HBase/Bigtable + Hadoop/MapReduce + HDFS/GFS, только в виде одно цельного продукта. И очень удобного, кстати.
HBase — это лишь довольно низкоуровневое хранилище. Это копия Bigtable, которая представляет из себя «sparse, distributed, persistent multi-dimensional sorted map». Да, там можно даже что-то хранить. И оно даже будет быстро оттуда извлекаться по ключу. Но на практике пользоваться таким вариантом в повседневной веб-разработке — невозможно.
Поэтому в Google App Engine вы работаете не с Bigtable (HBase), а с системой, построенной ПОВЕРХ Bigtable. («Google Megastore»?). Именно она даёт возможность легко и быстро работать с данными, в т.ч. создавать индексы, сложные запросы и прочее.
Вот MongoDB — это как раз аналог Megastore + HBase/Bigtable + Hadoop/MapReduce + HDFS/GFS, только в виде одно цельного продукта. И очень удобного, кстати.
0
Так я и говорю, что поверх HBase сейчас можно прицепить JDO. А JDO позволяет удобно работать с объектами, в том числе создавать сложные запросы (JDOQL). Но это только для java, по другим языкам не в курсе. code.google.com/appengine/docs/java/gettingstarted/usingdatastore.html
Плюс там еще есть всякие надстройки, например Pig для аналитической работы с данными — загрузка данных из внешних источников и выполнение запросов типа SQL.
В целом получается гибче. Есть низкий уровень Hadoop — поверх него есть HBase и другие подобные системы. Затем есть HBase, а над ним более высокий уровень JDO, Pig и т.д. В этом есть свои преимущества, конечно есть и недостатки. Монолитные системы типа MongoDB проще в установке, но ограничивают выбор. В общем, время рассудит, думаю на рынке будет ниша для обеих систем — многоуровневых и монолитных.
А мейнстрим на то и мейнстрим, что проект проверн в системах типа yahoo и других серьёзных компаниях, есть большое сообщество, пишут книги, присылают патчи, вливаются деньги и т.д. Хотя бы посмотреть уровень сделанных презентаций HBase и MongoDB на nosql конфе.
Плюс там еще есть всякие надстройки, например Pig для аналитической работы с данными — загрузка данных из внешних источников и выполнение запросов типа SQL.
В целом получается гибче. Есть низкий уровень Hadoop — поверх него есть HBase и другие подобные системы. Затем есть HBase, а над ним более высокий уровень JDO, Pig и т.д. В этом есть свои преимущества, конечно есть и недостатки. Монолитные системы типа MongoDB проще в установке, но ограничивают выбор. В общем, время рассудит, думаю на рынке будет ниша для обеих систем — многоуровневых и монолитных.
А мейнстрим на то и мейнстрим, что проект проверн в системах типа yahoo и других серьёзных компаниях, есть большое сообщество, пишут книги, присылают патчи, вливаются деньги и т.д. Хотя бы посмотреть уровень сделанных презентаций HBase и MongoDB на nosql конфе.
0
Кстати, для Ruby также сделали надстройку над HBase для работы с объектами. «NTFS круче MySQL» — думаю плохая аналогия. Она бы подошла для Hadoop, но не для HBase — это всё таки уже уровень выше «NTFS'а».
0
Для MongoDB тоже есть Ruby-драйвер со своим ORM, и ActiveRecord-адаптер для RoR. И даже есть storage-бэкенд для Google App Engine SDK.
А вообще-то, не важно кто из нас чем пользуется :) Это — вопрос «религии». Главное — люди начали следовать лозунгу «Think different» в отношении баз данных. Постепенно приходит понимание, что классическая схема реляционной СУБД часто может быть плоха, особенно для веба. А когда её пытаются масштабировать через репликации, шардинг, кэширование, то получается то же самое, что и в документ-ориентированных хранилищах, только в профиль.
Google и Amazon (SimpleDB) показывают своим примером, что приложение можно сразу разрабатывать сколь угодно масштабируемым — надо только изменить подход к разработке, ввести другие правила игры. И потом никаких крупных переделок не понадобится. Большое им за это спасибо!
А вообще-то, не важно кто из нас чем пользуется :) Это — вопрос «религии». Главное — люди начали следовать лозунгу «Think different» в отношении баз данных. Постепенно приходит понимание, что классическая схема реляционной СУБД часто может быть плоха, особенно для веба. А когда её пытаются масштабировать через репликации, шардинг, кэширование, то получается то же самое, что и в документ-ориентированных хранилищах, только в профиль.
Google и Amazon (SimpleDB) показывают своим примером, что приложение можно сразу разрабатывать сколь угодно масштабируемым — надо только изменить подход к разработке, ввести другие правила игры. И потом никаких крупных переделок не понадобится. Большое им за это спасибо!
0
«Дамп и восстановление системы хранения» — ура!, но интересно можно ли будет его автоматизировать
0
Ожидаю реализацию сложных миграций БД для Java (пока же они как-то не торопятся её реализовывать), поддержку Webmoney, а так же полноценный экспорт/импорт данных.
Datastore schema migrations issue:
* code.google.com/p/googleappengine/issues/detail?id=385
Webmoney issue:
code.google.com/p/googleappengine/issues/detail?id=1650
Datastore schema migrations issue:
* code.google.com/p/googleappengine/issues/detail?id=385
Webmoney issue:
code.google.com/p/googleappengine/issues/detail?id=1650
0
Sign up to leave a comment.
Что ожидается в App Engine