Комментарии 14
Это конечно все здорово, вот только у Redshift есть на мой взгляд супер-большой минус, который ставит на этой БД крест по сравнению с аналогами — необоснованно долгое время компиляции запроса. То есть даже простой запрос при первом запуске может выполняться 4-5 секунд, что ИМХО ну совсем несерьезно. Вот тут кстати подробно описано: medium.com/@pingram/redshift-code-compilation-977143576e89. На моём проекте вся инфраструктура на амазоне и казалось логичным взять RedShift для аналитики, но в итоге решили использовать Vertica — ни о чем не жалею.
Верно! Есть такая особенность, может показаться неприятной.
Не буду оправдывать или защищать, Vertica я тоже очень люблю.
Что по поводу бюджета? При примерно одинаковых мощностях, что выходит дороже?
Как решается вопрос с Operations? Обновление версий/maintenance? На себя всё берет вендор?
Не буду оправдывать или защищать, Vertica я тоже очень люблю.
Что по поводу бюджета? При примерно одинаковых мощностях, что выходит дороже?
Как решается вопрос с Operations? Обновление версий/maintenance? На себя всё берет вендор?
При прочих равных Vertica будет дороже, но я серверами не занимаюсь и деталей не скажу. Плюс само собой поддержка сложнее — редшифт из коробки одной кнопкой, а кластер вертики нужно разворачивать + это должно быть минимум 3 ноды для обеспечения кворума.
Но с другой стороны Vertica как мне кажется в функциональном плане намного лучше (тут оговорюсь, что я смотрю со своей программистской колокольни). Вот взять хотя бы драйвер для питона — у редшифта драйвер появился только полгода назад, а до этого для коннекта предлагали использовать постгрешный psycopg2. Всякие ошибки и прочие вещи для Vertica гуглятся проще, ну и в целом довольно большое комьюнити.
Но с другой стороны Vertica как мне кажется в функциональном плане намного лучше (тут оговорюсь, что я смотрю со своей программистской колокольни). Вот взять хотя бы драйвер для питона — у редшифта драйвер появился только полгода назад, а до этого для коннекта предлагали использовать постгрешный psycopg2. Всякие ошибки и прочие вещи для Vertica гуглятся проще, ну и в целом довольно большое комьюнити.
Спасибо за ответ. Примерно так и предполагал. У нас сейчас в команде нет возможности выделить ресурс на полноценный Ops-сопровождение решения.
В Redshift радует то, что это fully managed service. Раз в неделю автоматические обновления, в случае необходимости рестарт кластера 1-й кнопкой, автоматические бэкапы, и всё родное для AWS.
Vertica функциональнее, соглашусь. Если уметь выжать из неё всё. Уже несколько лет назад там были полнотекстовый индекс, in-database ML, сессионизация, pattern-matching по сессиям. И фишка с проекциями конечно супер.
В Redshift радует то, что это fully managed service. Раз в неделю автоматические обновления, в случае необходимости рестарт кластера 1-й кнопкой, автоматические бэкапы, и всё родное для AWS.
Vertica функциональнее, соглашусь. Если уметь выжать из неё всё. Уже несколько лет назад там были полнотекстовый индекс, in-database ML, сессионизация, pattern-matching по сессиям. И фишка с проекциями конечно супер.
Кстати, справедливости ради, хочется именно подчеркнуть, что время на компиляцию требуется только при первом запуске запроса. Все последующие запуски в точности того же запроса происходят без этапа компиляции.
Т.е. при использовании BI-инструментов (читай конструкторов запросов) и преднастроенных дашбордов эффект может быть и незаметен.
Т.е. при использовании BI-инструментов (читай конструкторов запросов) и преднастроенных дашбордов эффект может быть и незаметен.
Ну есть кейсы, когда допустим базой пользуются ребята из отдела аналитики. И пользуются они редко, и тем более из консоли, да и вообще куда им спешить — могут и подождать.
В моем кейсе база нужна, чтобы строить графики/таблицы для пользователей-кастомеров, и тормозить каждый HTTP-запрос веб-сервера на 4-5 секунд как-то совсем не комильфо. Каждая колонка в таблице — это фильтр в интерфейсе. Фильтров много, иногда делаются джойны, параметры запросов все разные. «Прогреть кэш» в данном случае не видится возможным
В моем кейсе база нужна, чтобы строить графики/таблицы для пользователей-кастомеров, и тормозить каждый HTTP-запрос веб-сервера на 4-5 секунд как-то совсем не комильфо. Каждая колонка в таблице — это фильтр в интерфейсе. Фильтров много, иногда делаются джойны, параметры запросов все разные. «Прогреть кэш» в данном случае не видится возможным
Для меня это секунды вообще не вопрос. Не минуты и часы ждать же. А вот кол-во одновременных запросов это действительно проблема.
Потенциально в планах на ближайшие месяцы PoC со Snowflake.
Snowflake отлично работает с JSON — у нас источник MongoDB.
Если получится — будет максимально объективный обзор и сравнение. Подписывайтесь и не пропустите!
Snowflake отлично работает с JSON — у нас источник MongoDB.
Если получится — будет максимально объективный обзор и сравнение. Подписывайтесь и не пропустите!
Около 4 лет назад переехали c Redshift на Snowflake. Тогда Redshift прилично отставал по функционалу. Сейчас выглядит получше, но кажется все еще проигрывает. За это время в основном положительный опыт со Snowflake.
Спасибо, тоже давно поглядываю в сторону Snowflake.
Немного охлаждает пыл необходимость полноценного тестирования, подготовки плана миграции.
Однако мы используем dbt для всей логической модели Хранилища, а dbt отлично интегрирован как с Redshift, так и со Snowflake (и с BigQuery, но его пока не рассматриваем).
Про проект Хранилища Wheely на dbt будет большой отдельный пост!
Немного охлаждает пыл необходимость полноценного тестирования, подготовки плана миграции.
Однако мы используем dbt для всей логической модели Хранилища, а dbt отлично интегрирован как с Redshift, так и со Snowflake (и с BigQuery, но его пока не рассматриваем).
Про проект Хранилища Wheely на dbt будет большой отдельный пост!
Snowflake тема! Он сильно подтолкнул развитие индустрии, и все бросились свои продукты допиливать, но legacy redshift очень сильно тормозит. Вроде как нельзя использовать из России напрямую.
Понимаю что банальный вопрос, но вы рассматривали Clickhouse?
Честно говоря, не рассматривался. Знаю про продукт и примерно сценарии его использования.
Некоторое время назад там не было полноценной поддержки соединения таблиц (JOIN). Предлагалось создавать широкие таблицы и работать с ними.
В Wheely специфика метрик и расчетов предполагает большое количество соединений и сложных, многоуровневых CTE.
В целом симпатизирую Clickhouse, присмотрюсь в будущем, возможно потестируем что-то и найдем применение.
Некоторое время назад там не было полноценной поддержки соединения таблиц (JOIN). Предлагалось создавать широкие таблицы и работать с ними.
В Wheely специфика метрик и расчетов предполагает большое количество соединений и сложных, многоуровневых CTE.
В целом симпатизирую Clickhouse, присмотрюсь в будущем, возможно потестируем что-то и найдем применение.
RA3 крутая штука! До него был затык в максимальном кол-ве но DC2.8XLARGE =126 и соответственно максимальный storage. RA3 позволяет нам уже мыслить PB. Но главная проблема это concurrency для меня. А так люблю Redshift, простой и понятный, делает свою работу, классика жанра.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аналитический движок Amazon Redshift + преимущества Облака