5-й КИТ

Закончился 5-й по счёту курс информационных технологий (КИТ)

Я там читал несколько лекций по основам БД, ничего сильно специфичного, несколько монологов о технологиях БД:

1. Базы данных: какие они бывают, что такое реляционная алгебра, SQL, нормальная форма и зачем нужна система управления БД

2. Базы данных: атомарность транзакций, способы ведения журналов транзакций и принципы построения транзакционных систем высокой доступности (на примере СУБД Oracle)

Кажется, что курс вышел достаточно интересным 🙂

Полный список лекций можно найти на странице проекта

5-й КИТ

Hadoop на распутье?

5 августа Майкл Стоунбреейкеер в своём блоге опубликовал интересную заметку Hadoop at a Crossroads?  

Ниже мой (местами вольный :)) перевод этой заметки. Кажется, что её нужно читать “на одном дыхании”, не отвлекаясь на необходимость переводить на родной язык.


 

С моего последнего в этом блоге постинга в 2012 году совместно с Джереми Кепнером (Jeremy Kepner) утекло уже много воды, и я считаю своим долгом указать на некоторые факты и мнения, а также сообщить о паре анонсов. В заключение я сделаю предположение о том, куда же “стек Hadoop” движется.

Первый анонс – выпуск Cloudera релиза новой DBMS Impala [2], работающей на HDFS. Упрощенно говоря, Impala спроектирована ровно также, как и все остальные параллельные shared-nothing SQL СУБД, работающие на рынке витрин данных. Особенно стоит отметить, что в релизе отказались от слоя MapReduce, и заслуженно. Как некоторые из нас доказывают уже на протяжении нескольких лет, MapReduce непрактичен для использования в качестве основного интерфейса внутри SQL (или Hive) СУБД [3,4]. Impala была спроектирована весьма здравомыслящими разработчиками СУБД, знакомыми с этими парадигмами. В действительности, схожая с Impala активность наблюдалась и среди разработчиков HortonWorks и FaceBook. Это, конечно же, поставило поставщиков Hadoop перед диллемой. Исторически Hadoop-ом называют open-source версию MapReduce, написанную Yahoo. Однако Impala выкинула этот слой из стека. Как же в этом случае можно быть поставщиком Hadoop, если сам Hadoop в его первоначальном смысле больше не является частью основного стека?

Ответ прост: переопределить термин “Hadoop”, и это ровно то, что было сделано поставщиками. Слово “Hadoop” теперь используется для обозначения всего стека. Иными словами, в основе HDFS, поверх которой запускается Impala, MapReduce и другие системы. Поверх этих систем работает высокоуровневое ПО типа Mahout. Слово “Hadoop” используется для обозначения всего набора.

Второй свежий анонс пришёл от Google, который объявил, что MapReduce – вчерашние новости и они идут дальше, строя свои программные решения поверх лучших систем, таких как Dremmel, Big Table, и F1/Spanner [5]. Вообще, Google должно быть тихонько посмеивается сейчас. Они изобрели MapReduce с целью поддержки процесса обхода web для своего поискового движка в 2004. Через несколько лет они заменили в своих приложения MapReduce на BigTable, потому что хотели интерактивную систему хранения, в то время как MapReduce обеспечивает только пакетную обработку. Так что основное приложение, использующее MapReduce, уже давно сменило платформу на лучшую. И теперь Google сообщает, что они не видят в будущем необходимости в MapReduce.

Весьма иронично, что Hadoop продолжает получать поддержку основной части сообщества уже около пяти лет после того, как Google перешёл на использование лучших технологий. Таким образом, весь остальной мир следует за Google в мир Hadoop с отставанием почти в десятилетие. А Google уже давно отказался от MapReduce. Интересно, сколько времени всему остальному миру понадобиться, чтобы двинуться в том же направлении, что и Google сейчас.

Обратите внимание, что поставщики Hadoop сейчас движутся встречным курсом с поставщиками витрин данных. Они сейчас реализуют (или уже реализовали) ту же самую архитектуру, что практикуется в мире витрин данных. Как только они получат несколько лет на кристаллизацию своих реализаций, они скорее всего смогут предложить конкурентную производительность. Между тем большинство поставщиков витрин данных поддерживают HDFS, а многие представляют функционал для работы с полу-структурированными данными. Так что рынки витрин данных и Hadoop вскорости сольются. Возможно, в результате шумного противостояния выиграет лучшая система.

А сейчас я хотел бы вернуться к HDFS, который остался единственным общим блоком в стеке Hadoop. Очевидно, что HDFS – файловая система, способная хранить байты данных, свойство, ожидаемое от любой вычислительной платформы. Есть два вИденья, куда HDFS могло бы двинуться в будущем. Если принять точку зрения будущего как файловой системы, то пользователям нужна обычная распределенная файловая система и HDFS – отличная разумная альтернатива.

С другой стороны, с точки зрения параллельной SQL/Hive СУБД HDFS “хуже смерти”. СУБД ВСЕГДА хочет отправлять запрос (несколько килобайт) к данным (много гигабайт) и никогда наоборот. Так что попытка спрятать месторасположение данных от СУБД – это смерть, и СУБД пойдёт на многое, только бы избавиться от этой особенности. Все параллельные СУБД, неважно, от поставщиков витрин данных или Hadoop, обязательно отключат прозрачность (в смысле transparency, когда приложениее не знает, где физически хранятся данныее) расположения данных, заставляя HDFS вести себя как набор файловых систем Linux, одна на узел. Точно также, как ни одна СУБД не нуждается в репликах файловой системы. См. в [6] обширную дискуссию на эту тему. Вкратце, соображения балансировки нагрузки, оптимизации запросов и транзакционности играют в пользу поддержки систем репликации на уровне СУБД.

Если окажется, что на рынке в течение длительного времени будет преобладать точка зрения СУБД, то HDFS атрофируется, поскольку поставщики СУБД откажутся от её специфичных свойств. В этом мире на каждом узле будет своя локальная файловая система, параллельная СУБД, поддерживающая высокоуровневый язык запросов, и различные утилиты на его основе или расширения, определенные с использованием пользовательских функций. В таком сценарии Hadoop трансформируется в обычную shared-nothing СУБД с набором поставщиков СУБД, конкурирующих за ваш бюджет.

С другой стороны, если победит точка зрения файловой системы, то HDFS, вероятно, останется большей частью неизменной, но с пёстрой смесью утилит, работающих поверх него. Свойства, считающиеся само собой разумеющимися в среде СУБД, такие как балансировка нагрузки, аудит, управлениее ресурсами, независимость данных, целостность данных, высокая доступность, контроль совместного доступа и качество сервиса медленно перейдут на уровень пользователей файловой системы. В этом сцеенарии больше не будет высокоуровневых стандартных интерфейсов. Другими словами, точка зрения СУБД способна предложить кучу полезных сервисов, и пользователи должны быть весьма разумны, чтобы тщательно обдумать, хотят ли они запускать низкоуровневые интерфейсы.

В обоих сценариях единственной общей частью ПО является файловая система, и поставщики Hadoop будут продавать основанные на файловой системе утилиты, либо только для СУБД или остальных продуктов (или, возможно, их обоих). Фактически они присоединятся к когорте поставщиков системного ПО, продающих ПО или сервисы. Возможно победит лучший продукт!

 

Ссылки:

[1] http://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltext

[2] http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html

[3] http://dl.acm.org/citation.cfm?id=1629197

[4] Pavlo, A. et. al., “A Comparison of Approaches to Large-Scale Data Analysis,” SIGMOD 2009.

[5] http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/

[6] Stonebraker, M., et. al., “Enterprise Data Applications and the Cloud: A Difficult Road Ahead,” Proc IEEE IC2E, Boston, Ma., March 2014

Hadoop на распутье?

Софтверный mdraid

Обычно, когда говорят о стратегии размещения блоков в массиве RAID, имеют в виду защиту от выхода из строя части дисков. На производительность же влияет уровень RAID либо размер stripe, либо параметры памяти контроллера. Это некий шаблон, сформированный миром больших дисковых систем. Тем удивительней было узнать, что в случае mdraid это не так и не меняя уровень RAID, изменяя лишь стратегию распределения блоков, можно существенно увеличить производительность.

 

Опыт работы с mdraid в кластере Vertica

Софтверный mdraid

Кластеризация Oracle Identity Management

О кластеризации IDM было уже сказано не раз, подборку материалов по этой теме можно найти в конце статьи. Я же хочу далее обратить внимание на практическую сторону вопроса. Да, во всех встречавшихся мне документах достаточно подробно и широко рассмотрены многочисленные вопросы обеспечения HA для продуктов Fusion Middleware, в общем, и Identity management, в частности. Однако же им не хватает деталей конкретной реализации: как заставить все перечисленные отдельные HA компоненты работать совместно?

Ниже описано, как все это работает в нашей картине мира на кластере из нескольких серверов в разных ДЦ.

Continue reading “Кластеризация Oracle Identity Management”

Кластеризация Oracle Identity Management

Решение логических задач с помощью рекурсивного SQL

В 7-м номере интернет-журнала ФОРС  увидела свет моя статья Решение логических задач с помощью рекурсивного SQL

 

Краткая аннотация:

В задачах, подобных “головоломке Эйнштейна”, основная сложность заключается в пестроте и сложности формализации условий, которые зачастую попросту сбивают с толку. Как правило, формализовать их удается с помощью логики высказываний. Однако реляционные базы данных и язык SQL, в частности, оперируют отношениями и предикатами, а не высказываниями и формулами. Выходом могло бы стать использование языка Datalog, однако он по-прежнему не находит широкого применения в промышленных системах. Вместе с тем, рекурсивные расширения языка SQL стандарта SQL:92 позволяют использовать при решении основные приемы языка Datalog. Тем самым становится возможным на основе имеющегося массива данных и известных закономерностей сделать логические выводы, получив новые данные, т.е. создать так называемую дедуктиную базу данных. В работе приведен пример решения одной частной задачи с использованием алгоритма вычисления наименьшей неподвижной точки.

 

PDF-версию этой статьи можно скачать по ссылке ниже

one_example

Решение логических задач с помощью рекурсивного SQL

SCAN listener IP в качестве fake имени в Fusion Middleware

В документации Oracle по настройке механизмов SCAN Listener и устранению неполадок при работе с ним несколько раз упоминается: не используйте разрешение имен в IP-адреса через файл /etc/hosts. В полной мере многогранность этой проблемы осознаешь, когда пытаешься использовать fake-имена в продуктах Fusion Middleware. Практическая значимость этого действия тривиальна: клонирование production-сред в тестовые/разработческие среды либо какие-то срочные работы по замене оборудования. Проблема здесь в том, что:

  • Имя сервера жестко прописано в конфигах. Это могут быть как xml и cfg файлы на диске, так и специальные таблицы конфигураций в БД;
  • Настройка среды с “нуля” – процесс длительный и трудоемкий. А сами среды могут состоять из нескольких машин и продуктов (это же Fusion Middleware);
  • Имена серверов сами по себе ценности не представляют, они нужны главным образом для разрешения их в IP-адреса и обратно.

В нашем случае целью было поместить БД конфигураций Hyperion Planning в существующем Oracle RAC кластере из соображений fault tolerance и лучшей утилизации ресурсов. Проблема здесь одна: имя сервера БД прописано явно во множестве конфигурационных файлов, таблиц с настройками и т.д. Последний раз, когда я менял номер порта listener в связи с переездом Oracle на другую машину, делать это пришлось в 17 источниках, а последствия этого разгребали в течение 2-х недель. Гораздо проще имя сервера Oracle оставить как есть, прописав в /etc/hosts для этого имени “правильный” IP-адрес. 🙂 Тем более, что такая замена может потребоваться еще не раз в будущем: при миграции в другой ДЦ, клонировании сред и т.д.

Что можно почитать про использование SCAN-адресов:

  • Документацию по динамической регистрации экземпляров http://docs.oracle.com/cd/E11882_01/network.112/e10836/listenercfg.htm#NETAG1154
  • Объяснение основных принципов работы 11gR2 Grid Infrastructure Single Client Access Name (SCAN) Explained [ID 887522.1]
  • Основные механизмы решения проблем How to Troubleshoot Connectivity Issue with 11gR2 SCAN Name [ID 975457.1]
  • Типичные причины ошибок ORA-12545 or ORA-12537 While Connecting to RAC through SCAN name [ID 970619.1]
  • Описание тонкостей поведения в открытых bug-ах Bug 9150053 : ORA-12545 REPORTED WHILE CONNECTING TO 11.2 SCAN ON CLIENT

Ниже приведен мой список мест, где все может сломаться и куда нужно посмотреть при использовании SCAN-Listener в качестве fake-имени:

  1. Все машины, с которых осуществляется доступ, должны правильно разрешать fake имя в IP-адрес SCAN listener
  2. Все машины, на которых может быть запущен SCAN listener, должны разрешать fake имя в IP-адрес SCAN listener. Я не знаю, зачем это нужно 🙂
  3. Экземпляры и сервисы должны быть зарегистрированы в SCAN listener и соответствующих local listener. Проверить можно командой lsnrctl. Не забываем только, что все listener запускаются из grid home.
  4. Имена, с которыми экземпляры зарегистрировались, должны корректно разрешаться на всех машинах кластера и всех машинах, с которых осуществляется доступ.

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

SCAN listener IP в качестве fake имени в Fusion Middleware

Семинар Jonathan Lewis 13 мая 2013 года

Огромное спасибо компании Innova и персонально Илье Дееву за уникальную возможность вживую пообщаться с Jonathan Lewis, задать каверзные и не очень вопросы!

13 мая, весь день, с утра до вечера, можно было слушать о новых и старых возможностях Oracle. Ну и, конечно же, сфотографироваться на память и взять автограф 🙂

В перерыве между секциями можно было задать Джонатану вопрос.
В перерыве между секциями можно было задать Джонатану вопрос.

Для себя я открыл нового Льюиса. По ощущениям это можно сравнить с чтением произведений Артура Конан Дойля о Шерлоке Холмсе, когда с помощью дедукции и внимания к мельчайшим деталям удается понять, что же происходило с системой и почему она себя так ведет. А в перерывах еще и пообщаться со старыми и новыми знакомыми. Нечасто удается увидеть так много хороших ораклистов в одном месте.

Ниже несколько фотографий с мероприятия.

Готовимся. Сейчас начнется первый доклад об архитектурных особенностях различных фич Oracle и о том, к чему может привести пренебрежение к существенным деталям при проектировании каркаса будущего решения
Готовимся. Сейчас начнется первый доклад об архитектурных особенностях различных фич Oracle и о том, к чему может привести пренебрежение к существенным деталям при проектировании каркаса будущего решения
И Жени Горбоконенко
Приветственное слово Жени Горбоконенко
Джонатан рассказыват о гистограммах
Джонатан рассказыват о гистограммах
Игорь Усольцев интересуется особенностями работы BACS
Игорь Усольцев интересуется особенностями работы BACS
В перерывах между выступлениями Джонатану не давали скучать
В перерывах между выступлениями Джонатану не давали скучать
Саян Малакшинов (справа) что-то уже проверяет на production системе
Саян Малакшинов (справа) что-то уже проверяет на production системе
"Русский" Pythian
“Русский” Pythian
Vint (слева) и Тимур Ахмадеев (справа)
Vint (слева) и Тимур Ахмадеев (справа)
Александр Анохин и Илья Деев
Александр Анохин и Илья Деев
После семинара можно было получить автограф Джонатана
После семинара можно было получить автограф Джонатана
Или дать автограф Джонатану самому :) На фотографии Илья в числе первых подписывает русский перевод книги CBO: Fundamentals, которую мы потом от всей нашей "тусовки" подарили Джонатану
Или дать автограф Джонатану самому 🙂 На фотографии Илья в числе первых подписывает русский перевод книги CBO: Fundamentals, которую мы потом от всей нашей “тусовки” подарили Джонатану
Общая фотография на память
Общая фотография на память
После семинара состоялась встреча без галстуков
После семинара состоялась встреча без галстуков
Окончание вечера
Окончание вечера
Семинар Jonathan Lewis 13 мая 2013 года

Одна задачка на SQL

В феврале 2013 года мне посчастливилось участвовать в жюри региональных финалов олимпиады Oracle ИТ-Планета

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

Итак, одно из заданий было сформулировано так:

Одной командой SELECT вывести список сотрудников, которым установлен оклад больший, чем средний оклад по подразделению компании, к которому они приписаны.

Сведения о сотрудниках, для которых неизвестно к какому подразделению они приписаны, выводить не нужно.

В результат вывести 5 (пять) столбцов:
1. Идентификатор сотрудника
2. Фамилию сотрудника
3. Имя сотрудника
4. Оклад, установленный сотруднику
5. Идентификатор подразделения, к которому приписан сотрудник

Результат отсортировать:
1. По окладу, установленный сотруднику (по убыванию)
2. По фамилии сотрудника (по возрастанию)
3. По имени сотрудника (по возрастанию)
4. По идентификатору сотрудника (по возрастанию)

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


SELECT employee_id, last_name, first_name, salary, department_id
FROM employees E
WHERE salary > (SELECT AVG(salary) FROM employees X
WHERE E.department_id = x.department_id)
ORDER BY salary DESC, last_name, first_name, employee_id;

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

Continue reading “Одна задачка на SQL”

Одна задачка на SQL

Disaster Recovery DB Essbase

Как восстановить БД Essbase, если исходная среда недоступна либо были утеряны/поломаны файлы с исходной БД? Пример одного восстановления.

Предисловие

Без бекапа восстановить БД невозможно 🙂 Как у нас выполняется бекап и где находятся файлы для восстановления?
Каждую ночь в Essbase делается физический online (без остановки сервиса) бекап данных. Далее эти файлы передаются в резервные ДЦ
БД у нас находится в transaction mode, точнее, включен режим SERVER_CLIENT
Это означает, что все изменения пишутся в transaction лог в каталоге backup, а файлы загрузки данных из реляционных источников – в /opt/hyperion/user_projects/epmsystemesb1/EssbaseServer/essbaseserver1/app/*/*/Replay/
Раз в 15 минут эти файлы передаются в резервные ДЦ утилитой rsync.
Оба эти источника нужны для автоматического наката изменений.

Пример восстановления БД в резервном ДЦ, не оставливая primary БД

Continue reading “Disaster Recovery DB Essbase”

Disaster Recovery DB Essbase

One simple example about Oracle SPM

The profiles are a new (relatively) word in a database systems. Profiles of load on the file system, of a historical sessions behaviour, of SQL … Finally, the baseline or Oracle SQL Plan Management is a new (again relatively 🙂 ) instrument for working with explain plan of queries during the lifetime of the application that can manage the choose among  explain plans and keep track of their evolutions.

There are a lot of technical surveys about it:

  1. Documentation http://docs.oracle.com/cd/E11882_01/server.112/e23633/preup.htm#UPGRD00232
  2. Maria Kolgan https://blogs.oracle.com/optimizer/entry/sql_plan_management_part_1_of_4_creating_sql_plan_baselines
  3. Johathan Lewis http://jonathanlewis.wordpress.com/2011/01/12/fake-baselines/
  4. NoCOUG 2012, №8 SQL Plan Management for Performance Testing
  5. http://www.oracle-base.com/articles/11g/sql-plan-management-11gr1.php
  6. http://coskan.wordpress.com/2012/04/11/when-dbms_xplan-display_sql_plan_baseline-fails-to-show-the-plan

Let’s consider the principles of SPM on one simple example.

Continue reading “One simple example about Oracle SPM”

One simple example about Oracle SPM