Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
«Сервис для работы с большими файлами.»
Наконец то!
Наконец то!
XMPP, как я поинмаю, чтобы к Google Wave прицепить?
Поскольку Google Wave построен на базе XMPP, то скорее всего вы правы. Из рабочих вариантов пока явно Google Talk напрашивается, а для Wave скорее всего сделают отдельный сервис на основе XMPP API.
Прикольный двигателет, как у Дима Червяка.
О, можно будет сделать jabber-бота? Или пока будет поддерживаться только отправка собщений?
Скорее всего можно будет, не вижу ни каких проблем
Об этом не пишут. Мое мнение, что будет только отправка. Идея встроить в App Engine сервисы, которые могли бы обрабатывать входящие e-mail (не как клиент к gmail, а как сервер) и XMPP боты выглядит очень привлекательно, но в то, что это будет скоро реализовано, верится с большим трудом.
А можно оттуда выгрузить код, который ранее загрузил? (чтобы поправить и обновить)
Не представляю что еще можно подразумевать в пункте 6 (Дамп всех неперехваченных исключений будет фиксироваться и отображаться в административной панели) кроме того, что уже реализовано сейчас: не то что неперехваченные исключения, вообще все нештатные ситуации с легкостью читаются в специальном разделе логов.
Дополню по презентациям из 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
Позволил себе перевести. Перевод очень вольный, сильно не ругать :)
Презентация 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) данными
интересно, а когда же апл стор введет поддержку карточек Visa Electron (сколько я а iTunes не старался регнуться визу электрон от сбербанка он не распознает) вот такая пища к размышлению.
Никогда не введет, ибо это невозможно. По российским банковским «правилам» Electron является только ATM без возможности оплаты в сети. Виза в 2004 помоему рекомендовала исправить ситуацию, но многие наши банки положили на это с прибором. И до сих пор многие российские Electron карты не биллятся в сети. Привяжите к своей карте онлайн-банкинг с виртуальным счетом или смените карту.
Обидно, но в моей организации з\п начисляется либо на визу электрон либо на сберкнижку… так что виза электрон лучший вариант для меня :(
можно поподробнее про Онлайн-банкинг, привязку к нему и будет ли ап стор кушать эту привязку?
если можно чтобы не разводить тут флуд, ответь в ЛС пожалуйста.
можно поподробнее про Онлайн-банкинг, привязку к нему и будет ли ап стор кушать эту привязку?
если можно чтобы не разводить тут флуд, ответь в ЛС пожалуйста.
На самом деле не очень понятнен вопрос про Apple store в контексте AppEngine.
А по сути — надо идти в банк и просить подключить онлайн-банкинг и виртуальный счет для платежей в интернете. Они все расскажут и покажут. Будет ли appstore принимать деньги с вирт.сбербанковского счета — скорее всего да, узнавайте в банке. Ни разу с appstore не сталкивался и услугами сбербанка не пользовался.
А по сути — надо идти в банк и просить подключить онлайн-банкинг и виртуальный счет для платежей в интернете. Они все расскажут и покажут. Будет ли appstore принимать деньги с вирт.сбербанковского счета — скорее всего да, узнавайте в банке. Ни разу с appstore не сталкивался и услугами сбербанка не пользовался.
// либо на визу электрон либо на сберкнижку
Очень странно. Именно Электрон? А обычная Виза почему не подходит? Бухгалтерии должно быть совершенно пох — они же на счет в банке деньги переводят, а не на карту.
Или просто заведите себе вторую карту. Моя сбербанковская стандартная Виза проходит везде в инете, где бы ни платил.
Очень странно. Именно Электрон? А обычная Виза почему не подходит? Бухгалтерии должно быть совершенно пох — они же на счет в банке деньги переводят, а не на карту.
Или просто заведите себе вторую карту. Моя сбербанковская стандартная Виза проходит везде в инете, где бы ни платил.
у нас гос учреждение с своими правилами к сожалению и по правилам которые мне пришлось подписать я имею право иметь только 1 счет банка (виза электро в моем случае) и я не могу иметь побочный заработок, вот такая фигня…
Есть жёны, родственники, домашние питонцы))
Что мешает оформить счёт на них?
Что мешает оформить счёт на них?
жены нет, родственники оч далеко.
Что за бред, никакими правилами не может быть запрещено привязка виртуального счета к карте, это личная карта и в пределах онлайн-банкинга перенос денег между счетов это личное дело. В конце концов по второй счет будете знать только вы, и привяка обоих будет к карте. На крайняк надо пойти в бухгалтерию (к директору) и рассказать плаксивую историю что не можете купить хлебушка в интернете на кровные денюшки. Ибо русский электрон не биллится в инете. Идите в банк и привязывайте e-банкинг. В сбербанке он назывется помоему «Сбербанк @nline»
Рекомендую взглянуть на открытый и свободный MongoDB ( www.mongodb.org/ ) всем интересующимся Google App Engine (GAE). MongoDB выглядит почти идентично Datastore в GAE, ничуть не уступая, а местами превосходя его по функционалу (взять то же хранение файлов и курсоры, которые в MongoDB уже давно есть, удобный API). Те же возможности + масштабируемость. Естественно, такой вариант только для тех, кто сам может (и хочет) обеспечить хостинг. Зато и ограничений платформы — никаких.
В этом плане более перспективна связка hadoop+hbase+jdo
Это уже вопрос вкуса. Скажу по себе — я недели две убил на изучение всех подобных проектов — а их немало. Это 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/ )
Я пока поверхностно на такие системы посмотрел. Просто показалось, что в будущем hbase и hadoop будет лучше поддерживаемой системой — станет в будущем менстримом. По hadoop и hbase кстати книга есть (только-только вышла) на amazon, на торрентах можно в евиде скачать.
А так я отсюда начинал смотреть blog.oskarsson.nu/2009/06/nosql-debrief.html
А так я отсюда начинал смотреть blog.oskarsson.nu/2009/06/nosql-debrief.html
Плюс на HBase прикручивается JDO и всё становится почти как на AppEngine :)
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, только в виде одно цельного продукта. И очень удобного, кстати.
Так я и говорю, что поверх 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 конфе.
Кстати, для Ruby также сделали надстройку над HBase для работы с объектами. «NTFS круче MySQL» — думаю плохая аналогия. Она бы подошла для Hadoop, но не для HBase — это всё таки уже уровень выше «NTFS'а».
Для MongoDB тоже есть Ruby-драйвер со своим ORM, и ActiveRecord-адаптер для RoR. И даже есть storage-бэкенд для Google App Engine SDK.
А вообще-то, не важно кто из нас чем пользуется :) Это — вопрос «религии». Главное — люди начали следовать лозунгу «Think different» в отношении баз данных. Постепенно приходит понимание, что классическая схема реляционной СУБД часто может быть плоха, особенно для веба. А когда её пытаются масштабировать через репликации, шардинг, кэширование, то получается то же самое, что и в документ-ориентированных хранилищах, только в профиль.
Google и Amazon (SimpleDB) показывают своим примером, что приложение можно сразу разрабатывать сколь угодно масштабируемым — надо только изменить подход к разработке, ввести другие правила игры. И потом никаких крупных переделок не понадобится. Большое им за это спасибо!
А вообще-то, не важно кто из нас чем пользуется :) Это — вопрос «религии». Главное — люди начали следовать лозунгу «Think different» в отношении баз данных. Постепенно приходит понимание, что классическая схема реляционной СУБД часто может быть плоха, особенно для веба. А когда её пытаются масштабировать через репликации, шардинг, кэширование, то получается то же самое, что и в документ-ориентированных хранилищах, только в профиль.
Google и Amazon (SimpleDB) показывают своим примером, что приложение можно сразу разрабатывать сколь угодно масштабируемым — надо только изменить подход к разработке, ввести другие правила игры. И потом никаких крупных переделок не понадобится. Большое им за это спасибо!
«Дамп и восстановление системы хранения» — ура!, но интересно можно ли будет его автоматизировать
Ожидаю реализацию сложных миграций БД для 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что ожидается в App Engine