PostgreSQL: Linux VS Windows – часть 2!

После проведения моего первого теста я получил интересный отзыв под постом на reddit, который подтолкнул меня сделать еще один эксперимент. 

И я подчеркну это еще раз – это не тест для сравнения Linux и Windows!

Меня не волнует, какая операционная система лучше!

У меня есть клиент с большой инфраструктурой, построенной с использованием Windows (но не Linux) и большим опытом работы с Windows (но не Linux), и я хочу знать, должен ли я посоветовать ему использовать PostgreSQL для Linux.

Поскольку для перехода на Linux ему будет необходимо нанять специалиста, разбирающегося в Linux, набраться собственного опыта, а также пересмотреть свой бюджет.

Последовав совету, я не стал использовать свой прежний инструмент тестирования. Для второго теста «Windows vs Linux для хостинга PostgreSQL» я использовал PgBench.

Следуя этому совету, я проводил тест с данными, превышающими размер памяти и с большой продолжительностью. М4.xlarge на Amazon имеют 16 Гб данных, а при масштабе 2000, PgBench генерирует БД ±30 Гб.

PgBench, для тех, кто не в курсе (как я), делает тоже самое, что и написанное мной приложение для тестирования, но лучше!

Он имеет большое количество опций и тщательно тестируется, в отличие от моего приложения, которое только было протестировано... только мной.

PGBench – это не совсем то, что я хотел, потому что я хотел провести тест с помощью .NET-приложения, которое использует npgsql (PgBench использует libpq), но, как говорится, «в Риме поступайте, как римляне».

Архитектура для тестов совпадает с предыдущей:

«Клиент»

Сервер Windows 2012 R2 на amazon, тип m4.xlarge, со всеми настройками по умолчанию.

Клиентским «приложением» выступает PgBench.

«Сервер Windows Postgresql» (далее – WS)

Сервер Windows 2012 R2 на Amazon, тип m4.xlarge, со всеми настройками по умолчанию и 100 GB SSD.

PostgreSQL 9.4.5 установлен с помощью мастера.

Я изменил listen_addresses на * и внес необходимые изменения в pg_hba.conf для подключения к работе.

«Сервер PostgreSQL для Linux» (далее – LS)

Amazon Linux AMI, тип m4.xlarge, со всеми настройками по умолчанию и 100 GB SSD.

PostgreSQL 9.4.5 установлен с yum.

Я внес те же самые изменения в postgresql.conf и pg_hba.conf, которые я делал для Windows.

Сценарий

PostgreSQL: Linux VS Windows!

В сентябре, по приглашению Dalibo, я был в Париже на Postgresql Sessions. Еще раз спасибо за приглашение! Это было событие, которое изменило мою жизнь! 

Во время разговора с некоторыми сотрудниками Dalibo, один из них сделал замечание, которое я воспринял как внутренний вызов. Он сказал, что PostgreSQL на ОС Linux, запущенной в виртуальной машине на Windows, работает быстрее, чем PostgreSQL на той же Windows.

Поскольку я новичок в мире PostgreSQL/Linux, я был озадачен этой информацией, но когда я спросил точные цифры, у него их не было. Тогда я понял, что это была просто шутка (я быстро понимаю шутки, особенно со второго или третьего повтора), и что он просто имел в виду, что PostgreSQL на Linux работает быстрее, чем на Windows.

Архитектура Linux в сравнении с архитектурой Windows

Чтобы понять его заявление о скорости работы, нужно знать основное, в данном случае, различие в архитектуре между Windows и Linux. 

Linux может использовать fork, а Windows – нет!

Но, что, черт возьми, это такое – fork? Если кратко, то fork – это системный вызов, который позволяет процессу создавать дочерние процессы, при этом продолжая работу параллельно с ними. Они могут делиться своей памятью и взаимодействовать друг с другом.Это стандартный метод разработки в среде Unix/Linux, но он не может быть применен в Windows... поскольку fork не существует в Windows.

Fork не поддерживается архитектурой Windows и, чтобы реализовать его функционал, нужно использовать потоки или...

Продолжение

Перестаньте думать о хранилищах!

Описываемое здесь – результат размышлений, которые начали беспокоить меня несколько лет назад. В то время я реализовывал проект за проектом, применял ETL-системы, оптимизировал расчеты, занимался разработкой панелей показателей, однако меня не покидало ощущение, что часть моих усилий тратится впустую, но почему – я не понимал. Когда я пытался с кем-то об этом поговорить, то наталкивался на стену непонимания.

Постепенно ко мне начали приходить озарения (я не утверждаю, что они всегда имели смысл, поскольку полностью осознаю, что в тот момент просто помешался на этом!) – что я неправильно подхожу к задачам. И этот небольшой поворот в моем мышлении в дальнейшем приобрел огромное значение: он не только изменил нашу методологию реализации проектов по предоставлению услуг, но и значительно повлиял на разработку и видение продукта Pentaho.

Несколько лет назад в блоге…

Пару лет назад я опубликовал в блоге новость «Kimball устаревает». Она несла в себе одно фундаментальное утверждение: технология развилась до такой степени, что простой взгляд на концепцию корпоративного хранилища данных (EDW) показывает ограниченность такого решения. Пользователей не волнует, с использованием каких технологий хранится информация, им важно, чтобы данные были где-то сохранены, а по-возможности – еще и сделана их резервная копия. Я предложил обратить внимание на эту проблему: возможно, DW Kimball с его организацией в виде схемы звезды, снежинки и прочим – не лучший вариант, и нам следует реализовать что-нибудь другое...

Но я был не совсем прав...

Я все еще (больше, чем когда-либо?) являюсь большим сторонником ...

Продолжение 

Привет, Hitachi Vantara!

Два года назад компания Pentaho была приобретена корпорацией Hitachi Data Systems и вошла в состав Hitachi Group. Сегодня появилась новая информация о дальнейшем развитии Pentaho

19 сентября 2017 года, произошло важное событие. Родилась новая компания. Знакомьтесь: Hitachi Vantara. Hitachi Vantara объединяет Hitachi Data Systems, Hitachi Insight Group и Pentaho в единый проект.

Что это означает?

Мы всегда стремились к тому, чтобы позволить нашим клиентам строить высокопроизводительные решения, основанные на анализе данных. Я считаю, что у нас это отлично получалось! И теперь мы хотим достичь нового уровня – стать лучшими не только в Big Data и аналитике, но и ведущим игроком в решениях в области Интернета вещей (IoT). А объединение в Hitachi Vantara позволит нам это сделать!

Что изменится?

Очевидно, что Pentaho, как продукт, продолжит существовать. А Pentaho, как компания, будет действовать в составе Hitachi Vantara. Это дает нам огромные возможности для развития продукта: мы сможем сосредоточиться на основной задаче наших решений (обработке и аналитике Big Data), но при этом пользоваться разработками на стыке операционных (ОТ) и информационных технологий (ИТ) других компаний, входящих в Hitachi Vantara.

Также мы займемся улучшением совместимости продуктов. Хотя до объединения в Hitachi Vantara наше отношение к этому было очень скептичным, сейчас стоит добавить одну маленькую деталь: нам нужно больше работать со своими решениями – потому что мы это можем!

Продолжение