Японская компания Gemini Mobile Technologies представила (http://www.geminimobile.com/news/news100714%28en%2...) новую свободную нереляционную БД Hibari (http://hibari.sourceforge.net/), предназначенную для организации сверхбольших распределенных хранилищ данных, представленных в формате ключ-значение. Код Hibari (http://sourceforge.net/projects/hibari/) написан на языке Erlang и распространяется в рамках лицензии Apache. В качестве наиболее типичных областей применения Hibari называются крупные web-mail системы, социальные сети, службы хранения логов операторов связи и другие сервисы, в которых необходимо хранить терабайты и петабайты поступающих ежедневно данных.
API для доступа к данным в Hibari доступно для языков Java, C/C++, Python, Ruby и Erlang. В настоящий момент подготовлены модули эмуляции API Amazon S3, JSON-RPC-RFC4627 и UBP (Universal Binary Protocol), что позволяет использовать БД с типовыми приложениями, написанными для уже существующих стандартных сервисов хран...URL: http://www.geminimobile.com/news/news100714%28en%2...
Новость: https://www.opennet.ru/opennews/art.shtml?num=27481
судя по описанию - вполне приличная хибара.
> высокая производительностьЭто на эрланге-то??? В виртуальной машине? Ха-ха-ха-ха!
О господи, да открой ты уже для себя мир оптимизации на более высоком уровне нежели ассемблер.
Оптимизация тут не при чем. Тут неустранимый оверхед ненативного кода.
При чем тут оверхед? У Erlang'а — soft realtime безо всякого оверхеда. Плюс плюшки по созданию именно распределенных приложений.Можно только повториться:
«
да открой ты уже для себя мир оптимизации на более высоком уровне нежели ассемблер.
»и
«
Народ, когда вы перестанете все примерять к своему "ноутбуку"? Это решение преследует несколько другие цели и масштабы.
Если так ограничены во взглядах, то не надо каждый раз это показывать.
»
> У Erlang'а — soft realtime безо всякого оверхеда.А как реалтаймность связана с быстродействием вообще? oO
Скорей всего он имел ввиду, что это возможно и реализовано, поэтому о оверхеде здесь можно не говорить.С.
Не вижу как одно связано с другим. Предсказуемость времени реакции ("реалтайм") - одно. Производительность - другое. Скажем мелкий 8-лапый "таракан" (микроконтроллер) может среагировать на внешнее событие гораздо быстрее писюка, при том с точностью до тактов и команды выполняются всегда за одинаковое время (кеша нет, память на полной скорости CPU). Т.е. ему по зубам даже "жесткий" реалтайм, когда время реакции всегда одинаковое и строго определенное (у x86 будет некий джиттер времен реакции на события за счет кеша и прочая). А вот производительность 8-битника на его паре десятков мегагерцев - понятно какая, да? Вот я и не догоняю - как они взаимосвязаны :). Более того - я не догоняю как можно гарантировать реалтайм не рассмотрев хотя-бы систему на которой это запущено. А то если у вашей задачи ядро системы отберет время вот сейчас на 10 мс а через полчаса на 100мс - это реалтайм будет или нет? :)
>[оверквотинг удален]
>на полной скорости CPU). Т.е. ему по зубам даже "жесткий" реалтайм,
>когда время реакции всегда одинаковое и строго определенное (у x86 будет
>некий джиттер времен реакции на события за счет кеша и прочая).
>А вот производительность 8-битника на его паре десятков мегагерцев - понятно
>какая, да? Вот я и не догоняю - как они взаимосвязаны
>:). Более того - я не догоняю как можно гарантировать реалтайм
>не рассмотрев хотя-бы систему на которой это запущено. А то если
>у вашей задачи ядро системы отберет время вот сейчас на 10
>мс а через полчаса на 100мс - это реалтайм будет или
>нет? :)Я не говорил про hard realtime, а про soft realtime. Ссылки сейчас искать лень, ищущий да обрящет ;)
Мне просто не понятно - как реалтаймность вообще коррелирует с производительностью или что вы хотели доказать. Более того - чтобы гарантировать времена отклика на вменяемом уровне и непрерывность выполнения на критичных местах - явно надо лезть глубоко в механику операционки. А это имхо заявка на написание модуля/драйвера ядра или как минимум какие-то злостные системные извращения, для которых прокатит обычный си (из коего лезть в тонкую системную механику более-менее удобно и съедобно, имхо).
>Более того - чтобы гарантировать времена отклика
>на вменяемом уровне и непрерывность выполнения на критичных местах - явно
>надо лезть глубоко в механику операционки.Не обязательно
В общем, достаточно взять Erlang в руки и посмореть/почитать.
>При чем тут оверхед? У Erlang'а — soft realtime безо всякого оверхеда.При чем здесь нахрен realtime? Без оверхеда - грязная ложь, он выполняется виртуальной машиной, а это всегда оверхед. У тебя на ноутбуке оно может и работает, а я не собираюсь покупать лишние сервера на то что мне не нужно - а именно, интерпретацию байткода. Есть замечательные параллельные БД на нормальных языках.
>>При чем тут оверхед? У Erlang'а — soft realtime безо всякого оверхеда.
>
>При чем здесь нахрен realtime? Без оверхеда - грязная ложь, он выполняется
>виртуальной машиной, а это всегда оверхед. У тебя на ноутбуке оно
>может и работает, а я не собираюсь покупать лишние сервера на
>то что мне не нужно - а именно, интерпретацию байткода. Есть
>замечательные параллельные БД на нормальных языках.Берется в руки мозг, если он есть и начинает читаться про:
- ejabberd
- facebook chat
- basecamp chat
- mochiads/mochiweb
- riak
- couchdb
ну или вообще хотя бы про Erlang.
Почему-то народ, переходя на Erlang с «нормальных» языков уменьшает количество серверов, а не увеличивает их.
>Почему-то народ, переходя на Erlang с «нормальных» языков уменьшает количество серверов,Может быть, дело в том что сервера были задизайнены дурно/неоптимально? А то почему-то переход с своеобразного опача на допустим лайти или нжинкс тоже количество серверов может уменьшить весьма некисло. А все отличие - сугубо в логике работы сервера. Одно форкает по процессу на юзера, что ессно жрет дофига ресурсов, особенно неоптимально сие на статике. Другое реализует машины состояний, которым количество юзеров не особо критично. А, извините, какойнить ircd писаный на голых сях - легко обслужит групчат с многими тыщщами юзеров на ископаемом железе вообще. Заметьте, сожрав в разы меньше ресурсов и траффика чем ejabberd для той же задачи (это правда частично заслуга самого протокола жаббер сделанного понятно как).
P.S. я не пытаюсь сказать что "эрланг - плохо". Я не имею ничего против эрланга. Тем не менее, если вы беретесь доказывать его крутизну - доказывайте убедительно и будьте готовы что аргументы проверят/оспорят :P.
>>Почему-то народ, переходя на Erlang с «нормальных» языков уменьшает количество серверов,
>
>Может быть, дело в том что сервера были задизайнены дурно/неоптимально?А может быть дело в том, что Erlang оптимизирован именно для распределенных систем, а для C/C++ практически нет подобных решений?
>P.S. я не пытаюсь сказать что "эрланг - плохо". Я не имею
>ничего против эрланга. Тем не менее, если вы беретесь доказывать его
>крутизну - доказывайте убедительно и будьте готовы что аргументы проверят/оспорят :P.
>Вообще-то, доказательства должны лечь на человека, заявившего про «оверхед» в первом ответе. Все остальное легко находится в гугле.
Производительность распределенных систем сильно зависит именно от распределенности - организации фрагментации и управления ею, производительность отдельных узлов отходит на второй план.
Народ, когда вы перестанете все примерять к своему "ноутбуку"? Это решение преследует несколько другие цели и масштабы.
Если так ограничены во взглядах, то не надо каждый раз это показывать.
А почему ты думаешь что ты самый умный и знаешь кто куда это решение примеряет?
Чтото последнее время эта CAP-теорема на каждом шагу, я вот только одного понять не могу, может кто прояснит, в соответствии с ней:"обеспечение непротиворичивости хранилища в целом"
возможно одновременно с
"способность продолжать работу в случае раскола кластера хранения (нарушения связности узлов)"
это как ?
Да не обращайте на нее внимания, бред это, а не теорема.
В это время база не работает и получаем нарушение второго требования "высокая надежность (устойчивость к сбоям)", т.е. как и предсказывалось.
т.е. база не работает уже при двух требованиях ?
>т.е. база не работает уже при двух требованиях ?Нет. Это означает, что база не выполняет третье требование
Непротиворечивость не значит доступность всех данных. Например, два условия сохраняются когда в кластере хранится только одна копия данных, без дублирования на несколько узлов. Так как при изменении данных другие узлы не затронуты гарантируется непротиворечивость.Заменяя требование о непротиворечивости на отказоустойчивость получаем дублирование данных на несколько узлов, но вот гарантировать, что во время чтения данных с одного узла они уже не успели измениться на другом не получится.
тогда получается что все данные должны лежать на одном узле, это уже не распределенная система, либо от функциональности остаются рожки да ножки, т.е. можно работать только с тем что доступно "локально" целостно и не продублировано, опять не распределенная система получается.