Ограничения EST и DEST
Юрий Джур
Max Lapshin
> Тут начальство на днях наткнулось на перевод Erl-банкинг и впало в
> когнетивный дисонанс... В общем сижу теперь изучаю язык.
> Так вот, в принципе с синтаксисом и основами работы разобрался, а вот
> некоторые моменты остались, мягко говоря не понятны.
>
> Собственно первый вопрос связан с ограничениями на ETS/DETS:
> Наткнулся на упоминание что DETS ограничен 2Гб. Так ли это? И какие еще
> ограничения ETS/DETS существуют?
DETS не умеет восстанавливаться после аварийного выключения. Короче,
это вообще не БД, а файл конфигурации.
Юрий Джур
DETS не умеет восстанавливаться после аварийного выключения.
Короче, это вообще не БД, а файл конфигурации.
Max Lapshin
>> DETS не умеет восстанавливаться после аварийного выключения.
>
> В смысле если VM эрланга умрет во время записи в DETS погибнет весь файл
> или будут потеряны те данные которые в это время записывал?
>
Если VM эрланга умрет и не успеет явно закрыть dets файл, размером в
500 мб и больше, то восстановление
потребует несколько часов. Это очень и очень много.
>> Короче, это вообще не БД, а файл конфигурации.
>
> Ну я понимаю что это не БД, просто в книге были такие слова как: "хеш" и
> "ключ-значение", вот я и подумал что это что-то вроде механизма BDB.
>
Теоретически, это очень удобная БД, в которой можно быстро и надежно
хранить erlang term-ы.
Если бы она была шустрой, это было бы очень быстро, потому что всё в
памяти и рядом.
На практике, её персистентность удручает.
Юрий Джур
Если VM эрланга умрет и не успеет явно закрыть dets файл, размером в
500 мб и больше, то восстановление
потребует несколько часов. Это очень и очень много.
Vladimir Gordeev
Ибо если привязываться к SQL базам, то язык свою привлекательность резко теряет.
Андрей П. Ковбович
30 мая 2012 г., 9:23 пользователь Юрий Джур <qra...@mail.ru> написал:
Maxim Treskin
--
Страница рассылки: http://groups.google.com/group/erlang-russian
Новости: http://erlanger.ru
Написать письмо: erlang-...@googlegroups.com
Отписаться: erlang-russia...@googlegroups.com
Maxim Treskin
Юрий Джур
> Тут начальство на днях наткнулось на перевод Erl-банкинг
Можно узнать ссылку на перевод?
Юрий Джур
Ибо если привязываться к SQL базам, то язык свою привлекательность резко теряет.Почему?
Maxim Treskin
--
Страница рассылки: http://groups.google.com/group/erlang-russian
Новости: http://erlanger.ru
Написать письмо: erlang-...@googlegroups.com
Отписаться: erlang-russia...@googlegroups.com
Maxim Treskin
Max Lapshin
> замена кода в нем тоже есть, так как он выполняется как скрипт. И кластер на
> PHP организовать не трудно.
Мне противно что-то обсуждать с человеком, который считает, что можно
писать веб на PHP.
Я из топика сваливаю.
Юрий Джур
Мне противно что-то обсуждать с человеком, который считает, что можно
писать веб на PHP.Я из топика сваливаю.
Vladimir Gordeev
Мне противно что-то обсуждать с человеком, который считает, что можнописать веб на PHP.
Я из топика сваливаю.
Андрей П. Ковбович
древняя какая-то статья и пример игрушечный.
30 мая 2012 г., 12:25 пользователь Юрий Джур <qra...@mail.ru> написал:
Артём Семёнов
Именно. Спросите у бухгалтерии <<что выгоднее: два сервера или 20>>. И
код на эрланге поддерживать проще, чем макаронину на псевдоязыке, в
котором, грубо говоря, даже нет понятия состояния. А сколько точек
отказа появится в виде memcache/redis (которые еще нужно как-то
шардить) и ampq. За всем этим зоопарком нужно как-то следить, каким-то
дополнительным супервизором (про персистентность, стремящуюся к 100% и
вовсе можно забыть).
И вообще, см. google://soft realtime , наверное.
30 мая 2012 г., 12:47 пользователь Юрий Джур <qra...@mail.ru> написал:
Led
PHP-Ынтырпайз - он такой - жестокий и беспощадный, руководствуется "статьями" с хабра, и, когда, вроде бы, заходят в
рассылку спросить что-нибудь, на самом деле учат нас, лохов, что правильно и выгодно в "бизнесе".
--
Led
Un Lexx
Не думаю что тут много народу которые будут вас убеждать использовать Erlang. Колхоз дело добровольное.
А по поводу механизмов хранения - в Erlang можно использовать любую удобную для вас БД - более того можно даже навелосопедить что то свое
хотя не думаю что это имеет смысл выкладывать в продакшн.
конкретно про DETS Макс вам уже отписал. Подчеркну Erlang вполне можно использовать как клей обеспечивающую соединения между элементами системы и никто не требует чтоб все подсистемы были обязательно реализованы в Erlang есть порты, есть nif, есть просто "драйвера" - обвязка вокруг БД.
Dmitrii Dimandt
dmitryme
Юрий Джур
***
В общем, всем кто принялся холиварить, высказываю свое ФИ. Уважаемые, если считаете себя сообществом, нефиг на людей с кулаками кидаться, не прочитав всех сообщений ветки. Это как минимум неправильно.
Илья Аржанников
--
Страница рассылки: http://groups.google.com/group/erlang-russian
Новости: http://erlanger.ru
Написать письмо: erlang-...@googlegroups.com
Отписаться: erlang-russia...@googlegroups.com
с Уважением Аржанников Илья
Anton Fedorov
данных.
В письме от Срд, 30 Май 2012, 20:48 Илья Аржанников пишет:
>
> 30 мая 2012 г., 19:43 пользователь Юрий Джур <qra...@mail.ru> написал:
>
>> Erlang.
>> А причем тут это? Это я к вам зашел с вопросом, а не вы ко мне с рекламой,
>> значит я изначально очень даже ЗА был. :)
>>
>> соединения между элементами
>> > в Erlang можно использовать любую удобную для вас БД
>> Да в том то и дело что я НЕ ХОЧУ городить зоопарк из баз, кешей и прочего.
>> Когда появляются SQL-сервера, появляется и централизованность, что нам не
>> очень то и удобно.
>>
>> ***
>>
>> В общем, всем кто принялся холиварить, высказываю свое ФИ. Уважаемые, если
>> считаете себя сообществом, нефиг на людей с кулаками кидаться, не прочитав
>> всех сообщений ветки. Это как минимум неправильно.
>>
>>
>> Ваши фотографии... Нет, не конкретно ваши, а тех кто имел честь улыбнутся
>> в где-нибудь посреди города. Видеонаблюдение, в каком-то в смысле.
>> Собственно потому и эрланг, ибо в идеале позволяло получить однородную
>> структуру на нескольких компьютерах.
>>
>> --
>> Страница рассылки: http://groups.google.com/group/erlang-russian
>> Новости: http://erlanger.ru
>> Написать письмо: erlang-...@googlegroups.com
>> Отписаться: erlang-russia...@googlegroups.com
>>
>
>
>
> --
> с Уважением Аржанников Илья
>
> --
> Страница рассылки: http://groups.google.com/group/erlang-russian
> Новости: http://erlanger.ru
> Написать письмо: erlang-...@googlegroups.com
> Отписаться: erlang-russia...@googlegroups.com
>
--
Anton Fedorov
Call2ru service
E-Mail: datac...@call2ru.com
Jabber: datac...@call2ru.com
Skype: datacompboy
ICQ: 272-35-262
Mobile: +7-913-925-7974 [SMS 24h, Call 05:00-19:00 MSKT (GMT+3)]
Ilya Shuma
среда, 30 мая 2012 г., 17:54:33 UTC+4 пользователь Anton Fedorov написал:
>> Написать письмо: erlang-russian@googlegroups.com
>> Отписаться: erlang-russian+unsubscribe@googlegroups.com
>>
>
>
>
> --
> с Уважением Аржанников Илья
>
> --
> Страница рассылки: http://groups.google.com/group/erlang-russian
> Новости: http://erlanger.ru
> Написать письмо: erlang-russian@googlegroups.com
> Отписаться: erlang-russian+unsubscribe@googlegroups.com
Юрий Джур
Я так понимаю, вы хоть в теме. Если мнезию тоже использовать не айс, что посоветуете? И большие данные это сколько примерно?
Илья Аржанников
--
Страница рассылки: http://groups.google.com/group/erlang-russian
Новости: http://erlanger.ru
Написать письмо: erlang-...@googlegroups.com
Отписаться: erlang-russia...@googlegroups.com
dmitryme
Илья Аржанников
--
Страница рассылки: http://groups.google.com/group/erlang-russian
Новости: http://erlanger.ru
Написать письмо: erlang-...@googlegroups.com
Отписаться: erlang-russia...@googlegroups.com
Anton Fedorov
вкратце: берётся таблица, заливается туда 100 метров, beam убивается,
перезапускаем, замеряем время подъёма.
заилваем 200 метров, повторяем.
500, повторяем.
делаем для себя личные выводы.
В письме от Срд, 30 Май 2012, 21:00 Ilya Shuma пишет:
>> >> Отписаться: erlang-russia...@googlegroups.com
>> >
>> >
>> >
>> > --
>> > с Уважением Аржанников Илья
>> >
>> > --
>> > Страница рассылки: http://groups.google.com/group/erlang-russian
>> > Новости: http://erlanger.ru
>> > Отписаться: erlang-russia...@googlegroups.com
>>
>>
>> --
>> Regards,
>> Anton Fedorov
>> Call2ru service
>> E-Mail: datac...@call2ru.com
>> Jabber: datac...@call2ru.com
>> Skype: datacompboy
>> ICQ: 272-35-262
>> Mobile: +7-913-925-7974 [SMS 24h, Call 05:00-19:00 MSKT (GMT+3)]
>>
>>
>
> Страница рассылки: http://groups.google.com/group/erlang-russian
> Новости: http://erlanger.ru
> Отписаться: erlang-russia...@googlegroups.com
Anton Fedorov
В письме от Срд, 30 Май 2012, 21:04 Юрий Джур пишет:
> посоветуете? И большие данные это сколько примерно?
Serge Matveenko
> В письме от Срд, 30 Май 2012, 21:04 Юрий Джур пишет:
>> Я так понимаю, вы хоть в теме. Если мнезию тоже использовать не айс, что
>> посоветуете? И большие данные это сколько примерно?
>
> я использую pgsql, хочу уйти на что-нибудь из nosql.
mongodb. welcome! есть драйвер для erlang
--
Serge Matveenko
se...@matveenko.ru
http://www.ohloh.net/accounts/lig
http://ru.linkedin.com/in/sergematveenko
Vladimir Gordeev
> я использую pgsql, хочу уйти на что-нибудь из nosql.mongodb. welcome! есть драйвер для erlang
Serge Matveenko
я имел в виду именно его. видел где-то на просторах гитхаба еще один
неофициальный, но сейчас ссылку не смог найти
Vladimir Gordeev
неофициальный, но сейчас ссылку не смог найтия имел в виду именно его. видел где-то на просторах гитхаба еще один
Un Lexx
> Когда появляются SQL-сервера, появляется и централизованность,
спорное утверждение. шардинги горячий резерв никто не отменял.
про хранение файлов на диске вам уже сказали. индексы можно держать где угодно
про обьемы и медленный подьем например мнезии -> пока нет тестов в
вашей предметной области дело сфероконное.
так же не могу понять:
> Собственно потому и эрланг, ибо в идеале позволяло получить однородную структуру
> на нескольких компьютерах.
это вы так странно сформулировали про единую виртуальный Erlang
кластер(ноды) или про систему деплоя erlang кода на несколько
физических машин в горячем режиме?
30.05.12, Vladimir Gordeev<gordeev.v...@gmail.com> написал(а):
>>
>> я имел в виду именно его. видел где-то на просторах гитхаба еще один
>> неофициальный, но сейчас ссылку не смог найти
>
>
> видимо вот этот: https://github.com/JacobVorreuter/emongo
>
chemist
Юрий Джур
unlexx
это вы так странно сформулировали про единую виртуальный Erlang
кластер(ноды) или про систему деплоя erlang кода на несколько
физических машин в горячем режиме?
Chernomorets Sergey
Eugene Lisitsky
--
Страница рассылки: http://groups.google.com/group/erlang-russian
Новости: http://erlanger.ru
Написать письмо: erlang-...@googlegroups.com
Отписаться: erlang-russia...@googlegroups.com
Yours,
Eugene Lisitsky
Юрий Джур
Dmitry Groshev
из-за которых он хорош. Не с точки зрения абстрактного менеджера, а с
точки зрения <<линейного программиста>>, как выразился один мой
знакомый.
Эрланг очень простой и достаточно сложный язык одновременно. Что
касается его простоты -- я думаю, вы её уже оценили; язык действительно
изучается достаточно быстро, особенно по сравнению с другими
функциональными языками. Сложный же он из-за того, что в нём много
ограничений, на первый взгляд кажущихся нелогичными, некоторые вещи
выглядят странно, а некоторые кажутся откровенно сырыми. Однако при
этом язык разрабатывается уже более 20 лет, за ним стоит прекрасная
команда инжинеров с большим опытом в построении реально больших и
реально отказоустойчивых систем (до того, как сегодняшние проблемы
возникли в Интернете, их решали десятки лет в телекоме -- банально
заставляя ваш телефон работать достаточно быстро и эффективно,
несмотря ни на какие перегрузки, 24/7). Виртуальная машина Эрланга
представляет из себя очень продуманную, красивую и быструю (для набора
реализованных фич) конструкцию -- пожалуй, это лучшая виртуальная
машина на сегодняшний день, если не считать коммерческие штуки вроде
Java, ориентированные на <<чистую>> скорость а-ля <<считаем факториал
почти так же быстро, как С>>. При этом Эрлангом пользуется достаточно
много людей со специфичными задачами -- и так получилось, что в
последнее время в Интернете всё больше таких задач. Всё вышеизложенное
было предисловием к одной мысли: если что-то кажется странным или
сырым, оно либо специально таково, либо никому особо не нужно (либо, в
некоторых случаях, не нужно было Ericsson'у).
Теперь давайте посмотрим на DETS/Mnesia. Несмотря на утверждения
разнообразных товарищей и мнимую простоту, реализация полноценной базы
данных -- очень сложная задача, полная внутренних противоречий и
вынужденных полумер. Посмотрите на примеры из реальной жизни: Mongo,
которая была написана реально быстро и малым количеством людей, с
одной стороны, способна терять данные и имеет кучу проблем, заложенных
в архитектуру (потому как делать по-другому не было людей); MySQL
пилится огромным количеством людей, достаточно быстрая, но весьма
бедна на по-настоящему реляционные фичи (начиная от partitioning и
заканчивая OLAP), и никогда их не получит, скорее всего; PostrgreSQL
пишет не меньшее количество людей, пишет <<по науке>>, и тем не менее
скорость её развития не очень высока и она во многом очень сильно
проигрывает монстрам от Oracle/MS, на которые убиты миллионы
человеколет. Поэтому, несмотря на кажущуюся простоту, написать
<<универсальную>> базу данных невозможно, а приблизиться к
универсальности очень сложно, долго и дорого. Это может быть незаметно
для человека, который просто ставит базу из репозитория, для которого
это <<чёрный ящик>>, но это так. Поэтому неудивительно, что выбирая из
различных фич авторы Erlang'а (напомню, это работники компании
Ericsson, основной бизнес которой -- телефонное оборудование, которому
не нужно хранить террабайты информации, но нужно быть крайне надёжным)
выбрали для своей базы надёжность и приемлемую скорость на небольших
объёмах данных (в чём Mnesia вполне хороша, без дураков). Дальше же
они занимались в основном самой виртуальной машиной вместо сизифова
труда написания <<универсальной>> базы данных, а пользователи особенно и
не хотели от них срочного развития механизма DETS.
Чего же хотели пользователи? Собственно, того, для чего машина и
делалась -- стабильности, скорости (не сырой скорости <<посчитать числа
фибоначчи как можно быстрее>>, а как бы <<интегральной>>, состоящей в
очень большой степени из обработки ошибок, записи в сокеты, в файлы,
выделения памяти и прочей ерунды, о которой подавляющее большинство
веб-девелоперов даже не задумывается). Именно это было и есть
приоритетом в разработке; именно это получается у Эрланга лучше всего
-- подтверждением чему, например, является erlyvideo (сервер потокового
вещания видео) за авторством присутствующего тут Макса Лапшина,
который был написан *очень* быстро для такого класса приложений, очень
стабилен и быстр (безусловно, наняв несколько сотен высококлассных
С-программистов, можно было бы сделать в 2-3 раза более быстрый
сервер, но они стоили бы гораздо больше, чем покупка лишнего сервера).
Поэтому если вы всё-таки решите писать на Эрланге, вы можете ожидать,
что у вас не будет проблем с:
-обработкой ошибок (серьёзных ошибок вроде <<у нас упала база
данных>>/<<у нас ошибка в коде>>);
-обучением новых программистов;
-построением новых <<жирных>> систем, способных обрабатывать десятки
тысяч запросов в секунду, рационально расходуя память и ресурсы и
адекватно ведущих себя в случае их нехватки;
-поддержанием работоспособности хрупкой конструкции из
балансировщика/десятка процессов похапэ/кеша для БД/менеджера
процессов/... -- это всё становится ненужно;
В то же самое время у вас будут проблемы:
-с форматированием текста (попутно вам придётся узнать и начать
задумываться о том, как же именно хранятся строки в памяти и почему);
-с необходимостью снова начать учиться, отбросив свои представления об
<<отказоустойчивых и высоконагруженных системах, обрабатывающих сотни
тысяч запросов в сутки>>, столь распространённые сейчас;
-с редактором для вашего кода (рекомендую всё-таки начать использовать Emacs)
-с юникодом (вы узнаете о codepoints, какие бывают юникоды, почему
нельзя просто конкатенировать юникодные строки и чем юникод отличается
от UTF-8).
При этом:
-все вышеназванные проблемы реально есть в любом языке, который вы
возьмёте, но они прячут их от вас за слоями неэффективных абстракций,
что в конечном счёте выливается в гигабайтах впустую израсходованной
памяти;
-вы однозначно станете лучшим программистом, чем были;
-все вышеназванные проблемы решаются проще, чем то, с чем у вас не
будет проблем в Erlang'е. Другими словами, цитируя автора языка Джо
Армстронга, вы сможете с лёгкостью делать сложные вещи и сможете *в
принципе* делать простые. Мне кажется, делать решаемыми сложные
проблемы более важно, чем делать простые вещи ещё проще.
Если соберётесь что-нибудь читать, я посоветую книгу Джо Армстронга, а
после неё OTP in Action.
2012/5/30 Юрий Джур <qra...@mail.ru>:
> Тут начальство на днях наткнулось на перевод Erl-банкинг и впало в
> когнетивный дисонанс... В общем сижу теперь изучаю язык.
> Так вот, в принципе с синтаксисом и основами работы разобрался, а вот
> некоторые моменты остались, мягко говоря не понятны.
>
> Собственно первый вопрос связан с ограничениями на ETS/DETS:
> Наткнулся на упоминание что DETS ограничен 2Гб. Так ли это? И какие еще
> ограничения ETS/DETS существуют?
> Просто из книги следует, что на основе ETS/DETS я могу сделать удобное для
> моей задачи хранилище данных, а их 5M записей объемом в 200Гб.
>
Max Lapshin
че, правда что ли?
Dmitrii Dimandt
«none of the normal forms are closed under string concatenation, meaning that the concatenation of two strings in the same normal form may not be itself in that normal form. This happens, for example, when a base character at the end of the first string is modified by combining characters at the beginning of the second string.»
>> почему нельзя просто конкатенировать юникодные строки и чем юникод отличается от UTF-8).
>
> че, правда что ли?
>
Michael Uvarov
символов, которые нужно нормализировать.