другие мнения..
Первая из них (также доступная для скачивания с этой страницы) мне кажется наиболее взвешенной, содержит описание как Exadata так и различных моделей систем IBM Smart Analitics и откуда вы можете получить отдельное удовольствие от например, просмотра модели 5600 with SSD Option, которая совершенно случайно содержит от 2-х до 8-ми узлов, 5 Tb flash, извините SSD, 100 TB raw пространства, что совершенно случайно совпадает с Exadata Full Rack. Еще раз, все совпадения совершенно случайны -)
Вторая, замечательна тем, что есть ее перевод на русский язык. Ее можно положить на стол вашему руководителю. Конечно, она содержит несколько милых
"Обратите внимание, что масштабирование [Exadata] невозможно без добавления дополнительных дисков: это означает, что вы не сможете просто добавить новую вычислительную мощность, если у вас имеется «бутылочное горлышко» на процессоре: вам придется приобретать дополнительные мощности для хранения данных, даже если они вам не нужны" стр 6.
Если коротко - поставить сейчас flash или ssd диски - это не проблема. Сделать так чтобы 'горячие данные' туда заползали сами - также (Exadata flash cache, IBM Storwise easy tier). Единственное, что действительно сейчас недостижимо с помощью аппаратных средств - это сжатие больше чем в 2-3 раза. Exadata действительно здорово сжимает данные в хранилищах. Правда, есть и другие мнения...
Update 1. В комментариях написали, что я забыл про Smart Scan. Если говорить про Oracle Database, да, технологий кроме Exadata, которые могут сделать что-то подобное нет, и надо быть честным вряд ли будут.
Ecли рассматривать не только Oracle, то ниже вы видете картинку как работает Netezza - специальный модуль FPGA, установленный внутри S-Blade (это аналог Storage Node), занимается фильтрацией данных. FPGA который (я честно не понял до конца) является комбинацией hardware и software (?), но крайне низкого уровня, занимается тем же самым smart scan. Т.е. идеи витают в воздухе....
Сообщения
>>Единственное, что действительно сейчас недостижимо с помощью аппаратных средств - это сжатие больше чем в 2-3 раза.
ОтветитьУдалитьа как же SmartScan ?
Ведь никто, кроме оракла, по определению это реализовать не сможет !
Как бы ни была талантлива копия, она лишь копия оригинала ;) Уверен, что если покапаться еще парочка "НО" найдется в копилку ;)
ОтветитьУдалитьОтличная фотка: "Кто девушку ужинает, тот ее и танцует"
ОтветитьУдалить>> другие мнения..
Это никакие не другие мнения :^) Это уже известное всем мнение IBM, поданое под камуфляжем агентства. В документе четко указано: This document was developed with IBM funding, так как законы развитых стран обязывают авторов декларировать такие вещи.
По-русски это означает, что автор Филип Ховард получил от IBM деньги за эти материалы, поэтому искать в этих документах что-то хорошее про Exadata это как искать в говне сметану.
Посудите сами: Из-за конфликта интересов Филип Ховард не в состоятинии честно сравнить технологии, так как если он это сделает, то заказчику документ не понравится, документ не появится на сайте IBM и Филип Ховард не получит бабки.
Кладите на стол вашему руководителю аналитику от компаний калибра Gartner или IDC. Вы не увидите в документах этих по-настоящему независимых аналитических компаний надписей мелким шрифтом: This document was developed with IBM funding.
слушьте, ну за чем в хорошем блоге холивар устраивать, расскажите не о том чего нету, а что есть, и не надо этой ерунды про флеш и ссд...
ОтветитьУдалитьЯ особенно рекомендую прочитать раздел о сжатии в Oracle и IBM. Феерическая демагогия. Надо отдать должное - Дмитрий не говорит, что сжатие в IBM лучше, а вот Говард врет без зазрения совести.
ОтветитьУдалитьМы все прекрасно знаем, что в Oracle есть 2 типа сжатия - обычное и поколоночное, а в IBM - только обычное. Обычно сжатие работает очень похоже - здесь сложно что-то придумать новое. А вот поколоночного сжатия, которое работает просто великолепно именно для хранилищ (ведь статья о хранилищах), в IBM просто нет, но Говард приходит к выводу, что Oracle сжимает хуже. Кстати, в статье ни слова про архивный режим поколоночного сжатия от Oracle.
Дальше я уже не читал: человек перевирает даже очевидные вещи. Что уж тут говорить про спорные моменты? :)
P.S. Кстати, для хохмы и, чтобы поднять настроение можно почитать статью про Adabas которая по мнению Bloor Research является "сравнимой (если не превосходящей) с
другими современными и прогрессивными базами данных": http://www.softwareag.com/ru/Images/Bloor_Adabas_rus_tcm63-12984.pdf
читал, не нашел знакомых букв. чтобы понять эти статьи, надо быть глубоко в теме и IBM, и Oracle решений. В противном случае читающий возьмет сторону привычного. Т.е. Оракла :)
ОтветитьУдалить> как же SmartScan ? Ведь никто, кроме оракла
ОтветитьУдалитьСпасибо, обновил пост. Да, для Oracle Database - никто, но в мире есть подобные реализации других вендоров...
>чтобы понять эти статьи, надо быть глубоко в теме и IBM, и Oracle решений
Согласен, пока это сложно, я и сам не слишком хорошо все понимаю. Буду работать над этим
> ну за чем холивар устраивать
Нет, Сергей вовсе не устраивал холивар. Он привел вполне законный аргумент - 'не подсоввывайте мне статьи спонсированные одним их вендоров'. Другое дело, что там есть хотя бы описание решений, что может быть полезно. Я бы на месте Сергея сосредоточился бы на ошибках, вместо констатации 'денежного' факта.
>и не надо этой ерунды про флеш и ссд...
Не понял. Увы ssd сейчас чуть ли не основной аргумент в сравнении performance. Ничего не могу сделать -( Или вы что-то имели в виду другое ?
>Дмитрий не говорит, а вот Говард врет без зазрения совести.
Бу-га-га. Не делайте мне смешно. В отличии от, я немного понимаю в том, о чем я пишу...
>А вот поколоночного сжатия в IBM просто нет
>в Oracle есть 2 типа сжатия - обычное и поколоночное, а в IBM - только обычное
Серьезно ?
http://www.dbms2.com/2010/06/21/netezza-ibm-db2-compression/
Я хотел сказать, что даже за деньги, даже специальное агентство не может написать относительно честное сравнение, потому что это очень сложно технически.
ОтветитьУдалитьНадо разбираться самим, нет других вариантов -(
М-да... Интересно прочитать всё это у человека, который чуть ли не первый рассказывал русскоязычному оракловскому сообществу о том, как устроена Экзадата. О том, что в Экзадате часть Оракла сидит в самом сторэдже и эта часть выполняет самую тяжелую работу по фильтрации строк и столбцов, снимая тем самым нагрузку с сервера и каналов ввода-вывода. О том, что сторэдж сам создаёт табличные пространства и выполняет быстрое инкрементальное копирования, не отвлекая сервер от работы. О том, что в памяти сторэдж-сервера хранятся диапазоны значений (сторэдж-индексы), анализ которых позволяет вообще пропускать целые участки дисковой памяти, в которых заведомо нет нужных нам данных. О том, что в Экзадате флэш-диски используются не для кеширования всего на свете, а только оракловских блоков и в очень интеллектуальной манере. О многих интересных вещах рассказывал нам Дмитрий, о которых сейчас, видно, уже подзабыл...
ОтветитьУдалитьА приведенные аналитические исследования без улыбки вообще читать невозможно. Ну кто этому автору сказал, что Экзадата хранит таблицы в сжатой форме по столбцам, потому что значения в столбце одного типа и потому хорошо сжимаются. Да не потому они хорошо сжимаются, что однотипные! При постолбцовом хранении повторяющиеся значения (например, в столбца-справочниках) ЛЕЖАТ РЯДОМ и только потому хорошо сжимаются. Я уже молчу о рассуждениях про супер-партиционирование в DB2 в одном разделе с индексами хранения Экзадаты...
>чуть ли не первый рассказывал русскоязычному
ОтветитьУдалитьне надо грязи, я был первый -)
>О том, что в Экзадате часть Оракла
Все верно
>о которых сейчас, видно, уже подзабыл..
ну так Oracle не дает мне Exadata, вот я и подзабыл. Приходил кстати, один партнер, обещал дать в тест машину, но куда-то пропал....Слабо, да ?
>без улыбки вообще читать невозможно
У них есть автор, улыбайтесь ему -)
> http://www.dbms2.com/2010/06/21/netezza-ibm-db2-compression/
ОтветитьУдалитьДмитрий, из статьи я понял, что в Netezza нынче используются 2 алгоритма сжатия: prefix compression и Huffman coding.
Префиксное сжатие применяется для сжатия индексов и оно появилась в Oracle очень-очень давно (в 9-ке точно уже было). Я как бы даже его и не считал ;) Это само собой разумеющаяся вещь.
А Huffman coding - это тот старый добрый Huffman, который применяется для сжатия ZIP, JPEG и MP3? :) Так он же очень медленный.
>А вот поколоночного сжатия в IBM просто нет
ОтветитьУдалить>из статьи я понял
2-ой абзац статьи, цитата "Both Netezza and IBM have chosen completely column-oriented compression...."
>А Huffman coding..Так он же очень медленный.
Открываем zlib.h на любом Unix. Тут же видим упоминание алгоритма Huffman. А теперь идем на tahiti.oracle.com
http://download.oracle.com/docs/cd/E11882_01/license.112/e10594/apxa.htm#DBLIC209
Цитата "Oracle gratefully acknowledges the contributions of Jean-loup Gailly and Mark Adler in creating the zlib general purpose compression library which is used in this product."
В любой книжке/статье про Oracle Advanced compression вы легко найдете упоминание zlib.
Но вот что действительно плохо, так то что вы не в курсе что query high и archive low, те самые знаменитые алгоритмы сжатия в Exadata, используют все тот же zlib.
PS Как дети, ей богу. Собственных сайтов и алгоритмов не знают -)
> 2-ой абзац статьи, цитата "Both Netezza and IBM have chosen completely column-oriented compression...."
ОтветитьУдалить1. А ссылку на официальную документацию про поколоночное хранение или, на крайний случай, про поколоночное сжатие (что, кстати, разные вещи)? Мне кажется - это мечты маркетологов.
> В любой книжке/статье про Oracle Advanced compression вы легко найдете упоминание zlib.
2. В любой книжке это какой? Я искал в документации: тынц1, тынц2. Ну и погуглить можно. Кстати, в твоем блоге это тоже можно прочитать. СУБД Oracle использует zlib для сжатия Spatial Georaster, JPEG и резервных копий RMAN.
> query high и archive low, те самые знаменитые алгоритмы сжатия в Exadata, используют все тот же zlib.
3. Да я и не специалист в Exadata - тут ты, скорее, гуру, чем я. Но query high и archive low предназначены скорее для длительного хранения информации, но и степень сжатия там в 14-22 раза. А вот в Query Low - там да, используется LZO и это алгоритм, заточенный на быструю распаковку.
;) Ладно - умолкаю, умолкаю
>> но и степень сжатия там в 14-22 раза
ОтветитьУдалитьСейчас опять начнется... :^)
> Сейчас опять начнется... :^)
ОтветитьУдалитьЯ ссылку привел ;) Я - чист. *перекинул стрелки на Томина*
>СУБД Oracle использует zlib для сжатия Spatial Georaster, JPEG и резервных копий RMAN.
ОтветитьУдалитьТы забыл secure file compression и redo transport compression.
>Сейчас опять начнется..
>*перекинул стрелки на Томина*
Тонкий ход, ничего не скажешь -)
>а как же SmartScan ?
ОтветитьУдалить>Ведь никто, кроме оракла, по определению это реализовать не сможет !
*Ржот*
Можно я вас буду цитировать?
*очередной вброс в вентилятор*
А еще компрессия есть у Терадаты
*отпрыгивает*
P.S. Я, в отличии от вас, ребята, на вендора не работаю и за этим серпентарием наблюдаю со стороны)))
Классный термин серпентарий.
ОтветитьУдалитьЕсли наблюдаете, значит блог свою функцию выполняет :^)
>Если наблюдаете, значит блог свою функцию выполняет :^)
ОтветитьУдалитьРазумеется, для меня это как на карусели покататься или в зоопарк сходить.
Кстати, какие зоопарки Лондона порекомендуете?
Для меня тоже :^)
ОтветитьУдалитьМы живем в деревне и в Лондон я езжу только по работе и, пожалуй, раз в месяц, не чаще. Вся идея была жить не в городе, а в домике в деревне.
Поэтому моя семья до лондонских зоопарков не доехала. Но за пределаими Лоднона могу порекомендовать Longleat Safari and Adventure Park (http://www.longleat.co.uk/) Там можно на машине въехать и животные будут вокруг без клеток. Это на юго-западе острова, недалеко от города Bath.