Previously it was OceanStore project and EMC provided funding for the research few years ago.

So, here you are, The OceanStore Project

The key of its efficiency is an architecture represented by a set of isolated nodes that don’t know aware of each other. The client makes decisions on data management. This provides very high scale-out factor.

On the other hand, in regular cluster-based systems there is a master server and slave nodes. Slave nodes are very helpful as they help to distribute and speed up read requests. But as soon as write activities occur in a cluster, it’s a pain to broadcast all changes to all nodes. The deployment schema becomes inefficient.

As always, it’s a chain of trade-offs to be considered…

Enjoy – http://www.linuxjournal.com/article/7451

Одним из таких интересных ресурсов является Amazon.com. Недавно я встретил интервью с Werner Vogels на acmqueue.com – где описывается их путь от книжной лавки к компании которая является драйвером инноваций(публичные сервисы S3, EC2,etc)

Существует два пути разработки архитектуры продуктов: при использовании первого – создается простой сервис который будет работать на одной-двух машинах.Если такой сервис выстреливает – начинается усиленная работа над масштабированием узких мест.
Второй путь – изначально закладывать требования масштабирования при разработке. Это, конечно требует некоторого опыта, но потом будет легче.

Вернер, конечно, рассказывает о вещах которые ни для кого теперь не являются секретом, но из его интервью можно выделить:

• При разработке масштабируемых систем важно придерживаться сервис-ориентированной архитектуры, это значительно все упрощает.

• Также важно чтобы каждая часть продукта была децентрализованной – режем продукт на части, каждую часть закрываем в черный ящик, в черном ящике пробиваем дырки – веб-интерфейсы – методы доступа к этой части. Теперь каждая часть может жить своей личной жизнью и развиваться без проблемм – ну, почти без проблемм . Таким образом мы получаем loosely coupled services model

• Очень хорошо сформулировал, что при разработке важно не создавать технологию ради технологии, а создавать технологию чтобы помочь заказчику. Ведь технология без пользователей бесполезна

• У них большая экспертиза в отслеживании поведения пользователя. При вводе новых фич они отслеживают фидбек через изменения в поведении пользователей – некоторые фичи люди начинают исопльзовать сразу же, другие отвергают сразу же, к некоторым необходимо им привыкнуть – такие случаи отслеживать труднее… В лубом случае – для он-лайн сервиса мониторинг действий пользователя, профайлинг своей системы при этом – очень хорошая идея.

В заключение, приведу список challenges которые привел Вернер – он мне понравился полнотой описания:
larger data sets, faster update rates, more requests, more services, tighter SLAs (service-level agreements), more failures, more latency challenges, more service interdependencies, more developers, more documentation, more programs, more servers, more networks, more data centers.

Полная версия статьи здесь

Taking into account dramatic grouth of AJAX popularity and its adoption by a community, the paradigm shift towards grid-computing-in-the-browser is quite possible.

Just check out the numbers:

approximately 4,000 processors, three terabytes of memory, 1.5 petabytes of disks, peak performance of more than 27 trillion calculations per second (27 teraflop).

-Source

Часть докладов уже доступна на RuTube. Не буду дублировать все доклады, приведу лишь те, что успел просмотреть и мне понравились:

1. Anatolix рассказал о трудностях с которыми сталкивались в Яндексе при борьбе с высокими нагрузками.
   http://rutube.ru/tracks/197396.html?v=377843ff9b0f9eec261b9b8378e238d7
   Большинство проблем в принципе классические в Information Retrieval, +/- специфика архитектуры Яндекса. Мне было интересно послушать некоторые моменты о развитии ресурса – например, как извращались разработчики, когда потоки еще не были реализованы во FreeBSD
   
2. Тюнинг операционных систем. Дмитрий Лоханский. Толковый доклад, инетересен тем что технический человек постарался рассказать о сложностях на обычном, доступном языке . Мне понравились идеи монтирования куска оперативной памяти в /tmp директорию для ускорения создания временных таблиц mysql, а также отключение свопирования процессов. ИМХО если было бы больше времени, можно было включить в доклад описание некоторых нюансов из проблемы C10K

Let’s look under the hood:

1. YouTube Architecture
2. Flickr Architecture
3. LiveJournal Architecture
4. Amazon Architecture
5. Google Architecture
6. GoogleTalk Architecture
7. FeedBurner Architecture
8. MySpace Architecture
9. Wikimedia architecture

source – http://highscalability.com/