Иван Бегтин

Проверенный чёрт

Previous Entry Share Next Entry
То что важно знать о Amazon SimpleDB
ivbeg

Что хорошего в SimpleDB

  • действительно большие объёмы данных
  • действительно бысто
  • высокий уровень доступности - уже имеющийся опыт Amazon + использование Erlang
  • лёгкое наращивание мощностей по требованию - по аналогии с S3, EC2

Ограничения и то о чём важно помнить

  • Лексографический порядок элементов - для сортировки цифр необходимо заполнять их нулями до цифр (zero pad), а также использовать аналог ISO 8601
  • Отсутствует полнотекстовый поиск и даже если он появится непонятно как в нём будет реализрована поддержка языков отличных от английского
  • Распределённое обновление записей происходит не мгновенно, а с определённой задержкой порядка 1 секунды для одиночных записей и, возможно, большее время для массовой загрузки данных

Некоторые подробности

  • Один из авторов James Larson также является одним из активных евангелистов языка Erlang и, в прошлом, разработчиком SendMail. А в сентябре 2007 года он перешёл на работу в Google Inc. для работы над ” Developing infrastructure for highly-scalable, highly-available Internet applications.” И что это такое Google задумал, очень интересно.

Источник - блог одного из разработчиков SimpleDB Charles H. Ying

Ещё несколько интересных публикаций по теме:

Ссылка на продукт на основе которого схожие сервисы могут начать строить другие компании - CouchDB и сравнение CouchDB и SimpleDB

Что интерестно так это что и Microsoft ведёт развитие своего проекта Astoria где хотя и пока нет массовости, но зато в качестве веб сервисов используется REST и есть надежда что они не замкнут этот сервис только в экосистему .NET.

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.


Действительно большие объёмы данных - насколько они "действительно большие"? ;-)

Вот дождёмся пары-тройки success story и узнаем:)

Спасибо за анализ и несколько интересных ссылок.

На мой (и не только мой) взгляд, происходит сдвиг в понимании баз данных вообще. Долгое время мир был под очень сильным давлением и влиянием реляционной модели и больших СУБД. Эта модель имеет много преимуществ, которые весьма важны для финансовых приложений, где она с успехом и применяется. Однако, она накладывает весьма жесткие ограничения на гибкость, масштабируемость, распределенность и т.д.

С развитием интернет-приложений стало выясняться несколько интересных аспектов работы с данными, специфичных именно для интернета:
- В большинстве случаев данные имеют весьма простую структуру, часто достаточно примитивного (key,value)-pair
- Однако, иногда это простая структура динамическая, она может быть неизвестна в момент проектирования
- Referential integrity часто не важна, или даже вредна
- Транзакции элементарные и короткоживущие, часто ими можно пренебречь
- Разработка ведется от интерфейса (раньше -- от данных)
- Требования к надежности не высоки, по сравнению к требованиями к масштабируемости, так как заранее не всегда можно предсказать рост нагрузки
- Некоторые данные можно иногда и потерять, это не смертельно (если они не финансовые, но для работы с платежами есть много специальных сервисов)
- Тенденция использования кластеров стандартных дешевых серверов, вместо тяжелых мейнфреймов.

Эти аспекты противоречат классическому подходу разработки R-OLTP баз данных и существующим СУБД. Нужен новый подход, и Amazon SimpleDB, как вариант, вполне в него укладывается.

Похожие мысли, хотя и с несколько другими выводами, можно найти в статье: "The end of architectural era". http://www.mit.edu/~dna/vldb07hstore.pdf
Или на русском: http://citforum.ru/database/articles/end_of_arch_era/

P.S. Характерно, что некоторые крупные интернет-приложения, сравнимые с enterprise, тоже отошли от R-OLTP. Например, известная Open Source CRM-система SugarCRM использует свой собственный способ "укладки" данных в СУБД. Модель и связи между объектами декларативно описываются в специальном конфигурацинном файле, по которому уже генерируется или валидируется сама схема. Схема может меняться динамически во время работы приложения. Никаких транзакций, никакой referential integrity на уровне СУБД, естественно, нет.

Также спасибо за ссылки на статьи, очень интересно. У меня были схожие ощущения что реляционная модель себя постеменно изживает, но до сих пор никто не предлагал оптимальной замены, а постреляционные идеи вроде XML-DB или Cache оказались не столь уж востребованными.

Я думаю что Amazon только первопроходцы, крупные игроки смотрят на то насколько будет востребован их продукт. Я думаю что вскоре и Google запустит аналогичный сервис, в ту же сторону могут склонится MS, Yahoo. Да и Joyent к примеру очень любят маштабируемые продукты.

А может быть это как раз та область где могут проснуться Oracle и IBM.

Спасибо за ссылку.

Причем, интересна не столько статья, которая вполне бездарна, сколько комментарии и ссылки в них.

You are viewing ivbeg