Изначально в сервисе Ubuntu One (https://one.ubuntu.com/) для синхронизации адресной книги, музыкальной коллекции закладок, закладок Firefox и заметок Tomboy использовалась документ-ориентированная база данных Apache CouchDB (http://www.opennet.me/opennews/art.shtml?num=30807), архитектура которой ориентированна на выполнение репликации в режиме master-master. Компания Canonical объявила (http://jderose.blogspot.com/2011/11/note-on-ubuntu-one-dropp...) о решении отказаться от использования CouchDB из-за нескольких принципиально нерешаемых проблем, связанных с невозможностью обеспечить должный уровнь масштабируемости в системах, обслуживающих запросы от миллионов пользователей.
Вместо CouchDB планируется создать (https://blueprints.launchpad.net/ubuntu/%2Bspec/desktop...) собственную прослойку U1DB для синхронизации данных, которая не будет зависеть от платформы и типа синхронизируемой БД (сможет синхронизировать от SQLite и MySQL до произвольных API и наборов данны...URL: http://jderose.blogspot.com/2011/11/note-on-ubuntu-one-dropp...
Новость: http://www.opennet.me/opennews/art.shtml?num=32369
Как? Ещё одна прослойка? Может хватит уже прослоек в линуксах?
В данном случае прослойка - это плюс, так как увеличивает гибкость.
С прослойками обычно проблема в том, что они являются наибольшим общим знаменателем всех поддерживаемых систем, а посему довольно ограниченные.
гибкость обычно обратно пропорциональна стабильности.
и последующий оратор тебе насчет гибкости уже сказал, что ты не прав.
> В данном случае прослойка - это плюс, так как увеличивает гибкость.Ага, самая лучшая прослойка была ODBC... Если еще кто-то это помнит... Одинаково скверная для любого SQL "диалекта" прослойка...
как и jdbc, ado.net и тд, и тп
более того, практически любое современное корпоративное ПО по доступу к б/д использует ту или иную прослойкузыж
2Аноним
>Как? Ещё одна прослойка? Может хватит уже прослоек в линуксах?а при чём тут линух?
вот в чём проблема то.
>> В данном случае прослойка - это плюс, так как увеличивает гибкость.
> Ага, самая лучшая прослойка была ODBC... Если еще кто-то это помнит... Одинаково
> скверная для любого SQL "диалекта" прослойка...Ну это уже проблема ODBC, а не всех прослоек. Задач у Ubuntu One весьма ограниченное количество, это сильно упрощает ситуацию.
> Вместо CouchDB планируется создать собственную прослойку U1DB для синхронизации данныхРеализация этой прослойки будет, конечно же, проприетарной?
Чет ближе к новому году компании потянуло на кардинальные перемены.
То ту подсистему выкинут, то от этой откажутся, то вон ту назовут устаревшей и непотребной.
И бегом писать анонсы о том, какие прекрасные вещи они наваяют взамен.
По факту ничего плохого в этом нет, но тенденция интересная.
К ним сотрудники из Фэйсбука не переходили? У тех тоже тяга к инновациям(tm) и постоянная головная боль с DB, ибо пользователей миллионы, серверов сотни и всё такое.
> К ним сотрудники из Фэйсбука не переходили? У тех тоже тяга к
> инновациям(tm)И у них неплохо получается: видимо, всё-таки кто-то вспомнил про теорему о циркуляции и решил снизить бесполезный расход электроэнергии на излучение электромагнитного поля, подняв напряжение питания с 220 до 440 вольт.
Заказное оборудование быстро окупится.
> и постоянная головная боль с DB, ибо пользователей миллионы, серверов сотни и всё такое.
Ну, это да. Базы данных масштабируются плохо. ;)
Erlang, на котором написано ядро СУБД, оказался не под силу программистам из Canonical. View-сервер, написанный на языке Си и базирующийся на JavaScript-движке Mozilla Spidermonkey, видимо тоже оказался не под силу JavaScript-программистам из Canonical.
Вывод: мультипарадигменное программирование в одном проекте не работает.Почему сразу не выбрать NoSQL СУБД, написанную на одном языке программирования — Java?! У Apache их есть.
изенчик, ты тока не матерись, но накой им на жаве писать? Есть и лучьше решения.
На питоне напишут, да?
А вас он укусил и с тех пор вы его не любите.
не, просто глупые хомячки везде его пиарят и пропихивают, ничего личного
Лишь бы не perl.
>>Erlang, на котором написано ядро СУБД,
>>написанный на языке Си
>>JavaScript-движке Mozilla SpidermonkeyОсталось еще что-нить на питоне и перле туда написать для полного счастья.
>>Почему сразу не выбрать NoSQL СУБД, написанную на одном языке программирования — Java?!
А чем сама идея LINQ плоха?
> Осталось еще что-нить на питоне и перле туда написать для полного счастья.Perl весьма неплох, как язык в целом, но не здесь, конечно
>отказаться от использования CouchDB из-за нескольких принципиально нерешаемых проблем, связанных с невозможностью обеспечить должный уровнь масштабируемости в системах, обслуживающих запросы от миллионов пользователей.Подождит-подождите. Она же написана на Erlang! Том самом Erlang, о супермасштабируемости приложений на котором так любят вопить его красноглазые фанатики. Как же так получилося?
Неосиляторам не особо важно, на чем оно написано.
Мы все ждали этого довода.
Масштабируемость Erlang плоха для больших распределённых систем.
Масштабируемость Erlang хороша для одной маленькой системы с сумасшедшим количеством потоков исполнения.Erlang -- Ericsson Language -- был разработан с оглядкой на то, что фирма Ericsson производит. А производит она АТС. Вот и представьте, сколько потоков исполнения в АТС, скажем, на 300 000 номеров. Что, Erlang не супермасштабируем?
Идея отказа от синхронизации и работы с сообщениями хороша в том случае, если есть среда передачи этих сообщений с нулевой latency (читай: внутренняя магистраль АТС).
Если у нас Ethernet, всё становится заметно хуже.
Во, интересно очень! А скажите, пожалуйста, есть ли смысл делать высоконагруженный сайт на Erlang? Фреймворки вроде есть специализированные. Просто я знаю один стартап, там всё носятся с этой самой масштабируемостью, говорят любые проблемы с нагрузкой можно будет решить втыканием дополнительного сервера. А насколько я вас понял - облом получается, связаны-то они по ethernet будут. Или масштаб не тот, что бы проблем огрести?
Erlang будет плохо работать, если latency для инфраструктуры передачи сообщений велика. Я бы не стал делать что-то на Erlang, если это "что-то" связано Ethernet'ом.
Можно поэкспериментировать с чем-нибудь более вменяемым, например, со связкой OpenMPI -> RDMA -> InfiniBand. Ну, для начала InfiniBand можно заменить на FireWire, он тоже умеет RDMA.
Что за рассуждения о сферичиском эрланге в вакууме?
CouchDB маштабируется/реплицируется по протоколу http, причем данные передаются в json.
> Что за рассуждения о сферичиском эрланге в вакууме?
> CouchDB маштабируется/реплицируется по протоколу http, причем данные передаются в json.Да-да, всё именно так и есть. Поэтому Erlang плохо и работает. :)
> Подождит-подождите. Она же написана на Erlang! Том самом Erlang, о супермасштабируемости
> приложений на котором так любят вопить его красноглазые фанатики. Как же
> так получилося?И что ? U1DB тоже планируют на Erlang написать. Насколько я понял, проблема не в возможностях CouchDB по одновременному обслуживанию большого числа запросов, а в том, что CouchDB не заточен под ведения огромного числа _разных_ баз. Так как у каждого пользователя своя база, то для каждого пользователя приходится запускать свой экземпляр серверного процесса CouchDB.
> U1DB тоже планируют на Erlang написатьАноним такой аноним...
https://launchpad.net/u1db
Programming Languages:
python, C
Одобряю, erlang-сервис на десктопе это я считаю перебор.
> Одобряю, erlang-сервис на десктопе это я считаю перебор.почему «перебор» именно erlang-сервис?
Лучше бы работу через прокси реализовали. С первых дней обещают, а воз и ныне там.Does Ubuntu One support access behind proxy servers?
No. We are adding proxy support for some Ubuntu One features in future versions of Ubuntu but users behind proxy servers will currently have issues connecting to a variety of Ubuntu One services including files and contacts sync.