Пока одной рукой льем в S3, второй вставляем в GP через мастер в AO h-store таблицы. Максимальная скорость вставки порядка 5-6 гигабайт в минуту, нам пока этого хватает. Постепенно уходим от этого, есть решение, когда мы раз в час с помощью PXF с сегментов подтягиваем данные из S3, несколько источников уже так проинтегрированы, скорость ощутимо выше.
В первую очередь он на тестах ощутимо медленнее работал с GP. Плюс разработка на Clojure+JS, а нас опыта с питоном намного больше. Ну и, насколько поняли, синхронизация с AD(LDAP) - только в платной версии.
110TB это было с учетом мирроров. Сейчас у нас на ноду 10TB HDD + 10TB SSD, и весь кластер суммарно уже на 440TB вышел. Расточительство хранить сырые данные в GP, нужно укалдывать все 110 TB с компрессией полезными данными ODS/DDS.
В Я.Облаке в 19 году этой фичи не было, да и диски у нас максимального размера - 4TB, т.е. никаких зарезаний по дисковому QoS со стороны самого облака точно не было. Плюс, нужно понимать, что диски в облаке сетевые и живут не рядом с виртуалками и любой запрос в GP (обращение к диску) идет в сеть между гипервизорами и стораджем. Так что тут тесты были нужны, чтобы понять максимальные возможности сети яндекс облака. После этого мы начали запрашивать от Я.облака ускорение дисков, в прошлом году появились NRD диски - прирост производительности составил ~20%. Мы купили производительность за счет снижения надежности. Сейчас же у нас инсталляция живет на выделенных хостах с локальными дисками - там все намного лучше, чем на сетевых и NRD, получили мы в итоге порядка +50% производительности дисков в сравнении с 4TB сетевыми SSD.
Фуллскан - да, но в нашей железной инсталляции мы увидели, что на HDD (шпиндели) диски в RAID10 со скоростью чтения 4ГБ/с запросы работали ощутимо медленнее SSD с той-же максимальной скоростью чтения, но ощутимо большими IOPS. Среднее время выполнения мелких запросов по витринам и справочникам упало с ~16с до ~4c. Плюс хранение pg_catalog на SSD, что повышает общую отзывчивость базы. Сейчас у нас 2 тейблспейса в GP - дефолтный на SSD и теплый на HDD.
6 сетевых дисков в облаке пробовали - прироста не выявили, похоже упирались в сеть между гипервизорами.
Для бизнеса - любая платформа сложная, но я бы не сказал, что текущая имплементация получилась технически сложная. Ну а так, да, бизнес доверяет инженерам, формирует требования, а реализацию оставляет нам.
Основной экономический эффект дают продукты, созданные после появления платформы, т.н.дата-продукты. В больших компаниях внедрение даже крошечных оптимизаций и нововведений может приносить огромную прибыль (экономию). Конкретные цифры называть не могу, но могу сказать, что несколько наших дата-продуктов экономят компании несколько сотен миллионов рублей в год.
Колоночное сжатие есть и в GP =) Все-таки полноценного ANSI https://clickhouse.tech/docs/ru/sql-reference/ansi/ нашим дата-инженерам в клике не хватает, поэтому он не для всех задач подходит. Сейчас тестируем его для быстрых слоев витрин, поделимся выводами, когда закончим
Был у меня Sudden Death летом 2013го (покупал осенью 2012го), в магазине спокойно взяли телефон, через 2 недели вернули — починили по гарантии. По сути получился новый телефон — новый серийник, IMEI и т.п. Остался доволен сервисом.
Если есть желающие, могу отдать аккаунты оттуда — два 23го уровня и один 21ый.
Пишите в личку.
Но играть не советую. Как тут уже писали — у игры нет золотой середины. Либо ты тратишь на неё 20 часов в сутки и чего-то добиваешься (президентства, богатства, известности и т.п.), либо 2 минуты в день и ты никто — простой «тукликер», цифра в статистике.
Привет! Есть репозиторий https://github.com/diarworld/greenplum-exporter-queries Там конфиги, они не совсем свежие, но большая часть метрик акутальна
Пока одной рукой льем в S3, второй вставляем в GP через мастер в AO h-store таблицы. Максимальная скорость вставки порядка 5-6 гигабайт в минуту, нам пока этого хватает. Постепенно уходим от этого, есть решение, когда мы раз в час с помощью PXF с сегментов подтягиваем данные из S3, несколько источников уже так проинтегрированы, скорость ощутимо выше.
В первую очередь он на тестах ощутимо медленнее работал с GP. Плюс разработка на Clojure+JS, а нас опыта с питоном намного больше. Ну и, насколько поняли, синхронизация с AD(LDAP) - только в платной версии.
Привет!
Архитектурно очень похоже получилось на GPCC. Какие отличия по функционалу?
И можно ли через ADCC делать автоматический pg_resgroup_move_query, если потребление ресурсов у запроса превышает какие-либо значения?
20 - 2 под систему + 10 HDD + 8 SSD
110TB это было с учетом мирроров. Сейчас у нас на ноду 10TB HDD + 10TB SSD, и весь кластер суммарно уже на 440TB вышел. Расточительство хранить сырые данные в GP, нужно укалдывать все 110 TB с компрессией полезными данными ODS/DDS.
В Я.Облаке в 19 году этой фичи не было, да и диски у нас максимального размера - 4TB, т.е. никаких зарезаний по дисковому QoS со стороны самого облака точно не было. Плюс, нужно понимать, что диски в облаке сетевые и живут не рядом с виртуалками и любой запрос в GP (обращение к диску) идет в сеть между гипервизорами и стораджем. Так что тут тесты были нужны, чтобы понять максимальные возможности сети яндекс облака. После этого мы начали запрашивать от Я.облака ускорение дисков, в прошлом году появились NRD диски - прирост производительности составил ~20%. Мы купили производительность за счет снижения надежности. Сейчас же у нас инсталляция живет на выделенных хостах с локальными дисками - там все намного лучше, чем на сетевых и NRD, получили мы в итоге порядка +50% производительности дисков в сравнении с 4TB сетевыми SSD.
Фуллскан - да, но в нашей железной инсталляции мы увидели, что на HDD (шпиндели) диски в RAID10 со скоростью чтения 4ГБ/с запросы работали ощутимо медленнее SSD с той-же максимальной скоростью чтения, но ощутимо большими IOPS. Среднее время выполнения мелких запросов по витринам и справочникам упало с ~16с до ~4c. Плюс хранение pg_catalog на SSD, что повышает общую отзывчивость базы. Сейчас у нас 2 тейблспейса в GP - дефолтный на SSD и теплый на HDD.
6 сетевых дисков в облаке пробовали - прироста не выявили, похоже упирались в сеть между гипервизорами.
Для бизнеса - любая платформа сложная, но я бы не сказал, что текущая имплементация получилась технически сложная. Ну а так, да, бизнес доверяет инженерам, формирует требования, а реализацию оставляет нам.
Сейчас для таких задач у нас есть S3, туда мы сливаем необходимые данные из кафки, а потом уже спарком их обрабатываем и сгружаем в GP.
Основной экономический эффект дают продукты, созданные после появления платформы, т.н.дата-продукты. В больших компаниях внедрение даже крошечных оптимизаций и нововведений может приносить огромную прибыль (экономию). Конкретные цифры называть не могу, но могу сказать, что несколько наших дата-продуктов экономят компании несколько сотен миллионов рублей в год.
Колоночное сжатие есть и в GP =) Все-таки полноценного ANSI https://clickhouse.tech/docs/ru/sql-reference/ansi/ нашим дата-инженерам в клике не хватает, поэтому он не для всех задач подходит. Сейчас тестируем его для быстрых слоев витрин, поделимся выводами, когда закончим
www.last-video.com/wp-content/uploads/2010/02/Emirates-Stadium-Arsenal.jpg
It's not just you! yandex.ru looks down from here.
Пишите в личку.
Но играть не советую. Как тут уже писали — у игры нет золотой середины. Либо ты тратишь на неё 20 часов в сутки и чего-то добиваешься (президентства, богатства, известности и т.п.), либо 2 минуты в день и ты никто — простой «тукликер», цифра в статистике.