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, с нашим заказчиком...
Дмитрий, а есть какие-нибудь white papers, презентации, таблицы на русском языке?
ОтветитьУдалитьДля руководства. Чтобы были понятны ключевые моменты технологии.
Чтобы они могли почитать и понять почему это лучше, быстрее и т.п.
На официальном сайте (http://www.oracle.com/global/ru/solutions/business_intelligence/exadata.html) по русски только сама страница, а все документы (PDF) уже на английском.
Конечно же, в библиотеке брошюр Oracle (нажмите на картинку справа на этом сайте) вы найдете на русском все что Вам нужно. Если не найдете - тогда запросите меня еще раз, но укажите чего не хватает.
ОтветитьУдалитьТочная ссылка:
http://www.dsvolk.ru/oracle/wp/tech/#exadata
Это конечно здорово... Мне посчастливилось побывать на одной конференции две недели назад, на которой показывали Netezza TwinFin. Так вот они селект каунты тоже быстро делают умеют :) Ну очень быстро :)))
ОтветитьУдалитьЭх, жалко меня не было !
ОтветитьУдалитьНасколько быстро ? Мы же конкретные люди, не так ли :) ?
>Эх, жалко меня не было !
ОтветитьУдалитьЭто точно... Там кроме Netezza были все: Teradata, Sybase, AsterData, Vertica, GreenPlum...
>Насколько быстро ? Мы же конкретные люди, не так ли :) ?
Если мерить попугаями, то полмиллиарда записей в сек. Но это сферический конь в вакууме. Конкретно по чтению пиковая скорость была до 10Гб в сек (что хорошо согласуется с кол-вом дисков в TwinFin 12). Что заинтриговало лично меня, так это то, что декомпрессия, применение предикатов, AND джойны - почти не влияли на скорость: очень много важных операция работает со скоростью чтения.
А вообще, архитектуры Exadata и Netezza очень похожи, только там где идет первичная обработка данных, у них аппаратная реализация, а у Exadata софтовая, что в теории дает преимущество в гибкости.
Дима, извини, не понял
ОтветитьУдалить1.select count(*)
2.На таблице нет индексов.
Разве 1 будет быстрее, если будет 2?
> Разве 1 будет быстрее, если будет 2?
ОтветитьУдалитьhttp://sql.ru/forum/actualthread.aspx?tid=735268
Index fast full scan
> до 10Гб в сек
ОтветитьУдалитьПолучается что у половинки Exadata скорость будет примерно такой же (10,5) и это если не включать компрессию. Не смог найти сходу сколько дисков в TwinFin 12 :(
> у них аппаратная реализация, а у >Exadata софтовая, что в теории дает преимущество в гибкости.
+1024
Отдельно напишу про это.
Там есть о чем поговорить, хотя бы о том, что легче обновлять, софт или hard :)
>Получается что у половинки Exadata скорость будет примерно такой же
ОтветитьУдалитьПолучается, только за совсем другие деньги... :-)
>...это если не включать компрессию
Объясните мне глупому, как компрессия увеличивает скорость чтения (Мб\с) с дисков? Они от этого быстрее крутятся? :)
>Не смог найти сходу сколько дисков в TwinFin 12 :(
96
> Получается, только за совсем
ОтветитьУдалить> другие деньги... :-)
Действительно, а если нет разницы, зачем платить больше :)))))
Apex, эта дискуссия у нас с Вами вечная :))
> Объясните мне глупому, как >компрессия увеличивает скорость >чтения (Мб\с) с дисков
У вас есть 1 Tb данных. Вы их загрузили в БД и можете прочитать за x сек. Теперь вы их сжали и можете прочитать за x/5 сек. С точки зрения стороннего наблюдателя, возросла скорость чтения данных, не так ли ?
Если вы можете измерять объем данных только на выходе.. Компрессия - важная вещь. Хотя даже она не может изменить скорость вращения дисков :)
>> Объясните мне глупому,
ОтветитьУдалить>> как компрессия увеличивает
>> скорость чтения
Эффект "увеличения скорости чтения" основан на том, что скорость декомпрессии намного быстрее скорости чтения. Если данные на диске сжаты, то их прочитать и расжать намного быстрее чем полностью читать несжатые данные.
>Эффект "увеличения скорости чтения" основан на том
ОтветитьУдалитьЯ не про эффекты спрашивал, а про суть. А суть в том, что компрессия не увеличивает скорость чтения с диска. И это был сарказм, если кто не понял. И относился он вот к этому: "Получается что у половинки Exadata скорость будет примерно такой же (10,5) и это если не включать компрессию. " - можно подумать, что если включить компрессию, будет не 10,5. Будут те же 10.5, а уж сколько при этом строк в сек вернется/обработается, зависит от характера данных (что-то сжимается лучше, что-то хуже), от организации этих данных (строки тоже разной длины бывают) и т.д.
Сарказм действительно не уловил. Sorry.
ОтветитьУдалитьВообще, о чем мы тут говорим? Всегда можно собрать стенд за три копейки, который в очень узком частном случае покажет очень серьезную производительность и я совершенно не удивлюсь, если этот стед покажет count (*) быстрее дорогущего промышленного решения.
Я как-то уже говорил о том, что СУБД не взаимозаменяемы как батарейки. Это можно сравнивать energizer с duracell. А базы данных сравнивать дело неблагодарное :^)
Представьте приложение, которое 10 лет затачивалось исключительно под netezza, специально тюнинговалось, использует кучу специфичных фич, и вот пришла teradata и показывает как работает count звездочка. Но приложение надо полностью переписать чтобы на нее переехать. Сила экзадаты в том, что эта технология прозрачна для проложений под oracle. Если вы плотно сидите на оракл (например, у вас oebs) то это для вас важно. Оракл ведь не самая быстрая база. TimesTen в десять раз быстрее сделает каунт звездочка. А Berkeley DB еще в 10 раз быстрее. Но эти базы данных не умеют многого, сто умеет оракл... В общем, выбирать в отрыве от конкретного приложения бесполезно. Если у Вас в распоряжении одно единственное весьма примитивное приложение, которое за месяц пара программистов перепишут подо что угодно, то выбирать технологию крайне тяжело...
Мои личные мысли... :^)
>А базы данных сравнивать дело неблагодарное :^)
ОтветитьУдалитьИ тем не менее их постоянно сравнивают, в т.ч. и вы, в т.ч. и в этом блоге. :)
Что касается конкретных задач: тут я с вами полностью согласен, именно на это и был направлен мой сарказм - в заметке то речь про count(*) как раз, и одно это преподносится как космическая технология на службе у слесаря... Комплексно надо к пиару подходить:)
Это уже мои личные мысли:)
Все правильно. Я стараюсь никогда не сравнивать :^)
ОтветитьУдалить...Это если только Волков. Но его контролировать бесполезно. Он просто берет и пишет в блог. Ну что с ним поделаешь? :^)