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 наше отношение к этому было очень скептичным, сейчас стоит добавить одну маленькую деталь: нам нужно больше работать со своими решениями – потому что мы это можем!

Продолжение 

Большие данные или хранилище данных: что выбрать?

Предположим, что у нас есть 100 файлов, каждый из которых содержит 10 миллионов строк, и нам нужно загрузить их в репозиторий для того, чтобы мы могли проанализировать данные. Как лучше всего поступить? Воспользоваться Hadoop (HDFS) или реляционной СУБД (RDBMS)?

На прошлой неделе я обозначил разницу между большими данными и хранилищем данных: большие данные – это Hadoop, а хранилище данных – это РСУБД. Подробности можно прочитать в моей статье. Сегодня я хотел бы проиллюстрировать на примерах, в каких случаях предпочтителен Hadoop, а в каких – хранилище данных.

Рассмотрим 4 фактора:

1. Структура данных.
2. Объем данных.
3. Неструктурированные данные.
4. Schema-on-Read (схема при чтении).

1. Структура данных: простая или сложная

Если все 100 файлов имеют одинаковую структуру, например, все они состоят из одних и тех же 10 столбцов, то лучше поместить их в Hadoop. Затем мы сможем использовать Hive, Spark, Presto, R или Python * для анализа данных – например, для поиска закономерностей в данных, выполнения статистического анализа или создания прогнозов. Время разработки будет короче, потому что это только 1 слой.
* или Phoenix, Impala, BigSQL, Stinger, Drill

Если 100 файлов содержат 100 разных таблиц, лучше поместить их в базу данных, создать хранилище данных и использовать аналитический BI-инструмент, такой как Pentaho или MicroStrategy * для анализа данных. Например, чтобы получить срезы данных, найти процент или аномалии и провести анализ временных рядов. Да, нам будет необходимо создать 3 слоя (staging, 3NF, star schema), но это позволит анализировать каждый показатель по различным параметрам.
* или Looker, PowerBI, Tableau, QlikView, BusinessObjects, Cognos BI, Birt, Pentaho, Roambi, SAS, Sisense или другие инструменты BI

Поэтому, если структура данных простая, поместите их в Hadoop, а если сложная – в хранилище данных. Это общее правило, но иногда из него бывают исключения. Можно ли поместить данные с простой структурой в хранилище данных? Конечно можно. Могут ли данные со сложной структурой быть помещены в Hadoop? Несомненно.

Используя Hadoop и Hive/Spark/Presto, мы также можем получить срезы данных, вычислить процент или аномалии, провести анализ временных рядов. Используя хранилище данных, мы можем выполнять машинное обучение и интеллектуальный анализ данных для поиска в них закономерностей, статистический анализ и создавать прогнозы. Таким образом, независимо от того, где мы храним данные – в Hadoop или в хранилище данных, мы все равно можем провести полный анализ.

Проблема заключается в хранении. Связывание 100 таблиц в Hadoop – сложно и неестественно. РСУБД, такие как SQL Server или Oracle, предназначены именно для этой задачи: связывания и объединения таблиц. Построение модели данных, связывающей 100 таблиц, очень подходит для РСУБД. Можем ли мы спроектировать модель данных, связывающую 100 файлов с различными структурами в Hadoop? Конечно, мы можем это сделать. Но это гораздо сложнее. Во-первых, это Schema-on-Read, поэтому столбцы в файлах не имеют типов данных. Schema-on-Read означает, что мы не пытаемся определить взаимосвязь между файлами при их загрузке в Hadoop. Так что да, мы можем загрузить 100 файлов в Hadoop, но мы сохраняем их как отдельные файлы, без связей между ними. То же самое происходит и в Data Lake, где также используется Schema-on-Read и HDFS.

2. Объем данных: маленький или большой

100 файлов, содержащих 10 миллионов строк каждый, составляют 1 миллиард строк в день. Если все 100 файлов имеют одинаковую структуру (скажем, все они состоят из одних тех же 10 столбцов), то у нас будет ... Читать далее

15 примеров визуализации данных

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

Сейчас широко применяются 2 различных метода визуализации данных: исследование, которое позволяет понять смысл и цель ваших данных, и объяснение, которое пересказывает историю данных пользователям. Для того, чтобы удовлетворить большинство ожиданий вашей аудитории, вы должны рассмотреть оба метода. К счастью, существует множество практических и интересных способов наглядного представления данных.

Читать далее... 

5 шагов погружения в DWBI

перевод статьи Vincent Rainardi

 Этап 1. Составление отчетов (Стоимость: £25 тыс./год. Длительность: 2-3 года)

В большинстве компаний BI-подразделение начиналось с одного сотрудника IT-отдела, занимающегося составлением отчетов. IT-отделу ставилась задача – подготовить сводный бизнес-отчет для какого-либо собрания на основе информации из базы данных. Отчет формировался с помощью встроенных средств отчетности – SSRS, Jasper или Crystal. Тогда никто ничего не слышал о Business Intelligence. Руководству требовался просто «Отчет», не BI и даже не Management Information.

Компания, состоящая из 100 сотрудников и имеющая годовой оборот в размере 5 млн. фунтов стерлингов, обходилась IT-отделом, в котором было всего 5 человек. Они в основном занимались технической поддержкой – Exchange и Email, администрированием файлового и SQL-серверов, локальной сети. Подготовка отчета для них была всего лишь одной из множества задач.

Однако руководству требовались все новые и новые отчеты. Нагрузка на сотрудника, занимавшегося их составлением, быстро росла. Пропорционально увеличивалась его производительность за счет освоения встроенных инструментов для визуализации данных. Так, например, если для подготовки первого отчета потребовалось 3 недели, то пятый был сформирован за 3 дня. При этом не существовало инструкций и строгих правил оформления отчетов. На бизнес-собраниях просто требовалась информация в удобном для восприятия виде.

Сколько это стоит? Расходы на этом этапе составляют около 20-25 тыс. фунтов стерлингов в год.

Читать далее...