Хотя у всех заинтересованных лиц рсс ридер уже наверняка забит пеаром первого выпуска журнала "Практика функционального программирования", не могу не отметиться тоже.
Tuesday, July 21, 2009
Concepts Get Voted Off The C++0X
Вот тут, по ссылке с ltu: — из C++0x решили убрать concepts! :)
Мне не то чтобы C++0x интересен с практической точки зрения, но это просто мощнейший ход.
Почему убрали: с одной стороны, часть ортодоксов не поняла зачем оно надо, и испугалсь что будет слишком легко отстрелить себе ногу (и это они про C++ говорят, хехе). С другой стороны, комитет по стандартизации испугался что авторы фичи не успеют ее допилить.
Кроме того, примечателен первый же камент от одного из авторов этой фичи — судя по тому, что он три раза упоминает там хаскель, становится совсем уж окончательно понятно откуда чуваки черпали вдохновение.
(Поскольку не все читатели моего бложека являются сиплюсплюс программерами, вкратце поясню — concepts была одной из наиболее ожидаемых фич нового стандарта популярного когда-то языка сиплюсплюс, что-то похожее на type classes в хаскеле)
Sunday, January 25, 2009
Yaws и потребление памяти
Уважаемые телерадиослушатели, мегаблог не совсем умер :)
В комментариях к записи про Yaws жжюзер ![[info]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_uHS4PPYqHZ4EPq6GHu2IIAHMSFMPAhP09AItcCOvXQ1l6c0tD3Mjmp1fpySnwYPKslR_CKX_G9i-aiPROFgTT-MgBPB10iK9j7ivzYo4kt=s0-d){kind=small}
Итак, берем yaws 1.79, в качестве генератора траффика программка на C, за основу взял пример работы с epoll какого-то японца.
Тупо создаем соединения к серверу, запрашиваем файл и мееедленно (по байту) читаем ответ.
$ uname –a Linux lrrr-laptop 2.6.24-23-generic #1 SMP Thu Nov 27 18:44:42 UTC 2008 i686 GNU/Linux
График:
По оси X — количество одновременных соединений, по Y resident size процесса в килобайтах. Понятно, тут хватило б и двух точек, но мало ли что, вдруг, например, gc стал бы захлебываться с какого-то момента, надо было удостовериться.
После 10000 соединений у меня yaws начинает их дропать, хотя наверняка можно это как-то победить, в связи с убогостью тестовых условий я решил не заморачиваться.
Итого, если поделить — отжирается 14 кб памяти на коннект. Неплохо. Yaws (ожидаемо) не кушал CPU (показатель болтался около 1-2%), но, почему-то, довольно медленно принимал соединения — удавалось создать порядка 10 коннектов в секунду.
Попытка поставить в те же условия nginx пока не увенчалась успехом, соединения создаются раз в десять быстрее, но в районе 700 коннектов nginx сначала отдает 500 ошибку, потом молча закрывает соединения, а потом начинает приходить ECONNRESET. Думаю, он это делает из лучших побуждений, но я пока не нашел как на это повлиять.
Wednesday, July 02, 2008
Erlang job 2
И, чтоб два раза не вставать: тут обнаружилась еще одна интересная вакансия в России (Москва) на Эрланге, в стартап http://artytalk.com/:
Server-side developer:
— Писать вместе с командой application server под нагрузку в миллионы пользователей (Erlang, Amazon Elastic Cloud)
— Иметь серьезный опыт разработки высоконагрузочных масштабируемых приложений
— И снова — любить наш проект, быть хорошим и веселым человеком с мотивацией сделать мир лучшим местом
Io
Тут Семка после сдачи диплома активно взялся за язык io, и генерирует чуть ли не ежедневно крайне познавательные статьи про него, очень рекомендую: раз, два, три.
Язык крайне приятный, очень объектно-ориентированный и минималистичный, любителям smalltalk, javascript, ruby или lisp должно понравиться.
Кроме того, у нас есть целый irc канал #io-ru на freenode, так что если ио заинтересовал — присоединяйтесь, да и просто заходите, там уже тусуется некоторое количество знатных рубихакеров и хаскелеводов.
Wednesday, May 21, 2008
Map/Reduce своими руками — Apache CouchDb
Предупреждаю — мой взгляд совершенно не претендует на какую бы то ни было объективность. Но реляционные базы данных
меня никогда, мягко говоря, не вдохновляли.
Нет, я вполне понимаю когда у вас действительно приложение ориентировано на обработку и хранение больших массивов данных. Ну, ERP-системы, всякие хранилища, статистика там, "в прошлом месяце продали сто тыщ карандашей, в этом двести".
С другой стороны, в большинстве случаев, когда речь идет о десктопных (или веб-) приложениях, где не нужно ворочать миллионами примитивных записей, а приложение работает с относительно высокоуровневыми, сложными объектами, суть "дизайна и проектирования баз данных" заключается в повторении двух действий:
а) расколупать эти высокоуровневые объекты на кучу простейших полей — чисел, строк и сложных зависимостей между ними, и раскидать между десятками таблиц. Обычно это не очень сложно, однако некоторые (или многие?) типы данных не так уж приятно и органично раскладываются в этой модели — например, теги у записей в блоге;
б) затем упорно собирать эти поля в объекты обратно, пользуясь четырехэтажными JOIN'ами, мегабайтами кода врапперов, кривыми и не очень слоями ORM — в зависимости от квалификации разработчика, в общем, всячески преодолевать пресловутый O/R impedance mismatch. При этом и рукописные JOIN'ы не показывают чудеса производительности и гибкости, а сгенеренные автоматически умным слоем врапперов — тем более.
В общем, немало приложений используют базы данных для хранения сложных структур данных, и при этом действительно сложные запросы с использованием внутренних зависимостей к этим данным им на практике нужны редко, или вообще не нужны (если не считать мега-JOIN'ов для того, чтобы просто обратно выковырять эти свои структуры из БД). Похоже, обычная RDBMS мало подходит для них — упомянутые выше проблемы довольно болезненно решаются, а миллионы человекочасов тратятся разработчиками БД на реализацию других, бесполезных для них возможностей.
Одним решением являются объектно-ориентированные хранилища, они действительно становятся довольно популярны и заслуживают отдельного разговора. Они прозрачно решают проблему с ORM, но, если говорить о веб-приложениях (которые весьма интересуют нас в свете обещаной новой версии defun.ru :), объектно-ориентированные базы это таки не совсем то, что доктор прописал — они не решают проблем горизонтальной масштабируемости и распределенности данных, да и веб — это прежде всего много текстовой информации, неплохо было бы как-то учесть и это.
Итак, CouchDb — документоориентированная база данных. Хранить она умеет документы — объекты, состоящие из кучи полей с произвольной структурой. У каждого документа есть только два обязательных служебных поля: имя и версия, имена уникальны и находятся в линейном пространстве — представьте себе гигантскую директорию с файлами-документами, вроде такого:
{
"_id":"63086444D554D3094C080F96D5005B03",
"_rev":"1837603925",
"author":"lrrr",
"tags":["baz","test","ru"],
"url":"http:\/\/incubator.apache.org/couchdb",
"title":"couchdb home",
"description":"boo boo ba ba",
"type":"story",
"comments":1,
"votes":2
}
Версии нужны для организации параллельного доступа к базе данных — вспомните как работает ваша система контроля версий — если мы хотим изменить документ, мы просто берем его, меняем и пытаемся положить обратно — если за это время его версия не поменялась, все отлично, если поменялась — можно просто попробовать внести те же изменения еще раз, с новым документом, или еще как-то сделать merge (в зависимости от приложения). Это называется optimistic locking, основной плюс — никто не блокирует документ на время редактирования, и поэтому не нужно ждать разблокировки. Кстати, такой механизм может применяться и в некоторых современных RDBMS, только на уровне строк в таблице (см. http://www.google.com/search?q=%22row+versioning%22).
Зато масштабироваться вширь все должно отлично — в конце концов, примерно по такой схеме построены и Amazon SimpleDb, и Google BigTable. Удивительное, кстати совпадение, но и SimpleDb, и CouchDb написаны на эрланге ;)
Что выгодно отличает CouchDb от сервисов гугла и амазона, так это более "продвинутая" функциональность в области запросов к данным.
Естественно, что менее структурированные данные обрабатывать сложнее, и, раз уж мы так заботимся о масштабируемости — запросы эти тоже должны легко распределяться по кластеру серверов БД. Для этого CouchDb использует паттерн map/reduce, описаный в известной статье инженеров Google.
На практике выглядит это так: на сервере, в специальных документах хранятся view-функции (собственно map() и reduce()), преобразующие набор документов нужным образом, и к ним можно обращаться с помощью того же REST интерфейса. Вычисляться они умеют постепенно, с сохранением промежуточных результатов, то есть, если между двумя вызовами view добавился или изменился один два документа, то функция будет вызвана только для них. Пишутся они на JavaScript, но можно несложно подключить вместо этого python/ruby/что-то еще.
В качестве дополнительного бонуса — поддержка полнотекстового поиска по документам, с помощью любой внешней библиотеки (пока авторы прикрутили к CouchDb поисковик Apache Lucene).
* * *
В конце обычно принято немного попинать рассматриваемую технологию, но CouchDb мне пинать пока жалко — слишком приятное впечатление производит. Хотя, конечно, это пока всего лишь альфа-версия, со всеми вытекающими последствиями (reduce, скажем, появился в транке три дня назад). Да, она очень небыстрая — пока умеет обрабатывать порядка десятков insert'ов в секунду (если не использовать режим bulk update) и да, она жрет очень много дискового пространства — так как все промежуточные версии документа сохраняются, если их периодически не удалить специальной функцией "Compact Database" — впрочем, это можно делать параллельно, не останавливая приложение. Однако для альфы система весьма стабильна и уже имеет, среди всего прочего, очень приятный и функциональный веб-интерфейс для администрирования и разработки.
Ссылки:
- Официальный сайт проекта
- Damien Katz — ведущий программист CouchDb
- Блоги еще двоих: Christopher Lenz, Jan Lehnardt
- Top 10 Reasons to Avoid Document Databases FUD — хорошая статья, почему не надо бояться нереляционных баз данных
- Amazon SimpleDB and CouchDB compared
- Ajatus — распределенная CRM-система, использующая CouchDb
27723148.0f886b0078628df55b2305efb1cb3729.1211322056.6554977ddd1d9ebd9f3e14154e6e8540
Subscribe to:
Posts (Atom)
