А может и специальный маркетинговый ход. Те кто хотел узнать о ТВ и так узнали, а тут еще и дополнительная публика, статьи и просмотры роликов на UT.

Загрузить канал на 10 гигабит несколькими клиентами не так сложно. Интересный момент не нашел в статье. Сколько одновременных соединений сможет обработать данное решение?

В течении дня успешно залил 20ГБ. Для удобства добавил бы несколько вещей:
1. возможность добавить линк на каталог для синхронизации (сейчас получается чтобы залить в облако надо скопировать весь контент в один каталог cloud@mail.ru, понятно что можно сделать линки на каталоги, но все-же).
2. два компьютера А и Б, на обоих по 20ГБ различных данный. Если залить в облако с каждого компьютера по 20ГБ, то потом на каждом компьютере в каталоге cloud@mail.ru получится по 40ГБ. Чего хотелось бы избежать, но при необходимости компьютер A должен иметь доступ ко всем данным, что было залито с компьютера Б. Что-то типа iOS приложения которое синхронизируют по необходимости во внутренний кеш.
3. хотелось бы на WEB части получить возможность сортировать (к примеру по дате), а не скролить в самый низ экрана за последней залитой фотографией с iOS

Спасибо.
П.С. на самой странице облака не нашел возможности обратиться в суппорт по облаку с багами и предложениями.

Правильно замечание. Зачем же сразу минусовать, исправте лучше статью.

В прошлом году обещали видео с RCC-2011. Уже смонтировали, можно где-то посмотреть?

это только статистика. самих пользовательских данный — фото, сообщения,… по одному из постов 160TB habrahabr.ru/company/odnoklassniki/blog/115881/
правда это было давно.

Большая часть собираемой информации абстрагирована от конкретного пользователя! Иначе объем данных и записей в день пришлось бы умножать на несколько порядков!

Всего смайликов c подарками ~1.5 TB (500 GB x 3 replication factor)

какая цель и в чем экономия?
сейчас работает, много не ест и нет проблем.

Concurrency: одновременное использование кеша в сотне потоков;
10% из потоков пишут.

Подошли бы. Только один важный момент — при рестарте приложения необходимо не потерять закешированные данные 55GB.

Даже в качестве наблюдателя очень весело было! Сам был, все видел и очень понравилось! Даже появилось желание в topcoder-e зарегестрироваться и заняться тренировкой мозгов!

Думая, что несколькими днями тут не обойтись. Просто уметь программировать будет не достаточно! Чтобы достигнуть вершин, то потребуются месяцы тренировок, а то и годы.

Для надежности данных используется родная Berkeley DB master-slave репликация базы. Особых проблем с QUEUE базой не наблюдалось.

Если задание попало в очередь, то потерять данные будет уже сложно (пока не теряли). Пишутся логи на диск и постоянно идет реплика на другой сервер. Надежность на 100% не ожидаем (специфика сервиса работающего с данной очередью).
В худшем случае при «hardware fail» на мастер сервере потеря составит <1 минуты работы сервиса. При этом значительного эффекта на систему не ожидаем. Сама система переходит в синхронный режим работы, пока проблемы с очередью не будут решены.

В случае же транзакций по платным сервисам ожидаем 0% потери данных. Тут уже процесс реализован на основе MS SQL.

Специально выделенных людей нет. Ответственный разработчик за разработку нового продукта занимается нагрузочным тестированием.

Тестируем в основном разного рода «back end» системы. Иногда при тестировании используем JMeter, но
в большинстве случаев это просто консольное java приложение, которое генерит нагрузку на систему.

Первый этап тестирования — это синтетика. Примерно прикидываем предпологаемую нагрузку и запускаем тест. Как показала практика синтетический тест зачастую очень далек от реальности (сложно предугадать в тесте реальное поведение массы людей). Поэтому второй этап нагрузочного тестирования проходит в реальных условиях на реальных пользователях, которые об этом даже не подозревают.

Для примера: при тестировании новой системы хранения данных мы параллельно сохраняли данные в старую и новую систему. При чтении данных сравнивали результат из обоих систем. После устранения всех узких мест и ошибок начинали переход на новую систему хранения данных. Логика написанная для тестрования в конечном итоге использовалась для плавного перехода на новую систему хранения данных.

Можно пожалуйста пример продукта работающий на данном решении? Желательно с дополнительной информацией: сколько машин в кластере, какая нагрузка на одну машину, объем данных.

Тема вообще интересная. Думаю может получиться хорошая статья — что, как, почему и к чему пришли.

«Работает и не трогай.» =) Пока нет проблем с текущим решением и причин менять на что-то новое.

Давно когда-то были идеи все отдать в opensource. В реальности на запуск и последующую поддержку opensource проектов может уйти много времени, но его как всегда нет.

Нагрузочное тестирование есть, но в основном на стадии внедрения каких либо новых технологических решений или при запуске нового сервиса с нестандартными решениями.

Делать синтетическое нагрузочное тестирование при каждом update на всю систему давольно накладно по времени. Своего рода нагрузочное тестирование происходит на тестовой группе серверов с реальными пользователями.