Комментарии 20
Чем Вас не устроила «своя» Эрланговская БД? Ипроизводительность высокая, и городушек не надо…
Всё-таки в Cache очень мощный инструмент работы с деревьями(глобалами), транзакциями, и много готового по организации распределённых хранилищ данных, при этом для разработчика эта распределённость скрыта. Настроить удалённую БД, мастер-слейв, теневое коприрование или зеркалирование — проще простого (об этом даже на хабре писали).
Помимо этого, на момент начала разработки, да и сейчас, иногда возникает необходимость подключиться к старым sql-источникам. Также данное ППО (MCA) — является частью более общего нашего ПО(ППО) ErlMOM (Erlang Message Oriented Middleware), которое позволяет осуществить интеграцию различных приложений и DBS в облачную инфраструктуру посредством обмена сообщениями в рамках конкурентной модели. Однако на практике, нами сейчас активно используется подключение к каше, в других наших проектах подключение к мнезии. Вообще, для обработки многомерных разряженных структур — использовать глобалы, которые по сути и сами есть многомерные разряженные структуры — очень удобно — и строить деревья или графы правил — получается естественно и просто. Также сам процесс создания системы и её частей — был достаточно растянут во времени, и для тех или иных компонент рассматривались, и прототипировались, различные варианты архитектуры, языки, библиотеки. СУБД Cache — нами была выбрана даже ранее, чем язык Erlang.
Помимо этого, на момент начала разработки, да и сейчас, иногда возникает необходимость подключиться к старым sql-источникам. Также данное ППО (MCA) — является частью более общего нашего ПО(ППО) ErlMOM (Erlang Message Oriented Middleware), которое позволяет осуществить интеграцию различных приложений и DBS в облачную инфраструктуру посредством обмена сообщениями в рамках конкурентной модели. Однако на практике, нами сейчас активно используется подключение к каше, в других наших проектах подключение к мнезии. Вообще, для обработки многомерных разряженных структур — использовать глобалы, которые по сути и сами есть многомерные разряженные структуры — очень удобно — и строить деревья или графы правил — получается естественно и просто. Также сам процесс создания системы и её частей — был достаточно растянут во времени, и для тех или иных компонент рассматривались, и прототипировались, различные варианты архитектуры, языки, библиотеки. СУБД Cache — нами была выбрана даже ранее, чем язык Erlang.
Никогда не понимал, чего такого многомерного в этих глобалах? Не видел, чтобы где-то реализация раскрывалась, но судя по поддерживаемым операциям — какая-то вариация на тему обычных btree. Термин чисто ради маркетинга?
btree у глобалов на физическом уровне. А так — это разреженный многомерный массив. Здесь неплохо объяснена природа глобалов.
Если вы о mnesia, у нее есть неприятная особенность — крайне долгое восстановление после сбоя, как и у dets, на котором у нее построено файловое хранилище. Mnesia рассчитана на эффективное хранение небольших объемов данных, не более того. Это не СУБД общего назначения.
используйте бездисковую схему и все будет ok.
А бездисковая схема внезапно позволит хранить большие объемы данных? :)) RAM'а всегда меньше, чем диска ;)
К сожалению, документация ерланга «как-бы избегает ответа на этот вопрос» по поводу достатка памяти, но намекает на использование бездисковых схем. Mnesia умеет, находясь в бездисковой ноде, подкачивать данные из дисковой ноды. Иными словами, при подъеме новой бездисковой ноды, как-бы в фоне произойдет подгрузка новых данных с дисковой ноды, если оная присутствует в схеме (вообще это уже неважно т.к. данные будут браться из любой доступной ноды). Не проверял в этом случае расход памяти. Где-то в мануалах по мнезии утверждается, что на 64-разрядной архитектуре вы можете задействовать «RAM-ноды» как результат с практически неограниченным объемом памяти. Это было кажется во «mnesia user manual» или каком-то faq/troubleshooting. Но во мнезии имеет смысл хранить указатели, сессионные данные, структуры, мелкие порции данных, словом классический key\value storage с плюшками. Но никак не хранилище для HD-video. Это не значит, что особо не впихнешь туда данных. Представьте себе рой из 3000 RAM-нод и объем данных, способный уместиться и живущий в этом количестве нод.
Есть и много других проблем.
1) При нескольких млн записях в секунду начинает резко падать скорость. Конечно можно разносить по машинам и балансировать нагрузка. Но количество машин ограничено.
2) Начинаются тормоза при двух млдр мелких записей в базе, даже когда скорость не сильно критична, такие тормоза раздражают.
Потому от mnesia мы отказались в пользу postgres. Гетерогенно и неудобно, но головной боли меньше.
1) При нескольких млн записях в секунду начинает резко падать скорость. Конечно можно разносить по машинам и балансировать нагрузка. Но количество машин ограничено.
2) Начинаются тормоза при двух млдр мелких записей в базе, даже когда скорость не сильно критична, такие тормоза раздражают.
Потому от mnesia мы отказались в пользу postgres. Гетерогенно и неудобно, но головной боли меньше.
Несколько млн записей в секунду это весьма приличная скорость. Мои поздравления!
При росте нагрузки потока сообщений, неоднократно наблюдал, как эрланг начинает захлебываться (вероятно сообщениями). Точнее не он а некоторое заурядное окружение. Все замирало, а потом через некоторое время оживало и т.д.
Добиться максимальной отдачи от одной ноды это почти утопия (за исключением того, что он лучше других умеет работать с несколькими ЦПУ). Эрланг на то и эрланг, что дает средства для построения распределенных вычислений. Соответственно, существенно поднять вычислительную мощность можно за счет приемущественно горизонтального масштабирования через балансировщик-шедуллер.
При росте нагрузки потока сообщений, неоднократно наблюдал, как эрланг начинает захлебываться (вероятно сообщениями). Точнее не он а некоторое заурядное окружение. Все замирало, а потом через некоторое время оживало и т.д.
Добиться максимальной отдачи от одной ноды это почти утопия (за исключением того, что он лучше других умеет работать с несколькими ЦПУ). Эрланг на то и эрланг, что дает средства для построения распределенных вычислений. Соответственно, существенно поднять вычислительную мощность можно за счет приемущественно горизонтального масштабирования через балансировщик-шедуллер.
Спасибо, старались.
Чтобы этого не было, можно попробовать, подкрутить (уменьшить?) число редукций на процесс. Но это грязно. Ну или разбирать конкретный случай, чтобы в очередях было минимальное число сообщений, и всеони пролетали очередь.
+ Сталкивался с проблемой числа файловых дескрипторов на процесс ос, но тут возможно это непричем.
В этом случае, он просто откажется выполнять библиотечные функции.
***
Горизонтально смаштабировать можно и без erlang, было бы на чем масштабировать. Как было сказано выше, мнезия только для мелких порций в малом количестве.
Пробывал redis и leveldb как альтернативу, но что-то с ними как-то не сложилось.
как эрланг начинает захлебываться (вероятно сообщениями)
Чтобы этого не было, можно попробовать, подкрутить (уменьшить?) число редукций на процесс. Но это грязно. Ну или разбирать конкретный случай, чтобы в очередях было минимальное число сообщений, и всеони пролетали очередь.
+ Сталкивался с проблемой числа файловых дескрипторов на процесс ос, но тут возможно это непричем.
В этом случае, он просто откажется выполнять библиотечные функции.
***
Горизонтально смаштабировать можно и без erlang, было бы на чем масштабировать. Как было сказано выше, мнезия только для мелких порций в малом количестве.
Пробывал redis и leveldb как альтернативу, но что-то с ними как-то не сложилось.
А постгрес типа может писать на одной машине несколько млн записей в секунду?
Ага, только немного подкрутить надо.
Писать. На диск. SQL база. Несколько миллионов записей в секунду.
Мы об одном и том же говорим?
Мы об одном и том же говорим?
Писать. На диск.Я не уверен, что современные sql-базы настолько примитивны. Никто не отменял отложенных записей, никто не отменял балков (говорил, же, что, все таки, неудобно).
+ Если и на диск (в чем я крупно сомневаюсь), то смотря какой диск.
Если интересно, могу свести с человеком который непосредственно этим занимался.
А на persistence отдельное хранилище+синхронизация? Ад.
Почему, таки, Yaws? Он тяжел, и есть достаточное число http-аксепторов, библиотек и пр.
Туплы-мутуплы.
Есть хорошее слово в русском языке для перевода tuple — кортеж.
Есть хорошее слово в русском языке для перевода tuple — кортеж.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
СУБД Cache + Erlang