Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Действительно ли о модели разработки MapReduce можно говорить лишь в контексте нереляционных хранилищ данных?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всем привет!

Я хотела бы узнать мнение сообщества DOU, действительно ли правильно относить применение термина MapReduce только к нереляционному миру. Такой вопрос мне пришел в голову после прослушивания одной презентации на тему нереляционных хранилищ данных.

Какой-то время назад я читала о том, что в некоторых реляционных базах данных есть так называемые пользовательские агрегационные функции (user-defined aggregate functions), как, например, в Oracle. Вот, вообщем-то, мне и стало интересно окунутся в эту тему на столько, на сколько позволяли мои познания и свободное время. Поэтому прошу, если кто-либо со мной в чем-либо не согласен, не стеснятся оставлять свои конструктивные комментарии под текстом статьи, так как мне было бы интересно добраться до истины вместе с вами.

Перед тем, как начать, я оговорюсь, что не собираюсь сравнивать нереляционные и реляционные хранилища данных, так как мне кажется каждое из этих решений направленно на решение своих задач, и поэтому поводу уже написан интересный труд Gaurav Vaish — Getting Started with NoSQL, в котором автор попытался раскрыть области (на сколько хорошо, хотела бы тоже услышать по этому поводу конструктивные комментарии), в которых оправдано/неоправданно применение обоих решений. Книга по размеру небольшая и написана легко. На протяжении всей книги автор, как мне показалось, уделял максимум внимания конкретики, поэтому воды скорей всего в ней не заметите.

Ну начну с того, что когда я разобралась с этой темой, то пришла к выводу, что пользовательские агрегационные функции (user-defined aggregate functions) ничто иное, как реализация MapReduce модели. Почему? Давайте попробуем в этом вместе разобраться.

Рассмотрим кластерную архитектуру как для нереляционного решения на базе MongoDB, так и для реляционного на базе БД Oracle 9i+. Рассматривать я буду по документациям и статьям которые прочла (буду в своей статье делать ссылки, где только это будет возможно и уместно), так как сама не пробовала разворачивать боевое окружение ни для первого ни для второго случая. Поэтому решила написать статью, чтоб встретить в комментариях людей с реальным опытом и конструктивной критикой.

Как наверное многим ’в теме’ известно, что модель разработки MapReduce направленна, в первую очередь, на решение задач, связанных с вычислениями над огромными массивами данных (об этом для ознакомления можно прочитать на MapReduce). Основывается это решение на модели распределённых вычислений, где MapReduce задача отправляется на узел, где находятся данные, выполняет операцию на узле над данными, и промежуточный результат возвращает прокси узлу (тот узел, через который приложение взаимодействует с кластером), который уже отвечает за то, чтоб из промежуточных результатов, собранный от узлов с данными, собрать финальный результат и отправить приложению (можно сказать агрегация данных в распределенном окружении).

Реализуется это решение за счет того, что изначально существует архитектура, например, на базе кластера, которая позволяет разделять данные между узлами в более-менее равных пропорциях (в MongoDB это сделано с помощью механизма shard key: sharding-shard-key, в БД Oracle 9i+ с помощью cluster key: docs.oracle.com/...​0/tablecls.htm#CNCPT88828, и, на сколько я понимаю, по этим ключам вычисляется хеш-код, с помощью которого можно однозначно определить место положения данных. О возможном варианте реализации процесса поиска места положения данных по хешу хорошо написано в этой статье: distributed-hash-tables-and-consistent-hashing), чтоб в дальнейшем иметь возможность запускать распределенные вычисления на разных физических/логических узлах (под логическим узлом я имею ввиду — одна физическая машина, но с несколькими запущенными узлами на ней). О достоинствах и недостатках хранения данных на физических и/или логических узлах говорить не буду, так как это не совпадает с целью статьи, собственно, как и о возможных решениях отказоустойчивости и масштабируемости.

Итак, вернёмся к нашим баранам. Решение на базе БД Oracle 9i+ исходя из документации я попыталась выразить следующей задачей для более легкого восприятия процесса: есть входящий набор данных в виде облака с различными объектами инфраструктуры внутри, и поставим задачу — подсчитать количество объектов, относящиеся к каждой инфраструктуре. Графически реализация этой задачи будет выглядеть следующим образом:

Решение этой же задачи для нереляционной БД (в нашем примере — MongoDB, хотя, собственно, не имеет значения...) графически выглядит следующим образом:

Добавлю, что задачу я намеренно выбрала наиболее простую и решение также, чтоб обратить внимание читателей на схожесть и разницу в реализациях. В настоящем же приложении для MapReduce скорей всего будет использоваться связка: Input Values -> Splitting -> Mapping -> Shuffling -> Reducing -> Final Result, как хорошо показано здесь: xiaochongzhang.me/blog/?p=338.

Вывод: из двух графических представлений видно, что и user-defined aggregate functions и MapReduce на диаграммах ведут себя схоже в распределенной среде (Oracle БД также построена на кластере), но процессы называются разными именами.

Интересный факт: после серфинга различных ресурсов я нашла, что упоминание и описание процедуры распределенного вычисления для Oracle БД вышла раньше, чем для MapReduce.
Описание API пользовательских агрегационные функций (user-defined aggregate functions) для БД Oracle 9i+ вышла в Сентябре, 2003, и была описана Adrian Billington (ссылка здесь: www.oracle-developer.net/display.php?id=215), в то время, как Google в лице Mark C. Chu-Carroll описал это решение в 2004 году (ссылка здесь: searchcloudcomputing.techtarget.com/definition/MapReduce)

Спасибо за внимание, и жду от вас конструктивных комментариев и, главное, дополнений.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Да, я тоже так считаю. От себя добавлю ссылку на еще одно описание того (на языке аналогий), как можно объяснить своей жене, что такое MapReduce (если кому-то понадобится вдруг :-) ): How I explained MapReduce to my Wife?

В случае RDBMS вы этого MapReduce не увидите, даже если он там применяется. Если есть функция агрегации, дело оптимизатора БД, будет он собирать промежуточные значения на месте на каждом узле (в случае шардинга) или сначала вытянет все данные в центр как диски. Хороший оптимизатор, да, сделает максимум работы локально; но везде ли он такой и всегда ли он догадается о всех обстоятельствах? Делая MapReduce явно, вы всего лишь спускаетесь на уровень ниже (как ассемблер относительно ЯВУ, так и язык работы с отдельными записями — по сравнению с реляционной алгеброй), соответственно берёте на себя все заботы по адекватности запроса и его оптимизации. Для задач, где это можно себе позволить и где это даёт преимущество — почему бы и нет?

А вот что мне не нравится в большинстве виденных реализаций MapReduce — отсутствие критериев предварительной фильтрации данных перед этим самым Map, которые бы эффективно исполнялись без полного перебора. Авторы многих этих баз действуют по принципу «чего думать, трясти надо» — улучшают скорость работы переборного этапа вместо того, чтобы изначально сократить поле обработки до необходимого минимума и позволить аккуратно задать этот минимум.

Эта проблема напрямую стыкается с другой — отсутствие упорядочения ключей и поиска по этому упорядочению в 99% нереляционных движков. Задача типа, в терминах SQL, ’SELECT foo FROM bar ORDER BY foo LIMIT 10′ для них невыполнима без полного перебора всех ключей под тот же MapReduce. Это при том, что ничто не мешает сделать такой запрос на каждом шарде и объединить результаты — меня бы вполне устроил подход типа «сложить 10 выбранных с каждого шарда, неважно сколько получится в итоге».

Спасибо, Валентин, за хороший комментарий!

Эта проблема напрямую стыкается с другой — отсутствие упорядочения ключей и поиска по этому упорядочению в 99% нереляционных движков. Задача типа, в терминах SQL, ’SELECT foo FROM bar ORDER BY foo LIMIT 10′ для них невыполнима без полного перебора всех ключей под тот же MapReduce.
Чего это? Может я неправильно понял условие, но именно в такой постановке при наличии индекса по foo задача сводится к последовательному чтению по индексу до «стопкея». При необходимости можно добавлять секционирование, группировать, используя аналитику и т.д. Что тут вообще «невыполнимого»?

Я так поняла, что в некоторых NoSQL хранилищах на данные, хранящихся на узлах после шардинга не возможно иметь индексы (как, например, в MongoDB индексы можно создавать в виде сбалансированного дерева), что поиск сводит к полному перебору всех данных из узла в худшем случае. Но я могу ошибаться, поэтому подождем ответ.

Может я неправильно понял условие,

Именно. Речь не про сферический NoRel движок в вакууме, а про конкретные реализации, которые (в моём случае) должны иметь равноправную сеть узлов (без выделенной головы), дублировать одну запись на нескольких узлах и позволять чтение/запись по кворуму, а не по наличию всех. А это условие сразу отбрасывает все развесистые «документные» БД и тому подобных зверей.

до «стопкея»

Ой, только не это. Мы не знаем плотность ключей на отрезке, и в интервале до граничного значения может встретиться 1 запись, а может 100500. А потом мы заложились на то, что их встретится не более 10, а их пришёл миллион. Stop key как ещё одно вспомогательное средство, конечно, иногда полезен, но только после уже состоявшейся реализации по пределу количества.

Ребята, круто общайтесь, разрешите хоть иногда встревать с вопросами, а то думаю, что ваши диалоги скоро превратятся во что-то такое, что будет понятно лишь вам одним...

У меня вопрос по ‘стопкей’ — здесь имеется ввиду установка границ на запрос (например, в Oracle это ROWNUM), по которому вычитывается ровно столько записей из всего множества, сколько было установлено в границе, после чего можно выполнять операции над этим подмножеством (фильтровать, сортировать ....). Верно?

У меня вопрос по ‘стопкей’ — здесь имеется ввиду установка границ на запрос (например, в Oracle это ROWNUM),

«Ах если бы». Аналог rownum — это как раз то, что я хотел. А реально встречается условие типа «key < $stopkey». Так и в Cassandra (без обсуждаемых рядом секретных методов через Thrift), и в Riak (bucket.get_index()). Это две доступные под описанные мной требования.

Ребята, круто общайтесь, разрешите хоть иногда встревать с вопросами, а то думаю, что ваши диалоги скоро превратятся во что-то такое, что будет понятно лишь вам одним...

Нет проблем:)

Спасибо, Валентин!

Вообще-то Вы в данном случае правильно понимаете. Honestly speaking, I’m not following Valentin in his below answer so maybe our misunderstanding is based on our different viewpoint.
В общем, я не очень понимаю, о чем ниже говорит Валентин, от себя добавлю что в зависимости от метода доступа к таблице и сложности запроса count stopkey может срабатывать, а может и нет.
Rownum по своей природе может быть использован только в запросах вида rownum <=XX, где XX — натуральное число, бОльшее нуля.

Ага, Спасибо, Alex, Валентин об этом же и сказал, по крайней мере я вас обоих одинаково поняла.

Я хотела бы добавить объяснение, почему именно rownum <=XX, может кому будет интересно. Oracle начинает считать записи с 1 и инкрементирует значение, только когда запись выбрана, тоесть когда все условия WHERE в SQL выражении были выполнены. Об этом хорошо написано здесь вместе с примерами: Using ROWNUM in Oracle, и также показано на примере, когда при наличии записей в таблице запрос с ROWNUM может вернуть 0 — ничего (WHERE rownum > 2).

Об этом хорошо написано здесь вместе с примерами

Ссылка битая. Но из неё можно восстановить нормальную. Почитал, интересно. Использование rownum не только для select, но и для update — это интересно, хотя я не представляю себе юзкейс. Напоминает анекдот про HR, который выбросил наугад половину резюме со словами «Нам не нужны неудачники».

А касательно условия rownum>:n — из-за таких причин свободные движки (mysql, postgres, sqlite) ввели синтаксис типа «limit :lim offset :ofs», который обожают авторы форумных движков (для задачи типа показать все сообщения на 90-й странице). Я считаю, что они решают это неправильно — потому что меня достаёт, когда при таком чтении половина страницы состоит из уже читанных тем — из-за того, что напостили новых. Лучше если бы выбирали следующую страницу по ограничению last updated timestamp.

Спасибо, Валентин, за поправку и дополнение! Восстановленный URL из кеша гугла (вчера еще работал :D): Using ROWNUM in Oracle (* from google cache)

в зависимости от метода доступа к таблице и сложности запроса count stopkey может срабатывать, а может и нет.

Я не воспринял stopkey как понятие, которое может означать и rownum, так рассматривать оказывается неэффективно. Количество — отдельно, диапазон ключей (если задаётся) — отдельно. Да, сплошь и рядом бывает задание типа «только за прошлый год». Но в случае Cassandra это будет уже при ограничении по равенству partitioning key, а в случае Riak нет гарантии, что движок не сделает полный перебор ключей. (Более того, перебор во всех корзинах! это уже свойства концепции Riak и его backend’ов. Из-за этого варианты типа «создать маленькую корзину и просто искать по ней» могут не работать. Но это я ушёл в сторону.)
Если считать, что stopkey — это и rownum, то... если каждая отдельная нода выполнит свою часть работы и пришлёт заказчику, получится что-то вроде того же MapReduce, только эффективного.

Ой, только не это. Мы не знаем плотность ключей на отрезке, и в интервале до граничного значения может встретиться 1 запись, а может 100500. А потом мы заложились на то, что их встретится не более 10, а их пришёл миллион. Stop key как ещё одно вспомогательное средство, конечно, иногда полезен, но только после уже состоявшейся реализации по пределу количества.

По поводу этого комментария я поняла следующее, что не смотря на то, что данные могут распределяться относительно равномерно по кластеру (на основе хеша shared key, например, в MongoDB), и иметь индекс на узлах по данным (B-Tree или любая другая реализация...), при увеличении объема данных на кластере, может скопится такое количество данных, что вызов какого-то запроса может не привести к улучшению производительности в сравнении с правильно настроенным RDBMS решением, а изменение shared key могут повлиять на смену архитектуры ничуть не меньше, чем если бы такое произошло с тем же RDBMS решением. Поэтому, я так понимаю, Валентин и хотел бы иметь еще какой-нибудь инструмент в NoSQL, который мог бы влиять на распределения данных по узлам кластера, например микс между распределением данных на основе хеша + на основе их естественного порядка, а не только одно из двух (может еще что-то...). Если я что-то не правильно поняла, поправьте меня пожалуйста, Валентин.

Кстати хотелось бы, чтоб к нам Alexey Vasiliev присоединился, так как я читала его блог, и у него есть интересная статья по сравнению различных NoSQL решений по ссылке: World of the NoSQL databases. Думаю, что ему нашлось бы, что еще добавить.

По примеру того, что существует в Cassandr’е, например — RandomPartitioner и OrderPreservingPartitioner, но только с возможностью их смешивать самому

Об этом я поняла по его рассуждениям (по рассуждениям Валентина) в этом посте: dou.ua/...ic/9914/#478447 + то, что он написал Вам, Alex, выше: dou.ua/...ic/9914/#478566

Я имел в виду вот что. Представим себе, например, форум местной политики. У него будет несколько периодов с чудовищно высоким количеством сообщений (типа как сейчас при войне с Россией) и периодов тишины между ними, как прошлое лето. Представим себе задачу просмотра по дате сообщения, для неё организовывается индекс — и, как рассказывает коллега reality_hacker, возьмём ByteOrderingPartitioner. Времена приведены к iso8601 или аналогу, пригодному для прямой сортировки.

Для такого partitioner’а нужно задать распределение ключей по узлам. Пусть мы вначале решили, что нам нужен один узел на квартал — например, один узел это для дат от 2013-07-01 до 2013-09-30 включительно. В текущей обстановке окажется, что на узле за I квартал 2014 — 100500 сообщений, а за II квартал 2013 — только 300. Да, попасть в нужный узел проблем нет. Только вот на одном кончились все диски и постоянно не хватает I/O, а другой простаивает.

В RDBMS такой проблемы изначально нет, пока не началось ручное вмешательство (типа партиционирования отдельных таблиц). Там может переполниться целиком узел движка, но это формально уже не та проблема:) И проблему диапазонов индекса (как с теми же датами) там решают регулярным анализом индекса с построением квантилей. Это очень хорошо иллюстрировать на примере даты. База форума, база людей в районе и база ветеранов военных действий будут иметь совершенно разные распределения, и оптимизатор сможет на этом основании понять, что ему делать (например, если задан поиск по ветеранам рождения от 2000 года, то он просто взглянув на максимум индексного выражения скажет, что таких записей 0 и запрос отдаст пустой ответ; от 1990 — пара человек и лучше начать с выборки по этому ключу; если же это база детской больницы, то таких записей будет большинство и выводы совсем другие). Теперь, что мне предлагают для Cassandra — это воспользоваться средством, которое требует ручного задания диапазонов ключа для узла и ещё и недокументировано в плане «а как мне аккуратно сдвинуть границу диапазона, что в этом случае будет? кто перенесёт записи между узлами и как запросить этот перенос?» Я в общем случае даже «за» (пойду изучать в экспериментах), если будет положительный ответ на этот вопрос с управлением без гемора.

А если будет тот вариант, что я описывал в пожеланиях, распределение по узлам может быть хэшировано как угодно — главное, чтобы на каждом из них задача «дать мне уроженцев 2000 года» или, усиливая, «дать с каждого узла 5 уроженцев 2000 года при выборке по возрастанию даты» решалась эффективно (без перебора всего массива данных, как обещают в Riak). Дальше пусть скинет результаты выборки с каждого из них, не агрегируя и не сортируя — я уже разберусь. И тут уже не будет проблем с перекосом загрузки между узлами, необходимости регулярной тонкой балансировки и тому подобных заездов.

при увеличении объема данных на кластере, может скопится такое количество данных, что вызов какого-то запроса может не привести к улучшению производительности в сравнении с правильно настроенным RDBMS решением

Я лично с RDBMS не сравниваю вообще, потому что они не могут работать под требования кворума при записи и чтении — это требование явно противоречит ACID. Единственное найденное исключение — MS SQL на Azure в фиксированном варианте «3 узла, кворум — это 2 из них», но ACID там уже ушёл лесом, а Azure меня не устраивает как хостинг. Сравнение идёт только в пределах распределённых одноранговых key-value хранилищ (или приводимых логически к таковым), с максимумом транзакционности это отказ, если данную запись успел поменять кто-то ещё (Cassandra — да, Riak — возможность считается устаревшей и отменяется).

Но если сравнивать — то вопрос не в производительности одного запроса, а системы в целом (как переполнение I/O на популярных узлах).

Поэтому, я так понимаю, Валентин и хотел бы иметь еще какой-нибудь инструмент в NoSQL, который мог бы влиять на распределения данных по узлам кластера, например микс между распределением данных на основе хеша + на основе их естественного порядка, а не только одно из двух (может еще что-то...). Если я что-то не правильно поняла, поправьте меня пожалуйста, Валентин.

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

Спасибо, познавательно.

Обсудив ситуацию на работе ещё раз, решили Riak выбрасывать в плановом порядке, переходить на Postgres, а вопрос кворума решать на клиенте. Ибо нефиг.

Спасибо, Валентин, за информацию! Если будет что-то еще добавить, буду рада снова увидеть Ваши комментарии.

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

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

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

Спасибо что прокомментировали мою статью, @reality_hacker, я согласна с Вашей позицией, и ее не собираюсь отрицать, разве что чуть-чуть. Могу лишь заметить (не в коем случае не для оправдания себя, а справедливости ради), что:

  • в статье я не писала о том, какой кластер Oracle рассматривала — это очень плохо, знаю, так как имея бы практический опыт в построении кластера на RAC архитектуре можно было бы получить другую статью и с другими комментариями, чтоб больше в комментариях писали о своем опыте, который никакие книги/документации не заменят, это придало бы как для меня, так и, возможно, для других некую ценность топика. С этой задачей я справилась плохо (вижу по комментариям), поэтому и приняла Вашу позицию
  • автор — полный дилетант — тоже не буду этого отрицать с одной лишь оговоркой, что все же до MongoDB руки у меня дошли, но уверена, что до гуру мне еще далеко. Об этом я кстати написала в тексте статьи, поэтому не понимаю, почему Вы решили на этом акцент поставить

Я благодарна Вам за правильное замечание по поводу shared nothing дизайна для RAC кластера (что это решение не идет из коробки), но все же ожидала от Вас куда более развернутый комментарий.

Добавлю лишь к своему комментарию, стараясь увеличить его ценность для читателей, что:
Shared-All Architecture — A cluster in which all nodes have concurrent access to shared storage and data is termed a shared-all or shared-everything configuration. Oracle RAC is an example of a shared-everything architecture: a single database located on shared storage is accessed by multiple database instances running on cluster nodes. In the Oracle terminology, an instance refers to the non-persistent memory structures, such as the shared global area (SGA) background- and foreground-user processes
Shared-Nothing Architecture — A shared-nothing database cluster is configured as a number of members in a cluster, where each node has its own private, individual storage that is inaccessible to others in the cluster. The database is vertically partitioned between the nodes; result sets of queries are returned as the unioned result sets from the individual nodes.

Определения взяты из книги Pro Oracle Database 11g RAC on Linux от Steve Shaw, Martin Bach

Спасибо.

Ирина, ваши статьи вгоняют меня в депрессию.

Извините, постараюсь исправится. Юмор то, конечно, заезженный, но даже иногда перечитка позволяет немного расслабится: Programmer Jokes.

Enjoy ;-) как говорится.

И как у тебя только язык повернулся ляпнуть это в адрес такой очаровательной девушки? =)

Добрый день.Спасибо автору за интересную статью о модели разработки,который вычесляет большие наборы данных MapReduce и его применения в контекcте нереляционных хранилищ данных(NoSQL).

Постараюсь сделать свой полезный конструктивный комментарий.
Буду использовать комментарий в фазе «Объяснение/Применение».

Начну пожалуй с термина MapReduce.

MapReduce — это програмная модель,которая вычисляет большие наборы данных,которые могут хранится в кластерах(набор серверов) по определенному алгоритму.Програмная модель состоит из двух процедур:

  • Map() - процедура использования сортировки и фильтрации больших наборов данных(например сортировка первых имен клиентов(firstnane) банка в одном запросе(query)).

    Reduce() - процедура которая использует финальную операцию(например обчисление общего количества всех клиентов банка).

  • MapReduce может иметь разную реализацию на разных языках(Java,C#). На сегодняшний день самый популярный фреймворк/платформа для работы с этой моделью считается проект Apache Foundation — Apache Hadoop

    Apache Hadoop — открытая платформа/фреймворк для работы с большим количеством данных (Big Dat ) ,а также его хранения и вычисления,которые хранятся в кластерах.
    Apache Hadoop состоит из таких компонентов(модулей):

  • Hadoop Common — модуль который состоит из набора библиотек,которые применяються для работы с другими модулями
  • В общем есть механизм использования модели MapReduce не только для NoSQL баз данных,но и для MySQL баз данных.
    Я хочу дописать пожалуйста.
    Второй модуль который используется в этой платформе:

    Hadoop Distributed File System(HDFS) — это распределенная система хранения большого количества данных.
    Используя эти два модуля(Hadoop Common , HDFS) мы создаем приложения которые используют модель MapReduce через некоторые классы.

    В результате все данные записываються в систему HDFS.
    Возникает вопрос: Можно ли применять модель разработки MapReduce в виде приложений не только в контексте нереляционных хранилищ данных?
    Ответ: Можно.Можно и для реляционных баз данных(MySQL).
    Для этого есть специальная программа (Sqoop) для импорта/експорта баз данных(MySQL) в виде таблиц в систему HDFS для подальшей обработки данных с помощью модели MapReduce.Он имеет консольный интерфейс с помощью которого можно создавать БД, експортировать/импортировать данные в спец.таблицы которые размещаються в Hadoop Hive(хранилище данных в Hadoop) или в Hadoop HBase(нереляционная БД,наследник BigTable от компании Google).

    Более детальную информацию об использовании этого приложения можно найти вот в этой книге
    White, Tom. «Chapter 15: Sqoop». Hadoop: The Definitive Guide (2nd ed.)

    Думаю я правильно вам написал конструктивный комментарий. ;)
    Удачи!

    Спасибо Вам большое, Alfared, за полезную информацию!

    простите, у меня только один вопрос — что такое чесло?

    Жодної проблеми в скюелах зробити мапредюс нема. Особливо в Ораклі, де можна в сторд процедури пхати куски повноцінного коду. Проблема в тому що він там нафіг не треба. Більшість мапредюсів можназмапити на реляційну парадигму стандартним скюельом, при тому ще дозволивши вбудованому оптимізатору це все діло пришвидшити.

    В носкюелах ( Монго наприклад, хоча там вже зявився убогенький агрегейшн фреймворк) нема 10ї частини того функціоналу що в ораклі, от тому мапредюс і приходить як срібна куля до кожного таску.

    А по сабжу: ясен пень що все що аггрегейшн можна звести до мапредюсу. С таким самим успіхом можете писати статтю про те чим С# подібний до мови програмування

    Не совсем поняла Вашего высказывания, Роман, так как высказывание

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

    Дело в том, что своего колеса из процедур и функций конечно никто не отменял для замены кастомных агрегационных выражений, однако, чтоб разделить с Вами удовольствие от чтения такого решение, скорей всего найдется не много людей. И, как мне кажется, это скорей будет связанно с тем, что многие будут не готовы к нему, зная о существовании кастомных агрегаций в © Oracle. Куда лучше использовать уже хорошо документированную, затертую до дыр на разных специализированных форумах возможность делать это, которая к тому же тянется с далекого и теплого Сентября, 2003 года — user-defined aggregate functions API: www.oracle-developer.net/...play.php?id=215. Ваше колесо, если я правильно Вас поняла, кроме всего прочего, может оказаться куда менее производительным решением, с проблемой расширяемости, чем тот же user-defined aggregate functions, иначе не вижу причин для существовании такого решения, ведь в © Oracle вроде как тоже не глупые ребята работают. Было бы интересно увидеть от Вас комментарий на то, что я описала выше, так как оно может внести хоть какую-то ясность в Ваше высказывание

    Більшість мапредюсів можназмапити на реляційну парадигму стандартним скюельом
    Більшість, но не все. Хороший пример того, где лучше использовать кастомную агрегацию можно увидеть по ссылке: www.oracle.com/...sql-083623.html, с коротким описанием почему именно. Сноска из статьи (для понимания к чему это, следует прочитать статью):
    The built-in aggregate function AVG does not support the interval types (and the same holds for SUM, by the way). For many, this problem might lead to running procedural code on the client to retrieve and summarize large amounts of data across the network through cursor loops, with all the attendant performance and scalability problems that such an approach might bring. Knowing how to write aggregate functions, however, makes this problem nothing more than a slight speed bump.

    При чому тут моэ колесо? Я ж не кажу використовувати мапредюс на ораклі, це вже ваша ідея.

    Якщо питання стоїть чи можна зробити мапредюс в ораклі і на реляцціонних бахз даних, то відповідь ТАК.

    Чи буде воно ефективніше за стандартну агрегацію: НІ

    Якщо ви не зрозуміли алегорію з шарпом, то я дам іншу: Чи можна використовувати апельсин для апроксимації математичної моделі сфери.

    Можна, але нах нікому не треба

    А по сабжу: ясен пень що все що аггрегейшн можна звести до мапредюсу. С таким самим успіхом можете писати статтю про те чим С# подібний до мови програмування
    — этого высказывания тоже мне не понять, так как я не пыталась быть капитаном очевидность в своей статье. По этой части Вашего ответа много вопросов, и ответ ни на один из них не раскроет, к сожалению, тему топика лучше, поэтому тут я промолчу...

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

    Согласна с Вами полностью, Дима, но речь не об этом в статье, и я об этом попыталась сказать в статье, упоминая при этом труды Gaurav Vaish — Getting Started with NoSQL, и также оговорилась, что в этой книге обозначены области, где какое решение лучше рассматривать со своими плюсами, минусами и возможными подводными камнями.
    Речь в статье как раз о том, о чем написал © Евгений Козлов в своем комментарии ниже, а именно:

    MapReduce и агрегирование — суть одно и то же. И что кастомные агрегаты в купе с возможность распараллеливания между узлами — тот же самый MapReduce, который продают как killer-feature в NoSQL.
    Спасибо, Дима, за полезный, на мой взгляд, комментарий

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

    Да, я это понимаю, Дима. В своей статье я лишь показала один край айсберга, об остальных частях хорошо написано в книге Gaurav Vaish — Getting Started with NoSQL в разделе 4 Advantages and Drawbacks.

    Дима, давайте попробуем с Вами вместе найти природу того, почему у RDBMS ограниченный инструментарий для прямого влияния на работу оптимизатора выполнения запросов, может кто-то еще к нашему диалогу присоединится.

    Как мне показалось после прочтения книги, на которую я сослалась в своей статье и выше в этом комментарии, и других статей на эту тематику, это связано с тем, что в RDBMS при высокой нагрузке и в кластере сложно придерживаться ACID принципов, что и стало одной из причин появления нереляционных хранилищ данных, построенных на альтернативных принципах, называемых BASE, которые описал © Eric Brewer. Кроме этого он сделал еще один существенный вклад в развитие распределенных систем, а именно предложил описывать распределенные системы теоремой CAP. О том, зачем она и что это такое, можно прочитать здесь: en.wikipedia.org/...iki/CAP_theorem
    Что Вы думайте по этому поводу, права ли я или нет? Если нет, могли бы Вы пожалуйста дать развернутый ответ.

    В дополнение еще хочу сказать, что в книге Gaurav Vaish — Getting Started with NoSQL описано, что это за принципы ACID и BASE и за что они отвечают в разделе: What NoSQL is and what it is not

    Конструктивный комментарий по оформлению: оставьте только уникальные ссылки. затем подумайте, для чего ссылки на очевидные справочники(в частности, wiki) любому мало-мальски знакомому с популярными ресурсами интернета? долой и их. в итоге останется пяток ссылок на доку Oracle © Еще удивляет большое количество акцентов на отдельных фразах. Создание информационного шума — не лучший способ передать идею.

    Касательно содержимого: как я понял, при своем довольно ограниченном опыте, речь о том, что механизм MapReduce и агрегирование — суть одно и то же. И что кастомные агрегаты в купе с возможность распараллеливания между узлами — тот же самый MapReduce, который продают как killer-feature в NoSQL. Так? Если все верно, в чем цель такого переусложненного повествования?

    Конструктивный комментарий по оформлению: оставьте только уникальные ссылки. затем подумайте, для чего ссылки на очевидные справочники(в частности, wiki) любому мало-мальски знакомому с популярными ресурсами интернета? долой и их. в итоге останется пяток ссылок на доку Oracle © Еще удивляет большое количество акцентов на отдельных фразах. Создание информационного шума — не лучший способ передать идею.
    согласна с Вами, Женя, буду думать над тем, как улучшить это
    Касательно содержимого: как я понял, при своем довольно ограниченном опыте, речь о том, что механизм MapReduce и агрегирование — суть одно и то же. И что кастомные агрегаты в купе с возможность распараллеливания между узлами — тот же самый MapReduce, который продают как killer-feature в NoSQL. Так?
    Да
    Если все верно, в чем цель такого переусложненного повествования?
    Речь идет о том, что иногда очевидные вещи, которые кажутся верными, могут быть совсем не такими, по крайней мере мой небольшой опыт мне об этом говорит. Поэтому иногда при наличии свободного времени и интереса я выбираю предмет, и стараюсь его изучить, чтоб подтвердить или опровергнуть истинность высказываний. Поэтому решила в это окунутся, чтоб не просто написать пост в стиле — MapReduce — killer-feature в NoSQL и пошло поехало в комментах..., а расширить это своим анализом, чтоб это имело платформу для оснований так полагать и высказываться. По крайней мере пользу от этого я ощущаю — немного начинаешь касаться смежных областей ИТ, понимать их сложность и проблемы. Выложила этот анализ здесь, так как не видела подобного анализа на просторах инета.
    Спасибо, Женя, за Ваш комментарий

    О, господи!
    Вы диплом пишете, что-ли?
    Простите, но такой адской мешанины из терминов, обозначающих совершенно разные вещи и применительно к сферическому коню в вакууме я не видел с институтских времен.
    За оформление похвалю — красиво! )
    .
    Поехали по смыслу:
    1. Оракл — безусловно РЕЛЯЦИОННАЯ СУБД. Практически эталон реляционной СУБД. А NoSQL — нереляционная. Поменяйте термины местами в тексте. Хоть придирка, но принципиальная.
    2. В Оракле существует несколько понятий «кластер» и в них Вы, увы, полностью запутались. Применительно к структурам хранения табличных и индексных данных данное понятие означает всего лишь несколько более оптимальное хранение колонок с ключами. И не более того.
    Это не имеет ни малейшего отношения к распределенным вычислениям. Их в 9i попросту не было вообще.
    3. Остальные понятия «кластера» в Оракле означают метод его развертывания и (не вдаваясь в подробности), представлены всего двумя видами — HA cluster (active-passive) и RAC (active-active). Только последняя из них несколько приближается к понятию «распределенных вычислений», но и то далеко не полностью — системе все еще необходим единый storage и максимальное эффективное количество нод составляет примерно 8 (по причине гиганского траффика между ними).
    4.

    user-defined aggregate functions
    не более чем расширение библиотечного API в Oracle (вендоровский навесок на SQL92) и также не имеют отношения к распределенным вычислениям. Реализация нижнего уровня api полностью up-to-Oracle и не претендует ни на какой стандарт.
    .
    О концепцях нереляционных, распределенных, колоночных и in-memory хранилищ и их реализациях распространяться не буду, т.к. совершенно очевидно что к вышеописанным вещам они не имеют никакого отношения.

    В похвале не нуждаюсь, так как лучшая похвала, это конструктивная и предметная критика, понятная не только мне и/или Вам, но и большинству читающих.
    По вашей придирке к терминам мне сразу видно, что мою статью вы читали по диагонали (если вообще читали...), что больше мне напомнило институтские годы, и Вас в качестве преподавателя. В статье было одно единственное место с ошибкой, на которое я не обратила свое внимание из-за невнимательности (оправдываться себя не собираюсь), что на контекст статьи никоем образом не сказалось и не подмешивало понятия никоем образом, так как текст сам показывал на это узкое место, о котором Vasya Pupking мне подсказал, за что я ему благодарна.
    По поводу Ваших смыслов:

    1. Оракл — безусловно РЕЛЯЦИОННАЯ СУБД. Практически эталон реляционной СУБД. А NoSQL — нереляционная. Поменяйте термины местами в тексте. Хоть придирка, но принципиальная.
    — смысла нет в этом высказывании, так как лишь подчеркивает, что статью Вы не читали (или плохо читали, что с в этом конкретном случае равносильно для меня). Думаю, что для ребят, которые прочли мою статью в первой ее версии этот факт очевиден
    2. В Оракле существует несколько понятий «кластер» и в них Вы, увы, полностью запутались. Применительно к структурам хранения табличных и индексных данных данное понятие означает всего лишь несколько более оптимальное хранение колонок с ключами. И не более того.
    — Вы помойму не внимательно читали документацию Oracle, в которой подчеркивается то, о чем я написала. Поэтому перед тем, как писать то, что Вы написали, было бы не плохо Вам ознакомится с документацией, и я постараюсь Вам в этом помочь. По URL docs.oracle.com/....htm#CNCPT88801 в разделе Schema Object Storage написанно следующее: Figure 2-2 shows a possible configuration of table and index segments, tablespaces, and data files. The data segment for one table spans two data files, which are both part of the same tablespace. A segment cannot span multiple tablespaces. Tablespaces, на сколько мне известно, можно спокойно размазывать по кластеру на основе cluster key, о котором я писала в своей статье. Как это делается посмотрите в туже документацию в секцию Overview of Table Clusters. Как таблицы могут быть размазаны по кластеру в той-же документации нарисовано: Figure 2-6 Clustered Table Data.
    3. Остальные понятия «кластера» в Оракле означают метод его развертывания и (не вдаваясь в подробности), представлены всего двумя видами — HA cluster (active-passive) и RAC (active-active). Только последняя из них несколько приближается к понятию «распределенных вычислений», но и то далеко не полностью — системе все еще необходим единый storage и максимальное эффективное количество нод составляет примерно 8 (по причине гиганского траффика между ними).
    — вы ничего не путайте? Причем здесь виды конфигураций узлов к возможности разделять данные по узлам? Ссылку на документацию/статьи(ю)/расширьте комментарий свой пожалуйста, чтоб это стало очевидным, а то из вашего высказывания больше вопросов, чем ответов на них. Мне кажется, что конфигурация узлов нужна для failover, а не для распределения данных, если нет, — то пруф пожалуйста, либо разжёванный комментарий
    4. О концепцях нереляционных, распределенных, колоночных и in-memory хранилищ и их реализациях распространяться не буду, т.к. совершенно очевидно что к вышеописанным вещам они не имеют никакого отношения.
    — совершенно очевидно как раз обратное из моих ответов выше

    Попробуйте ответить на мои высказывания выше попредметней и обоснованней, так как я здесь не диплом писала, как наверное уже видно... Спасибо.

    Хорошо.
    Вы исправили статью чуть позже, чем я начал писать комментарий, поэтому по первому пункту вопрос снят.
    .
    По второму:
    Понятие table cluster: «A table cluster is a group of tables that share common columns and store related data in the same blocks.»
    Обобщая — это более связаное и компактное хранение данных для жестких реляций. И не более того.
    Tablespaces — логическая сущность для хранения таблиц, индексов и т.д. Физически размещается на одном или нескольких datafiles. Полная аналогия с винчестером и партицией (логическим volume) для файловой системы.
    В рамках одного instance СУБД невозможно держать и обрабатывать часть данных через один сервер, а другую — через другой. Единственное исключение — Oracle RAC, но он ограничен по масштабируемости, посему системой массовой параллельной обработки данных не является тоже.
    .
    Чтобы окончательно зафиксировать сущности — просто приведу пример:
    1. БД Oracle — масштабируется через покупку более мощного сервера, когда недостаточно самого мощного — переделку на RAC максимум до 8 нод из самых мощных серверов, что даст прирост еще примерно в 5 раз. Дальше — все, предел производительности. Примерно такая же ситуация для всех реляционных СУБД — Sybase, MSSQL, DB2 etc.
    2. NoSQL/MongoDB — масштабируется установкой дополнительных серверов до (в теории) бесконечности.
    .
    По вышеописанной причине реляционные СУБД не подходят как для BigData (новое название концепции data warehousing), так и для моделей параллельных распределенных вычислений, одной из которых является MapReduce.

    Спасибо, Тим, за Ваш комментарий

    переделку на RAC максимум до 8 нод из самых мощных серверов, что даст прирост еще примерно в 5 раз

    Ага. Только для этого надо не забыть приложение переписать с учетом RAC специфики.

    Сергей, расширьте пожалуйста свой комментарий, а то уж сильно тонко и многозначно получилось...

    Тим, могли бы Вы, пожалуйста, прокоментировать статью, написанную © Don Burleson по ссылке: Parallel Query. Он описывает как раз то, что на момент 2005 года уже существовало решение у Oracle RAC выполнять распределенные запросы паралельно.

    То есть, я все же настаиваю на своем, что Вы заблуждайтесь по поводу того, что не возможно в Oracle RAC выполнять распределенных запросы при конфигурации кластера, в которой таблицы разделены на отдельные инстансы, либо утверждать, что это не паралельные запросы, и отбрасывать это решение вообще. Don Burleson пишет в своей статье, что эта возможность есть, то есть вызвать паралельный запрос, который удаленно прочитает данные из таблиц. Посмотрите также, пожалуйста, на раздел, где Don Burleson описывает паралельные запросы: Parallel Query for distributed instances.

    Очень хотела бы от Вас увидеть еще комментарии по этому поводу, либо ссылки на документацию, статьи(ю), где объясняется Ваша позиция лучше. Жду с нетерпением.

    Заранее благодарна.

    Ирина, я Вас прошу, не читайте

    © Don Burleson
    , это может вызвать у Вас еще бОльший сумбур в голове.
    Читайте больше документацию.
    Инстанс — экземпляр по-русски. В конфигурации RAC экземпляры монтируют одну и ту же базу данных, в этом случае можно сделать так чтобы
    таблицы разделены на отдельные инстансы
    Замечу что сама по себе эта фраза не имеет смысла. Экземпляр — совокупность памяти и процессов, т.е. это рабочая среда. Таблицы существуют в рамках базы данных. Если не используется RAC, а
    таблицы разделены на отдельные инстансы
    , практически это означает что есть несколько независимых между собой баз данных. Для того чтобы
    вызвать паралельный запрос, который удаленно прочитает данные из таблиц
    нужно для начала каким-то образом синхронизировать данные в этих самых таблицах, находящихся в разных базах данных. А затем так как
    эта возможность есть
    наслаждаться еще одним прекрасным архитектурным решением чтения через db link-и реплицированных до этого данных.
    И несколько слов по поводу статьи. Я пытался понять статью, но не смог, хотя знаком со всеми концепциями очень близко(
    Т.н. «придирки» Тима мне, к примеру понятны. Может все-таки имеет смысл использовать общепринятую терминологию и как-то четче обозначить смысл и цель этой статьи?

    По поводу инстанса — я понимаю значение этого слова, но в любом случае спасибо за определение.

    Документацию я читала. Я понимаю то, что написал © Don Burleson, сумбура у меня в голове нет (по крайней мере до тех пор, пока Вы не докажете обратного), так как то, что вы написали полностью вписывается в мой вопрос. То, что я называю узел (в тексте статьи), который синхронизирует данные между инстансами БД/хранилища данных (экземплярами, как кому удобно называть) — прокси, то он вроде как и выполняет функции, подобно прокси, разделяя данные на этапе загрузки через db link по удаленным таблицам (в случае RAC), либо же паралеля запрос для выполнения во время чтения данных из удаленных таблиц (в томже RAC).

    Что тут неправильного? Объясните пожалуйста детальней.

    Если можно приведите пожалуйста еще список терминов, которые показались Вам странными и не нужными с пояснинием, может я в чем-то была не права, я тоже это вполне допускаю.

    Цель статьи постаралась выразить через заголовок и содержание, смысл — через содержание.

    Смешались в кучу кони, люди...
    В кластерных конфигурациях PQ работает из коробки.
    В распределенных затраты на реплицирование перекроют любые выгоды.
    Что такое прокси? Зачем использовать линки в кластерной конфигурации?
    Причем здесь UDAF?
    Как узел синхронизирует данные?

    Смешались в кучу кони, люди...
    Не делайте поспешных выводов, Alex, не спешите вешать на людей ярлыки, дайте возможность судить читателям по вашим комментариям, а не выводам
    В кластерных конфигурациях PQ работает из коробки.
    Хорошо, спасибо
    В распределенных затраты на реплицирование перекроют любые выгоды.
    Согласна по крайней мере на основе той информации, которую прочла из книг и различных интернет ресурсов
    Что такое прокси? Зачем использовать линки в кластерной конфигурации?
    Задавать такие вопросы нет смысла мне, так как они только уведут наш диалог в ненужном направлении, а мне бы этого очень не хотелось.
    Прокси узлами, в моем понимании, обычно называют узлы, которые инкапсулируют в себя сложную (вообщем-то любую) логику взаимодействия с внутренней инфраструктурой, отдавая при этом приложению простой интерфейс для взаимодействия. Это мое понимание этого термина. Кроме того он широко применяется в обозначении MongoS инстансов, которые роутят запросы по sharding key (точнее по его хешу) на конкретный инстанс MongoDB (mongod) для обработки. Я думаю, что это и так очевидно, тем более при том, что Вы говорите, что имейте достаточно плотный опыт работы с различными хранилищами данных.

    database link используются клиентом (приложением, кому как удобно называть...) для того, чтоб подключится к так называемому мной прокси узлу (см. выше определение) для дальнейшего взаимодействия с кластером (чтение/запись...)

    Причем здесь UDAF?
    Как узел синхронизирует данные?
    Об этих двух вопросах не составит труда почитать, а ответ на них уведет нас еще более в сторону от предмета дискусии.

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

    1. Коментарий начинается с того, что вы вешайте ярлык на человека
    2. Потом переходите к тому, что учите то, что нужно делать, и что нет
    3. Придирайтесь к названиям простых терминов, хотя, я уверена, что у большинства ИТ специалистов эти термины на слуху и каждый более менее владеет их значением

    Я Вас очень прошу, просто ответьте по предмету, согласны ли Вы с тем, что пишет Don Burleson в своей статье www.dba-oracle.com/...allel_query.htm или нет? Если нет, то в чем и почему. И это будет лучшая благодарность от Вас за мою статью.

    Спасибо.

    Ирина, зря Вы принимаете все замечания на свой счет. Во всех комментариях (не только моих) речь идет о технической составляющей Вашей статьи. Там в самом начале alfared немного Вас потроллил в стиле КО, но Вы как-то не восприняли, похоже.

    Я не хочу комментировать «преданья старины глубокой», честно. И вообще я не хочу комментировать те перепечатки из документации, сдобренные часто непроверенной отсебятиной, которые постил раньше и (возможно) продолжает постить

    Don Burleson

    Давайте я перейду к языку аналогий, возможно, он покажется более понятным.
    Представим себе «задачу Золушки» — рассортировать все зернышки, смешанные на полу в одной куче, по своим емкостям. И посчитать общие количества. Для этой задачи мы нанимаем мышей. Понятно что чем больше мышей, тем больше эффективность. Но если их будет слишком много, они начнут мешать друг другу. Теперь предположим расширенную задачу. Амбар общий, но разделенный на разные комнаты, везде рассыпаны зернышки, которые надо отобрать, рассортировать и посчитать. В каждой комнате свои мыши. И есть координаторы, управляющие параллельной работой мышей в соседних комнатах (они уже есть в этой конфигурации). И следующая задача — несколько амбаров, разнесенных территориально. Здесь никаких координаторов нет изначально. Теперь предположим, что для улучшения работы мышей мы их снабжаем специальными черпаками-ситами, приспособленными для определенных типов зерен. И для каких-то нестандартных зерен (например, панський горох, он же нут) мы решили изготовить собственный черпак-инструмент. Собственный черпак-инструмент — это аналог UDAF. Мышь — CPU core. Амбар — сторадж или хранилище.
    Комнаты, на которые амбар разделен — узлы в конфигурации RAC. Собственный черпак-инструмент никогда не будет настолько же эффективным, как стандартные инструменты в лапках мышей. Более того, нельзя ожидать что DOP (degree of parallelism) для собственных инструментов всегда будет такой же как и для стандартных (зависит и от способа реализации, и от запроса, т.е. как инструментом пользоваться), а вот усилий (aka циклов ЦПУ) от мыши они будут отнимать больше однозначно. Если у нас 6 мышей, то нельзя ожидать DOP = 32, все равно они максимум по 6 параллельно могут работать над одной задачей.
    Вот этот вот DOP имеет смысл только в контексте одного амбара, т.е. в конфигурациях одна база — один экземпляр или одна база — много экземпляров. В контексте когда «амбаров много», такое понятие как DOP теряет смысл. Точно также теряет смысл понятие UDAF, оно вообще не имеет смысла вне контекста одной базы данных.
    Теперь понятная аналогия для db link-а. Это когда мы берем одну мышь и заставляем ее приносить зернышки из соседней комнаты или соседнего амбара. Т.е. мы снабжаем ее мешочком и отправляем во вполне конкретный амбар (без всяких прокси и тому подобных измышлений), там местные мыши насыпают ей уже отсортированного зерна и посылают обратно, и так до достижения результата.
    Приносить зернышки из соседней комнаты вообще нет смысла, так как в конфигурации один амбар — несколько комнат уже есть готовые координаторы, и для PQ, и для обмена данными (т.е. зерном), и для координации работы мышей. Иначе на хиба вообще тогда RAC нужен был бы?
    Конечно, можно носить зернышки и из соседних амбаров. Для этого надо выделить минимум одну мышь «на побегушки». Ладно, может аналогия не совсем удачная, так как только чтение из db link-а является действием, потребляющим ЦПУ, но в целом, идея понятна, я надеюсь.
    Аналог монги — множество жилых домов, где в подвале амбар со своими мышами и зерном. Мыши все делают локально и выдают наружу только результат, который затем агрегируется на «прокси».
    Написали бы, что идеи параллельных и распределенных вычислений будоражит Ваше воображение и что Вы бы хотели узнать больше, глядишь, и народ бы подтянулся к обсуждению.

    Спасибо большое, Alex, за хороший ответ.

    Написали бы, что идеи параллельных и распределенных вычислений будоражит Ваше воображение и что Вы бы хотели узнать больше, глядишь, и народ бы подтянулся к обсуждению.
    Да, может Вы и правы в этом. Скажу только, что работа, пусть даже в чем-то абсурдная (а именно — результат работы, не имеющий реального прикладного применения) развивает лучше, как мне кажется, чем спрашивать вопрос с ожиданием найти однозначный ответ среди комментариев, слишком уж эта область мне кажется многогранной, как, наверное, и любая другая.... По крайней мере сама я от такого развития ощущаю и пользу, и удовольствие, в том числе и от комментариев, не смотря на толпы желающих обгадить работу сходу и неконструктивно (при этом поддерживающие развитие ИТ в Украине). Но это уже оффтоп, и по сути меня мало волнует.

    Даже не знаю что и сказать. Желаю больше

    конструктивных комментариев и, главное, дополнений
    и никаких толп желающих обгадить работу сходу!

    Под ’сходу’ я имею ввиду без чтения содержания статьи. Спасибо

    Ирина, попытаюсь.
    Эксперименты с построением аналитических систем на базе RDBMS начались довольно давно и Оракл был одним из ведущих экспериментаторов.
    Первая инкарнация была в районе 2002-2003 года, тогда, как справедливо сказали ниже, сделали OPC. Маркетинговое название — «data warehousing».
    Практика показала, что решение нежизнеспособно по следующим причинам:
    1. В аналитике нет и не может быть жестких структур (собственно — реляций) и если первым уровнем лежит такая структура, а на ней сверху — пользовательские абстракции представления, то через очень непродолжительное время эти абстракции вступают в конфликт с встроенными реляционными механизмами оптимизации и система «грузнет» в очень тяжелых базовых запросах.
    2. Структура реляционных СУБД с точки зрения простой обработки массивов данных очень неоптимальна by design — данные занимают очень много места, стремятся размножиться в большом количестве экземпляров, кэши транзакций практически бесполезны, средства обеспечения целостности данных очень сильно тормозят систему, при этом не имея особого смысла, механизм индексирования плохо справляется с огромными объемами.
    3. Издавна самым узким местом всех СУБД является скорость ввода-вывода. В этих системах количество операций ввода-вывода нарастало в арифметической прогрессии и с разгону упиралось в пропускную способность массивов и интерфейсов. Целостность транзакций требовала единой точки проверки блокировок и диспетчеризации очередей, что делало невозможным реальное «размазывание» данных по большому количеству серверов.
    .
    В целом этот праздник жизни принес огромные барыши производителям серверов и массивов, т.к. эти аналитические системы пожирали целые ЦОДы, но все-равно переставали работать через несколько месяцев. Единственные более-менее успешные внедрения были там, где требовалась строго определенная заранее аналитика, которую очень аккуратно программировали профессионалы еще на этапе внедрения системы и потом никто ничего в нее не добавлял.
    .
    Все данные недостатки специалисты Google оценили еще в то время и просто отказались от концепции RDBMS и создали свое распределенное хранилище.
    .
    Oracle RAC
    Вы прочли литературу времен той первой волны романтических представлений об обработке больших данных, в то время действительно рождались и обкатывались идеи, сегодня реализованные в нереляционных хранилищах.
    Но RAC по итогу был переориентирован на решение других, более прозаичных задач. А именно — OLTP обработки большого количества клиентов.
    Говоря проще — в определенный момент крупные банки, страховые и государственные службы столкнулись с проблемой, что на рынке просто не существует «железа», способного обработать все их сессии в удобоваримое время. Полная аналогия с SMP в мире серверов. И такой же набор тех же новых проблем скорости шины взаимодействия и возросшего количества необходимых вычислений. В RAC невозможно «развязать» ноды на запись — блокировка блока едина для всех нод и кэш изменений постоянно синхронизируется между всеми участниками (с известными оптимизациями).
    Существует замечательный документ, где кратко описано как действительно работает RAC и какие мифы о нем не имеют под собой оснований:
    www.orainternals.com/...f_myths_doc.pdf
    .
    Сегодня на фронте big data
    Сегодня на данном фронте игроки разделились на «богатых» и «технологичных». Первые продвигают in-memory системы на базе простых нетранзакционных хранилищ, где накапливающуюся энтропию можно быстро сбросить при необходимости. Примеры — Vertica, решения SAP.
    Вторые стараются применить другой подход к самому хранению и обработке данных, который позволит убрать узкие места RDBMS, но сохранить гибкость и надежность. Пример — MS SQL 2014 (впрочем он тоже умеет утилизиировать in-memory).
    Однако все эти решения все еще компромиссы на фоне концепции абсолютно параллельных систем по типу Google, Amazon и т.д.
    Я не специалист в них, так что тут и закончу пост. )

    Огромное Вам спасибо, Тим, замечательно написали!

    to @Радион Миронов: что именно, из сказанного Тимом вы поддержали? Так как я смотрю по Вашему профилю, у Вас должен быть хороший прикладной опыт в работе с Oracle БД, и возможно даже, в кластере. Именно это может быть бесценно в Вашем комментарии к статье не только для меня, но и для других, интересующихся этой темой

    Да, и, конечно же, почему поддержали?

    Заранее благодарна

    to @Дмитрий Думанский: что именно, из сказанного Тимом вы поддержали, и почему? Так как я смотрю по Вашему профилю, у Вас может быть бесценный опыт работы в высоконагруженных проектах. Именно Ваш опыт может быть и бесценным в комментарии, а не в клике на кнопку: Поддержать. Это не только для меня могло бы быть полезным, но и для других, интересующихся этой темой

    Спасибо

    Справедливости ради замечу что OPS (Oracle Parallel Server) появился еще в версии 8.1.5 (если я правильно помню), из которого потом путем титанических усилий вышел RAC. RAC уже был в 9-ке. То, что Вы называете HA cluster, всего лишь метод резервирования aka standby. В данном случае просто разница в терминологии. Ограничение в количестве узлов 8 существовало где-то в 90-е. Я не помню, какое максимальное количество в последней версии, но разумное ограничение — количество узлов не больше 100. UDAF — одна из первых попыток задать стандарт в ORDBMS — скрестить объектные и реляционные принципы.

    Спасибо, Alex Batler, что подключились к нам

    как для не реляционного решения на базе БД Oracle 9i+, так и для реляционного на базе, например, популярного в наше время — MongoDB.
    Исправьте ошибочку :)
    И да, «нереляционные» пишется все же слитно

    не, в выделенном фрагменте ошибка в том, что оракл — реляционное решение а монго — нереляционное

    Спасибо, Сережа, за помощь

    Красиво сказываешь. А теперь сколько стоит нанять работника, который сможет довести до ума, и сделать чтобы всё это реально работало и не падало? Насколько я знаю, на Oracle спецы дороги. Да и сам он недёшев по лицензиям.

    Естественно, идея MapReduce не нова. Её реализовывали задолго до SQL. И честно говоря, особых проблем ни у кого не вызывала, менялся лишь обьём кода для её реализации.

    Другой вопрос, что классический MapReduce — имеет весьма небольшую сферу применений. То есть это мало кому нужно. Мода на эти технологии — просто мода, всё равно приходится свистелки-перделки допиливать.

    NoSQL в основном берут именно чтобы уйти от затратности SQL-структур. А не столько ради шардинга. Шардинг это уже второстепенная фенечка.

    Мне приходилось тестировать кластер Oracle. Штука приятная, но они опередили события лет на 10. В те годы просто не было столько данных. Потому мало кто вспоминает о кластерах Oracle. Есть и вторая причина: проекты не рождаются большими. А под малый проект Оракла не берут [опять же, денежка]. Когда проект вырос — его переезд болезненная процедура. Потому пытаются допиливать что есть, даже ценой излишнего кодинга и избыточного железа.

    А вот NoSQL для малых проектов — прост и приятен. А когда вырос — масштабировать их одно удовольствие.

    В контексте комментария выше (dou.ua/...ic/9914/#477256 ), что вы подразумеваете под «кластером Oracle»?

    Спасибо, Женя, за комментарий, не заметила его...
    Я думаю, что Леша имел ввиду решение на базе Oracle RAC с Shared-Nothing? архитектурой. Но лучше конечно услышать это от него, так как я могу ошибаться.

    на базе Oracle RAC с Shared-Nothing?
    Такого в природе не существует

    Спасибо, reality_hacker, за дельное замечание, я действительно считала, что это конфигурируемо в Oracle RAC (Shared-All Architecture/Shared-Nothing Architecture).

    Тоесть для Oracle на сегодняшний день существует лишь одно решение с Shared-Nothing архитектурой — Oracle NoSQL Database. Верно?

    Тоесть для Oracle на сегодняшний день существует лишь одно решение с Shared-Nothing архитектурой — Oracle NoSQL Database. Верно?
    Мне один знакомый Оракл ДБА говорил что они в последней версии выкатили какие то виртуальные базы с этой целью, но подробностей я не знаю

    Ага, спасибо, @reality_hacker!

    Это совсем-совсем другое, и на мой взгляд, никакого отношения к обсуждаемой теме не имеет: речь не о масштабировании, а наоборот — использовании доступных ресурсов (память-процессор) для нескольких plugable баз данных.
    Насколько я понимаю, используется для удешевления поддержки.

    Ну вот мой ДБА утверждал что эти штуки могут сидеть на разных серверах, быть соединены DB линками, и все запросы будут распаралеливаться и агрегироваться. Т.е. такая себе shared nothing архитектура и горизонтальное масштабирование. Хотя может он нагнал, я не в курсе этого дела.

    Как только мы говорим о database link, можно забыть о распараллеливании и масштабируемости в контексте обсуждаемой темы.
    Аггрегирование, как уже упоминалось, — это тоже другое, к масштабируемости отношения не имеет.
    btw — Parallel Query Option была уже в версии 7.1 — двадцать лет назад :-).
    Database links — ещё раньше, в 80-х.

    parallel query option это совсем другая опера, про дб линкс и когда они появились я в курсе.

    Да, это я сгоряча про PQO.
    Но со всем остальным вы же не спорите?

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

    NoSQL в основном берут именно чтобы уйти от затратности SQL-структур.

    Реализация на основе таблицы вида create table «x» («key» varchar(max), «data» blob) даст 50% среднего NoSQL — а именно, key-value хранилище. В отличие от NoSQL базы, он (+) даст упорядочение ключей (то, на что плюют 99% таких баз) и (-) не даст шардинг. Мы вот в текущем проекте сели на Riak именно из-за шардинга с избыточностью, чтобы было 3 копии любых данных. Но уже хотим сбежать — эксплуатировать это, мягко говоря, неудобно.

    Реализация на основе таблицы вида create table «x» («key» varchar(max), «data» blob) даст 50% среднего NoSQL — а именно, key-value хранилище.
    Суть в том что ключ-значение — это не 50%, а скорее 5% от того NoSQL. Из того что я вижу, больше гонятся за масштабируемостью и простотой (тут отдельная и очень флеймообразующая история).
    .
    он (+) даст упорядочение ключей (то, на что плюют 99% таких баз)
    Не совсем понял о чем вы. Если про индексы, то они вроде как есть в той же монге. Если нет, то поясните или дайте ссылку где почитать.
    Не совсем понял о чем вы. Если про индексы, то они вроде как есть в той же монге.

    MongoDB — редкое исключение, которое это умеет. Но у неё другая проблема — нет multimaster с кворумом на запись/чтение. А у тех, у кого это есть (Riak, Cassandra), индексы — только хэши. (Вторичный для кассандры не учитываю, это профанация задачи.)

    Суть в том что ключ-значение — это не 50%, а скорее 5% от того NoSQL. Из того что я вижу, больше гонятся за масштабируемостью и простотой (тут отдельная и очень флеймообразующая история).

    Ключ-значение и даёт ту самую простоту — не надо рисовать схемы, заранее планировать, потом пересчитывать, бодаться с тормозами deployment’а и проблемами типа «при апгрейде сначала перестроить базу вот этим неопробованным скриптом»... И масштабируемость там из того же корня — при шардинге ты фиг выведешь проверку консистентности структуры данных самим движком, всё уходит на код реализации. Зато избавившись от такой поддержки получается возможность растянуть на сколько угодно узлов.
    А вот что-то среднее между ними — не хотят делать, видимо, мало кому нужно.

    А у тех, у кого это есть (Riak, Cassandra), индексы — только хэши.
    Ты ашибаешься, кассандра поддерживает обе схемы: ria101.wordpress.com/...ingpartitioner

    Прочёл. Это какая-то явная дурь. Во-первых, «This means you can scan rows as though you were moving a cursor through a traditional index» молчит как партизан о конкретном методе реализации, а маны по CQL говорят английским по фоновому — по partitioning ключу можно только сравнивать на равенство. Переход на Thrift меня не устраивает. Во-вторых, выбор ByteOrderingPartitioner (сейчас он так называется) сопровождается необходимостью массового заката солнца вручную типа подбирать распределение ключей.

    Чего я хотел: чтобы для каждого конкретного ключа выбиралась нода (группа нод) согласно хэшу ключа, но в пределах ноды было упорядочение. Тогда работал бы запрос типа get_around(base_key, direction, cnt), где direction — одно из ’>=’, ’>’, ’<=’, ’<’, cnt — сколько брать таких с каждой ноды. Дальше пусть только даст результаты (можно не сортировать) и разберёмся сами, что там и почему.

    Прочёл. Это какая-то явная дурь.
    Мы не перешли еще на CQL, а в шрифте все шуршит уже несколько лет.
    его я хотел: чтобы для каждого конкретного ключа выбиралась нода (группа нод) согласно хэшу ключа, но в пределах ноды было упорядочение. Тогда работал бы запрос типа get_around(base_key, direction, cnt), где direction — одно из ’>=’, ’>’, ’<=’, ’<’, cnt — сколько брать таких с каждой ноды. Дальше пусть только даст результаты (можно не сортировать) и разберёмся сами, что там и почему.
    Кассандра на самом деле именно так и устроена, хеши используются только для раскидывания записей по нодам, а внутри ноды все записи в SSTables упорядочены по ключу, просто никто не прикрутил АПИ который тебе хотелось бы, видимо потому что он бы тогда оставлял бы разработчикам меньше маневра как все менять внутри, и то что ты хочешь это уже больше OLAP а кассандра позиционируется как супернагруженная OLTP.
    и то что ты хочешь это уже больше OLAP а кассандра позиционируется как супернагруженная OLTP.

    Да ну, OLAP’а тут и далеко не стояло. OLTP в чистом виде, только вместо супернагруженности ориентация на повышенную надёжность.

    а внутри ноды все записи в SSTables упорядочены по ключу

    Я знаю, я её на это мучал. Только вот это упорядочение начинает работать только при равных партиционирующих ключах. А это условие нам убивает применимость. (Опять-таки я этот ByteOrderingPartitioner не учитываю.)

    а в шрифте все шуршит уже несколько лет.

    При том, что его упорно объявляют устаревшим, я боюсь, что это счастье ненадолго.

    Да ну, OLAP’а тут и далеко не стояло. OLTP в чистом виде, только вместо супернагруженности ориентация на повышенную надёжность.
    Нет, в твоем примере что что-то там агрегировать с разных серверов с разными условиями — это ОЛАП, кассандра — это засунуть и читать отдельные записи — ОЛТП. Приведи пример зачем вообще тебе это нужно, может ты не знаешь просто как базу cassandra-way спроектировать
    Я знаю, я её на это мучал. Только вот это упорядочение начинает работать только при равных партиционирующих ключах. А это условие нам убивает применимость. (Опять-таки я этот ByteOrderingPartitioner не учитываю.)
    Я нифига не понял
    При том, что его упорно объявляют устаревшим, я боюсь, что это счастье ненадолго.
    Шрифт — это как у них все внутри сейчас устроено, CQL — это надстройка над шрифтом. Ну и вот я очень просто загуглил как делать range scans в CQL, а у тебя что не получилось?
    Ну и вот я очень просто загуглил как делать range scans в CQL, а у тебя что не получилось?

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

    Я нифига не понял

    Там в описании к этому виду partitioner’а сказано, что надо самому рисовать границы значения ключа для каждой ноды хранения. В результате или эти границы берутся наобум и тогда на одной ноде густо, а на другой пусто, или их надо постоянно корректировать, делая вручную работу, которую нормальный RDBMS движок делает сам (а именно, анализ индекса, построение профиля ключей по квантилям и использование этих данных для реорганизации индекса и/или вычисления оценок для оптимизатора). Кстати, Cassandra умеет сама запустить переразмещение данных, если ranges партиций изменились? Riak умеет (хотя у него не ranges), добавил ноду — автоматом пошёл фоновый перенос, в результате только периодически проверяешь, закончился ли он и с каким итогом.

    Нет, в твоем примере что что-то там агрегировать с разных серверов с разными условиями — это ОЛАП, кассандра — это засунуть и читать отдельные записи — ОЛТП.

    Это не разные сервера с разными условиями, это несколько серверов одной и той же базы (шардинг по серверам). Каждый хранит свою часть ключей. В варианте Riak это так: если есть N партиций, и для корзины установлено M копий данных, то данные хранятся в партициях от K до (K+M-1)%N, где K=hash(key)%N. Далее партиции распределяются по физическим узлам.
    Прямой лукап по ключу реализуется в поиск партиций по описанным формулам, попытку чтения с этих партиций через их узлы (чаще всего это не тот же узел кольца, что текущий отрабатывающий запрос чтения) и интеграцию результатов для отдачи заказчику (достаточно ли для порога успешного чтения, есть ли разброс между версиями). Стиль «железобетонно, как в реляционке» задаётся условиями nr=1, nw=M, где nr — сколько копий данных должно быть получено для успешного чтения, nw — сколько записано для успешной записи. Стиль «лучшие усилия», как нам нужен, реализуется через nr=ceil((M+1)/2), nw=ceil((M+1)/2), то есть через кворумы. Это я чуть упростил, там несколько параметров для разной специфики взаимодействия. (У кассандры, судя по доке, есть похожие режимы.)

    И ~99% операций в нашем случае — это прямые чтения и записи по ключу. Но оставшийся 1% портит всю малину, выдвигая требования, которые фиг реализуешь его средствами. Так что никакого OLAP, это привиделось от недопонимания.

    Не-а. Видимо, отсутствие реального опыта мешает правильной фильтрации.
    Но я вынужден повторить, что если заранее требуется точная настройка этих самых ranges между нодами, то такая техника мне не нужна — именно эти вещи движок должен решать сам.
    Тогда следует смотреть HBase, он именно под это заточен с самого начала — он балансирует таблеты самостоятельно если они перенагружены
    Кстати, Cassandra умеет сама запустить переразмещение данных, если ranges партиций изменились? Riak умеет (хотя у него не ranges), добавил ноду — автоматом пошёл фоновый перенос, в результате только периодически проверяешь, закончился ли он и с каким итогом.
    В случае добавления ноды кассандра достаточно умная что бы накидать туда данных с перенагруженных нод
    И ~99% операций в нашем случае — это прямые чтения и записи по ключу. Но оставшийся 1% портит всю малину, выдвигая требования, которые фиг реализуешь его средствами. Так что никакого OLAP, это привиделось от недопонимания.
    Ну вот твой оставшийся 1% — это и есть олап. В кассандре такое можно делать с помощью правильного моделирования данных или подключения ее к хадупу

    @reality_hacker, секрет Вашего ответа таится в видах Partitionar’а в Cassandr’е, которые позволяют управлять распределением данных по узлам? А именно в том, что RandomPartitioner делит данные на основе хеша ключа (в основном по алгоритму MD5), а OrderPreservingPartitioner на основе естественного их порядка?

    Спасибо, Богдан, что присоединились к нам.

    @Валентин, я конечно могу ошибаться, но когда вы говорите за упорядочивание ключей, вы имейте ввиду, чтоб они хранились в памяти/на диске в какой-либо структуре для быстрого чтения/изменения, как, например, в MongoDB все индексы хранятся в B-tree структуре (в виде сбалансированного дерева): MongoDB Index Types?

    Да, именно так. По крайней мере в пределах одного узла. (Между узлами это как раз не нужно и для моих целей скорее вредно.)

    Підписатись на коментарі