Сортировка по данным в анонимном хеше

Задача: отсортировать данные разнесенные по множеству серверов Postgres.

С ходу придумал два решения:

1. Собрать данные скриптом и обработать.
2. Написать server side функцию, которая установит dblink-соединение со всеми необходимыми севрерами, прогонит запрос по ним и вернет агрегированные данные. Необходимый запрос передается параметром.

Решение задачи первым методом:

Есть небольшая сложность: полей данных более, чем два. В случае C я бы использовал структуры. Но в Perl нет структур в комплете (хотя можно подобрать модуль). Я предпочел складывать данные ссылкой на анонимный хеш в хеш ( переменная %result ) :) Правда потом немного сложно сортировать эти записи. Собственно поэтому и пишу пост, магия сортировки происходит в третьей с конца строке:


Решение вторым методом пока не реализовывал. Сделаю - дополню пост.

Облака: выдумки маркетологов или реальность?

Представляю вашему вниманию текст моего выступления на Ulcamp 2011.

Сейчас "облака" - это один из мировых трендов. Только ленивый сейчас не говорит об "облаках". И если какой-то маркетолог не говорит про "облака", то это наверное мертвый маркетолог :) Мы же, хотим рассказать про "облака" с точки зрения сервиса, который реально их использует, которым пользуются больше 70 тысяч пользователей. Мы хотим показать вам "грязную", "неприкрытую" подноготную облаков.

Что могут рассказать вам об "облаках" маркетологи? Вот это. Что вам больше не надо париться об обслуживании, масштабировании, безопасности, доступности и бла-бла-бла... всего вашего хозяйства. Звучит красиво :)

И, да. Все это есть в "облаках". До появления облаков нужно было покупать лицензию на каждую машину. Теперь есть "облачные" решения: Google Docs, Gmail, Autocad WS. Появилось много решений, не имевших аналогов ранее: Dropbox, Yammer, Juniper Junosphere.

"Облака" делают более доступными программные продукты, которыми раньше мы не могли пользоваться из-за стоимости или технической сложности. Сравните сложность внедрения shopping cart-решения в существующий сайт до появления Ecwid и теперь. Яна Франк отлично описала свои "приключения".

Однако, "облака" - это прежде всего техническое решение, не маркетинговое. На самом деле, каждое "облачное" решение индивидуально. Начиная от механизмов виртуализации серверов (XEN, VMware, Jail) и заканчивая всем спектром SaaS решений.
Даже сами "облака" бывают разными:

- Infrastructure as a Service ( IaaS ) - это облако предоставляющее инфраструктуру. Вы нажимаете несколько кнопок, и у вас появляется полноценный сервер. Делаете запрос по API, и вас появляется еще десяток абсолютно таких же серверов. Красота!
Примеры: Amazon Web Services, Rackspace Cloud Services, GoGrid Cloud Hosting.

- Platform as a Service ( PaaS ) - это облако, которое дает вам платформу. Вы просто пишете программу в соответствии с предопределенными правилами, нажимаете кнопку “Deploy” и она живет дальше сама. Платформа обеспечивает ее работу за вас.

Примеры: Google App Engine, Echo StreamServer, Heroku, Azure Services Platform.

- Software as a Service ( SaaS ) - это законченный сервис. Если предыдущие решения используют разработчики, то эти работают с обычными пользователями.

Примеры: Ecwid, Google Docs, Gmail, Dropbox, Yammer, Autocad WS, Juniper Junosphere.

Когда вы говорите об "облаках", пожалуйста, уточняйте какой из “aaS” вы имеете ввиду :) Потому что SaaS Ecwid живет в IaaS Amazon EC2. Облако живет в облаке. Нам еще остается как-нибудь с Echo StreamServer’ом интегрироваться и полный набор облаков получится :)
Да, снаружи они тоже выглядят красиво, и даже блестяще. Но, вся "облачность" ограничивается их архитектурой. Об этом маркетологи, обычно умалчивают - зачем стеснять обывателей?

Например, Ecwid до недавнего времени хранил изображения продуктов на своих серверах. Представьте, у вас есть сервер, на котором хранятся картинки клиентов. Жесткие диски на сервере имеют конечный размер. Угадайте, насколько безразмерной является возможность заливать изображения продуктов? Да, все эти вопросы решаемы либо автоматизацией, либо изменениями в архитектуре. В данном случае не было архитектурных изменений, пока у нас не накопилось 5,5 миллионов картинок. Теперь картинки благополучно живут в безразмерном вместилище Amazon S3.

К чему это я? К тому что, обычно, за красивыми словами об автоматической масштабируемости обычно скрывается труд инженеров, которые ищут оптимальные решения в нашем мире ограниченных возможностей.

К слову о доступности. Что бы вам не обещали маркетологи, все "облака" работают на реальном железе. И, вы не поверите! Железо иногда "умирает"...

Возьмем пример: Amazon EC2. Известный IaaS сервис. Нажал кнопку - получил сервер. Однако, этот сервер работает на каком-то реальном, физическом железе. Что произойдет, если этот физический сервер умрет? Правильно, умрет и ваш хост. Да, инженеры Amazon мониторят железо, и да если железо умирает, то они скорее всего могут прозрачно переселить вас на другой хост. Если успеют. На моей памяти, сервера на Амазоне умирали навсегда несколько раз. Ваши действия в этом случае зависят от архитектуры: один сервис “не заметит” пропажи сервера, а у другого будет частичная недоступность, третий будет лежать целиком и полностью...

А что если умирает не хост-система, а сетевое оборудование? 21-го апреля 2011 года во время сервисных работ с сетевым оборудованием, основной поток трафика был ошибочно перенаправлен на вспомогательную сеть. Эта ошибка вызвала каскадное падение нескольких сервисов. В том числе сервиса, отвечающего за предоставление жестких дисков (Amazon EBS).  Множество серверов в этом регионе Амазона не было доступно в течение трех дней! Во время этого фейла лежала целая пачка известнейших сервисов. Вот замечательная коллекция сообщений о недоступности достаточно известных сервисов, затронутых тем несчастьем. Вот так "облака" опускаются на землю... Нам тогда повезло - нас не задело. Сервера падали вокруг, а мы счастливчики.

Амазон предоставляет несколько возможностей, чтобы избежать подобных проблем. Но это тема для отдельного выступления.

Далее. Есть такой сервис как Amazon S3, который позиционируется как мегаофигенное хранилище. Только они могут себе позволить упасть на 20 минут, именно столько были недоступны те самые картинки продуктов в Ecwid незадолго до этого выступления.

"Облака", вообще в последние годы стало модным словом. Все хотят быть "облачными". Даже последний VPS-провайдер не стесняется называть себя “облачным хостингом”. Хотя единственное, что он умеет делать - это давить ресурсы на хост-системе, чтобы засунуть побольше серверов на одно железо. А потом торжественно приоткрывать кран и называть это “облачным выделением ресурсов” :)

Такой спрос на “облачность” обесценил само понятие. Когда мне говорят про очередное “облачное” решение, я спрашиваю в чем заключается его "облачность". Давайте оставим право говорить об "облаках" маркетологам. А мы будем называть технологии своими именами.



Спасибо за внимание.

Деление текстового файла по шаблону

awk '/PATTERN/{i++}{print > "file.out."i}' file

А еще можно воспользоваться утилитой csplit из coreutils. Последний способ намного более удобен :)

CA сертификаты в Perl-скриптах в Debian

Если ваш скрипт внезапно перестал корректно соединяться с серверами по https и начал возвращать что-нибудь вроде этого:

error: 500 Can\'t connect to www.google.com:443 (certificate verify failed)';
Can't connect to www.google.com:443 (certificate verify failed)

LWP::Protocol::https::Socket: SSL connect attempt failed with unknown errorerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl/5.10.1/LWP/Protocol/http.pm line 51.

Это вполне может означать, что клиент больше не знает где искать CA сертификаты. Помогите ему, подскажите, где искать. Добавьте:

$ENV{HTTPS_CA_DIR}="/etc/ssl/certs";

Как создать раздел на весь диск?

Подобное может понадобиться в скрипте. Итак, создать раздел на весь диск размером можно следующей командой:

/bin/echo ",,," | /sbin/sfdisk -L /dev/sdX

Восстановление MyISAM таблиц при восстановлении раздела из снапшота

Оставлю здесь, путь лежит

find /$PATH/db/ -name "*.MYI" -exec myisamchk --silent --force --fast --update-state {} \;

JOIN по нескольким таблицам.

YAML в perl'отворчестве

Задача: вы пишите большой perl-скрипт, который должен выполнять длительные/рутинные операции. Вы взрослый мальчик и не боитесь CPAN. Вы используете самые вкусные модули, которые помогают вам писать быстро и без изобретения велосипедов. Некоторые длительные операции порождают объекты (да, вы совсем взрослый мальчик), с которыми вы и работаете дальше.

Проблема: Чем длительнее операции, которые выполняются скриптом, тем больше времени вам требуется чтобы отладить скрипт... Например, скрипт добирается до места отладки только через 15 минут. А если при этом каждый раз выделяются значительные ресурсы?

Решение: Сериализация/десериализация объектов.

В частности, мне подошла реализация YAML из модуля (Хотя тут поговаривают, что JSON захватит мир...)

Достаточный минимум:

use YAML qw(DumpFile LoadFile);

DumpFile('object.yml', $obj);

my $obj = LoadFile('object.yml');

Противная ошибка в Crypt::DES

Проблема: При использовании модуля Net::SSH::Perl при попытке выполнения некоторых команд в $ssh->cmd() можно получить следующюю ошибку:

input must be 8 bytes long at /usr/local/lib/perl/5.10.1/Crypt/DES.pm line 57.

Причина: модуль Net::SSH::Perl реализован на чистом Perl и все методы шифрования пользует свои, в том числе и Crypt::DES. А последний плохо дружит в UTF-8, поэтому и отгребает ошибку.

Фикс: добавить 'utf8::downgrade($data);' в проблемный DES.pm прямо перед строкой, на которую ссылается ошибка. Например, в мое случае я заменил

my ($self,$data) = @_;
return Crypt::DES::crypt($data, $data, $self->{'ks'}, 1);

на

my ($self,$data) = @_;
utf8::downgrade($data);
return Crypt::DES::crypt($data, $data, $self->{'ks'}, 1);

Решение нашел на perlmonks.org.

P.S. Та же беда с Cryprt::Blowfish. Фиксится так же.

P.P.S. Можно еще попробовать чиперы другие использовать. Я не пробовал.

Удаление триггеров bucardo в Postgres

Для сервисных нужд я иногда использую bucardo. Утилита внятная. Четкая документация. Работает и не жужжит :)

У нее есть одна особенность - она не удаляет триггеры из базы, даже если мы убираем ее из обработки. Это было бы не страшно, если бы лишние триггеры не замедляли работу базы. Поэтому для удаления bucardo-триггеров была написана следующая функция:


Исполнение, как обычно:

select strip_bucardo_triggers();

"Raising Elephants" mnemonic device

The section was removed from Wiki with the following comment: Removed section. I strongly feel it doesn't belong. There's no magic formula and REISUB doesn't seem like a good idea either.

I do not think so. So here is the removed section:

---
A common idiom to perform a safe reboot of a Linux computer which has otherwise locked up, the QWERTY (or AZERTY) mnemonic "Raising Elephants Is So Utterly Boring", "Reboot Even If System Utterly Broken" or simply remembering the word "BUSIER" backwards, is often useful. It stands for:

unRaw       
 tErminate 
 kIll       
  Sync     
  Unmount  
reBoot.

This can prevent a fsck being required on reboot and gives some programs a chance to save emergency backups of unsaved work.
In practice, each command may require a few seconds to complete, especially if feedback is unavailable from the screen due to a freeze or display corruption. For example, sending SIGKILL to processes which have not yet finished terminating can cause data loss.
---

Преобразование varchar в integer в Postgres на лету.

Для подобного преобразования достаточно определить следующую функцию:


Источник решения: stackoverflow.com.