Компания Google анонсировала (http://googlecode.blogspot.com/2011/10/google-cloud-sql-your...) начало тестирование нового сервиса Cloud SQL (http://code.google.com/apis/sql/) для облачного хостинга web-приложений App Engine (http://appspot.com). Новый сервис позволит выполнять в окружении App Engine приложения, написанные для работы с традиционными СУБД, используя стандартный интерфейс JDBC для Java и DB-API для Python. Сервис полностью совместим с MySQL, как по формату загружаемых дампов, так и по возможностям SQL.
Все операции по обслуживанию базы берет на себя Google, для пользователя доступны только функции массового импорта и экспорта данных, а также административный интерфейс для удобного управления данными. Целостность данных гарантируется благодаря синхронной репликации всех изменений одновременно на несколько серверов в разных дата-центрах. Все операции по обеспечению работоспособности из-за сбоя отдельных серверов или целых дата-центров выполняются автоматически, незаметно для клиента.
URL: http://googlecode.blogspot.com/2011/10/google-cloud-sql-your...
Новость: http://www.opennet.me/opennews/art.shtml?num=31970
Репликация в 2011м году? Она вообще не фонтан. Все ее прелести требуют человеческого фактора - двухфазные коммиты, толпы транзакций in doubt. Веселуха!
> Репликация в 2011м году? Она вообще не фонтан. Все ее прелести требуют
> человеческого фактора - двухфазные коммиты, толпы транзакций in doubt. Веселуха!Думаю, что как и в других сервисах Google репликация реализована на уровне низкоуровневого хранилища, а не в СУБД. Поэтому без разницы, что реплицировать.
СУБД не обеспечивают логической целостности данных при работе поверх сториджа с низкоуровневой репликацией. Оракл поверх EMC это наглядно демонстрирует.
> СУБД не обеспечивают логической целостности данных при работе поверх сториджа с низкоуровневой
> репликацией. Оракл поверх EMC это наглядно демонстрирует.Мне другое интересно, они как в vmWare сделали - отдельная БД привязана к одному instance или из нескольких instance можно c общими данными работать. Во втором случае конечно репликацией на уровне хранилища не обойтись. В первом случае нет никакой разницы, работает СУБД поверх реплицируемого хранилища или допустим RAID, для приложения это обычный диск.
Для такой работы нужна claster aware filesystem. _без_ низкоуровневой репликации под POSIX.
а она у них есть - G(oogle)FS
Блин, ты прав. Я об этом факте просто забыл.
судя по "claster" - просто не знад
Что только гугль не сделает, чтоб собрать побольше чужих данных.
такое ощущение что GAE пытается догнать по возможностям (точнее сказать по отсутствию ограничений) Heroku .. но правда сёравно Heroku далеко уехало вперёд
блин, пусть лучше гугль запиливает в свои GAE-сервисы -- CouchDB , а не эти MySQLы и PHP (ну про PHP ещё не сообщалось, но после MySQL кажется это уже не будет сюрпризом, если вдруг захотят это сделать :-D)
Чушь какую-то предлагаешь. Зачем туда запиливать миллион NoSQL-баз? MySQL-решение поможет мигрировать туевой хуче народу, а CouchDB ты и и без гугла погонять сможешь. И какой ещё PHP? Что за бредятина? Ассоциативный ряд MySQL=>PHP - свойственен 1С-программистам каким-нибудь, и то, недалёким.
причем здесь ассоциативный ряд? вполне естественно использовать недоязык с недосубд. а миграция туевой хучи недоразработчиков ничего кроме проблем не принесет