How to read 1 billion rows in 2 sec ?

Short answer: Use Exadata :)




Один из видов тестирования, которые предлагает Oracle - это однодневный визит в ETC (Enterprise Technology Centre) под Лондоном, во время которого инженеры рассказывают про продукт, его пропускную способность. Cама Exadata V2 стоит за стеклом, но к ней можно подойти, потрогать, попросить запустить какой-то запрос. Нет никаких проблем с английским - оказывается я могу переводить почти в синхронном режиме. Реально, лучше всего один раз увидеть. Самолет из Москвы летит 4 часа. Погода (дождь) и еда (fish & chips) отвратительные, но вы же не есть приехали :)) Хотя, если знать места...:). Так вот, один из наших заказчиков и решил увидеть все своими глазами..


Вот только один тест, который показали во время этого визита инженеры ETC: табличка с 1,000,000,000 записей, по которой считается select count(*). Нам нужно прочитать примерно 60 Gb данных. Что мы с успехом и делаем за 7 сек (~8,5 Gb/s). Затем, мы применяем Hybryd Columnar Compression (HCC) Query Mode, что позволяет нам сжать таблицу примерно в 3 раза и тот же запрос выполняется за 2,7 сек. Далее мы сжимаем таблицу еще больше с помощью HCC Archival Mode, объем становится 10gb (сжатие примерно в 6 раз) и наш запрос завершается уже за 2,68 сек. На таблице нет индексов. В запросе участвует 6 Exadata Storage Cell (теоретическая пропускная способность 1,5 gb per cell). Мы не использовали помещение таблицы во Flash Cache в этом тесте. Это чистое тупое чтение с дисков. Для очень умных: buffer cache тут "не играл". Сами догадайтесь почему :). C Flash Cache даже несжатая таблица читалась за 0,5 сек.


Другая возможность, которая существует - это передать свою БД версии 11.2 на тестирование в ETC. Звучит заманчиво :) Теперь немного деталей. Быстро делаем ee обновление. Все расписано в одном из предыдущих постов. Затем вы должны ее обезличить. Далее, пожалуйста ограничьте ее 1-5 Tb. И наконец, придумайте способ воспроизводить нагрузку. Мы очень любим воспроизводить нагрузку, записанную с помощью Real Application Testing. Нагрузка воспроизводится в реальном времени. По факту тестирования тут же вы получаете отчет, в котором расписано сколько запросов улучшилось и насколько. Вообще план тестирования на Exadata звучит настолько просто, что только ленивый сейчас этим не воспользуется.

Кстати, совершенно случайно, у нас есть story по этому поводу: "Одна из американских компаний, производящих рекламные уличные панели использовала 11.1.0.6 на платформе Linux. Они захватили пиковую нагрузку в течении 5 часов и решили протестировать дисковые массивы различных производителей. После завершения тестов они захотели попробовать Exadata. Тут не обошлось без приключений и они встретились на 11.2 с bug #9066130. К счастью, fix уже существовал и после его установки они получили уменьшение DB Time на 62%. По заявлению наших product managers они продолжают сотрудничество с нашим ETC центром для следующих тестов".

Я не помню, возможно я упустил, тестирование в ETC бесплатно для заказчика. Имеет смысл позвонить в Oracle +7 495 641 14 00. Я, кстати, думаю, что скоро смогу рассказать уже и свою success story, с нашим заказчиком...

15 комментариев:

  1. Дмитрий, а есть какие-нибудь white papers, презентации, таблицы на русском языке?

    Для руководства. Чтобы были понятны ключевые моменты технологии.

    Чтобы они могли почитать и понять почему это лучше, быстрее и т.п.

    На официальном сайте (http://www.oracle.com/global/ru/solutions/business_intelligence/exadata.html) по русски только сама страница, а все документы (PDF) уже на английском.

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

    Точная ссылка:

    http://www.dsvolk.ru/oracle/wp/tech/#exadata

    ОтветитьУдалить
  3. Это конечно здорово... Мне посчастливилось побывать на одной конференции две недели назад, на которой показывали Netezza TwinFin. Так вот они селект каунты тоже быстро делают умеют :) Ну очень быстро :)))

    ОтветитьУдалить
  4. Эх, жалко меня не было !

    Насколько быстро ? Мы же конкретные люди, не так ли :) ?

    ОтветитьУдалить
  5. >Эх, жалко меня не было !
    Это точно... Там кроме Netezza были все: Teradata, Sybase, AsterData, Vertica, GreenPlum...

    >Насколько быстро ? Мы же конкретные люди, не так ли :) ?
    Если мерить попугаями, то полмиллиарда записей в сек. Но это сферический конь в вакууме. Конкретно по чтению пиковая скорость была до 10Гб в сек (что хорошо согласуется с кол-вом дисков в TwinFin 12). Что заинтриговало лично меня, так это то, что декомпрессия, применение предикатов, AND джойны - почти не влияли на скорость: очень много важных операция работает со скоростью чтения.
    А вообще, архитектуры Exadata и Netezza очень похожи, только там где идет первичная обработка данных, у них аппаратная реализация, а у Exadata софтовая, что в теории дает преимущество в гибкости.

    ОтветитьУдалить
  6. Анонимный12/2/10 10:13 PM

    Дима, извини, не понял

    1.select count(*)
    2.На таблице нет индексов.

    Разве 1 будет быстрее, если будет 2?

    ОтветитьУдалить
  7. > Разве 1 будет быстрее, если будет 2?

    http://sql.ru/forum/actualthread.aspx?tid=735268

    Index fast full scan

    ОтветитьУдалить
  8. > до 10Гб в сек

    Получается что у половинки Exadata скорость будет примерно такой же (10,5) и это если не включать компрессию. Не смог найти сходу сколько дисков в TwinFin 12 :(

    > у них аппаратная реализация, а у >Exadata софтовая, что в теории дает преимущество в гибкости.

    +1024
    Отдельно напишу про это.
    Там есть о чем поговорить, хотя бы о том, что легче обновлять, софт или hard :)

    ОтветитьУдалить
  9. >Получается что у половинки Exadata скорость будет примерно такой же
    Получается, только за совсем другие деньги... :-)

    >...это если не включать компрессию
    Объясните мне глупому, как компрессия увеличивает скорость чтения (Мб\с) с дисков? Они от этого быстрее крутятся? :)

    >Не смог найти сходу сколько дисков в TwinFin 12 :(
    96

    ОтветитьУдалить
  10. > Получается, только за совсем
    > другие деньги... :-)

    Действительно, а если нет разницы, зачем платить больше :)))))

    Apex, эта дискуссия у нас с Вами вечная :))

    > Объясните мне глупому, как >компрессия увеличивает скорость >чтения (Мб\с) с дисков

    У вас есть 1 Tb данных. Вы их загрузили в БД и можете прочитать за x сек. Теперь вы их сжали и можете прочитать за x/5 сек. С точки зрения стороннего наблюдателя, возросла скорость чтения данных, не так ли ?
    Если вы можете измерять объем данных только на выходе.. Компрессия - важная вещь. Хотя даже она не может изменить скорость вращения дисков :)

    ОтветитьУдалить
  11. Анонимный17/2/10 6:54 PM

    >> Объясните мне глупому,
    >> как компрессия увеличивает
    >> скорость чтения

    Эффект "увеличения скорости чтения" основан на том, что скорость декомпрессии намного быстрее скорости чтения. Если данные на диске сжаты, то их прочитать и расжать намного быстрее чем полностью читать несжатые данные.

    ОтветитьУдалить
  12. >Эффект "увеличения скорости чтения" основан на том
    Я не про эффекты спрашивал, а про суть. А суть в том, что компрессия не увеличивает скорость чтения с диска. И это был сарказм, если кто не понял. И относился он вот к этому: "Получается что у половинки Exadata скорость будет примерно такой же (10,5) и это если не включать компрессию. " - можно подумать, что если включить компрессию, будет не 10,5. Будут те же 10.5, а уж сколько при этом строк в сек вернется/обработается, зависит от характера данных (что-то сжимается лучше, что-то хуже), от организации этих данных (строки тоже разной длины бывают) и т.д.

    ОтветитьУдалить
  13. Анонимный18/2/10 10:46 PM

    Сарказм действительно не уловил. Sorry.

    Вообще, о чем мы тут говорим? Всегда можно собрать стенд за три копейки, который в очень узком частном случае покажет очень серьезную производительность и я совершенно не удивлюсь, если этот стед покажет count (*) быстрее дорогущего промышленного решения.

    Я как-то уже говорил о том, что СУБД не взаимозаменяемы как батарейки. Это можно сравнивать energizer с duracell. А базы данных сравнивать дело неблагодарное :^)

    Представьте приложение, которое 10 лет затачивалось исключительно под netezza, специально тюнинговалось, использует кучу специфичных фич, и вот пришла teradata и показывает как работает count звездочка. Но приложение надо полностью переписать чтобы на нее переехать. Сила экзадаты в том, что эта технология прозрачна для проложений под oracle. Если вы плотно сидите на оракл (например, у вас oebs) то это для вас важно. Оракл ведь не самая быстрая база. TimesTen в десять раз быстрее сделает каунт звездочка. А Berkeley DB еще в 10 раз быстрее. Но эти базы данных не умеют многого, сто умеет оракл... В общем, выбирать в отрыве от конкретного приложения бесполезно. Если у Вас в распоряжении одно единственное весьма примитивное приложение, которое за месяц пара программистов перепишут подо что угодно, то выбирать технологию крайне тяжело...

    Мои личные мысли... :^)

    ОтветитьУдалить
  14. >А базы данных сравнивать дело неблагодарное :^)
    И тем не менее их постоянно сравнивают, в т.ч. и вы, в т.ч. и в этом блоге. :)

    Что касается конкретных задач: тут я с вами полностью согласен, именно на это и был направлен мой сарказм - в заметке то речь про count(*) как раз, и одно это преподносится как космическая технология на службе у слесаря... Комплексно надо к пиару подходить:)

    Это уже мои личные мысли:)

    ОтветитьУдалить
  15. Анонимный20/2/10 10:54 PM

    Все правильно. Я стараюсь никогда не сравнивать :^)

    ...Это если только Волков. Но его контролировать бесполезно. Он просто берет и пишет в блог. Ну что с ним поделаешь? :^)

    ОтветитьУдалить