Comments 15
Добрый день. В Сбербанк не используется Vertica. Данная статья является продолжением MeetUp, на котором рассказывали про СУБД, которые применяются для промышленных хранилищ данных.
Привет. Можно-ли ознакомиться со статьями про другие СУБД о которых речь шла на MeetUp?
А те, кто хочет попробовать колоночную СУБД, но не хочет платить за вертику, можно порекомендовать яндексовый ClickHouse
Что касаемо попробовать — Vertica тоже на первых порах бесплатная. В остальном — нужно сравнивать.
Самый главный минус open source решений — никто не несет ответственность в случае потери данных. Кроме того, как правило, бывают сложности с документацией и поддержкой.
Самый главный минус open source решений — никто не несет ответственность в случае потери данных. Кроме того, как правило, бывают сложности с документацией и поддержкой.
Вертика есть и платная, по крайней мере если размер БД станет больше если мне не изменяет память 10 ТБ, но могу ошибаться+там есть разные фичи именно при платной лицензии
Тут описание бесплатной версии.
Благодарю, да ограничение в 1 ТБ, а не в 10 ТБ, я ошибся, правда что такое «полуструктурированные данные» пока не ясно-можете описать из Вашего опыта что это имеется в виду?
Данный термин в оригинале звучит как «semi-structured». Более детально описано в разделе Vertica flexible tables тут.
понятно-это и есть неполно структурированные данные, кот обертываются как-то и к ним можно обращаться как к структурированным данным. Подобные вещи есть и в других СУБД для xml, json, иерархическим структурам и т д и т п
На небольших данных отработает быстро, но с ростом кол-ва обрабатываемых данных для анализа подобные преобразования будут приводить все к большим ожиданиям и повышению требований к ресурсам. Лучше стараться использовать для аналитики такой формат хранения данных, чтобы было возможно быстро эти данные извлекать (естественное хранение). Но увы унификация здесь неуместна. Можно использовать кубы для агрегаций-это пока один из самых эффективных способов для аналитики, где данных обрабатывается очень много (порядка сотен ГБ или неск ТБ и более). В любом случае даже если не кубы, то хранилище данных для анализа придется готовить заранее и НПД (неполно структурированные данные или NoSQL еще называют) не всегда хороший подход в этом. Хотя как конечная обработка вполне уместно-напр вытащить идентификаторы документов, отвечающие определенным критериям, а затем уже по этим идентификаторам вытащить и сами документы-как то так, грубо, но в простом приближении
На небольших данных отработает быстро, но с ростом кол-ва обрабатываемых данных для анализа подобные преобразования будут приводить все к большим ожиданиям и повышению требований к ресурсам. Лучше стараться использовать для аналитики такой формат хранения данных, чтобы было возможно быстро эти данные извлекать (естественное хранение). Но увы унификация здесь неуместна. Можно использовать кубы для агрегаций-это пока один из самых эффективных способов для аналитики, где данных обрабатывается очень много (порядка сотен ГБ или неск ТБ и более). В любом случае даже если не кубы, то хранилище данных для анализа придется готовить заранее и НПД (неполно структурированные данные или NoSQL еще называют) не всегда хороший подход в этом. Хотя как конечная обработка вполне уместно-напр вытащить идентификаторы документов, отвечающие определенным критериям, а затем уже по этим идентификаторам вытащить и сами документы-как то так, грубо, но в простом приближении
имел в виду под «естественным» к запросу, который делается, чтобы минимизировать кол-во тяжеловестных операций (соединения, преобразования, сериализация/десериализация и т д, и т п).
А вообще, для записи для приложений удобно оперировать НСД (json, xml и т д), чтобы уменьшить кол-во блокировок и обеспечить атомарность и не мучаться с транзакциями. Хотя это не всегда и не везде можно сделать. А уже для аналитики ETL-процессы преобразуют эти данные в естественные данные для аналитики (напр, теже кубы или другие реляционные или нет данные)
А вообще, для записи для приложений удобно оперировать НСД (json, xml и т д), чтобы уменьшить кол-во блокировок и обеспечить атомарность и не мучаться с транзакциями. Хотя это не всегда и не везде можно сделать. А уже для аналитики ETL-процессы преобразуют эти данные в естественные данные для аналитики (напр, теже кубы или другие реляционные или нет данные)
Для каждой задачи есть своё решение. Косить молотком траву можно, но по меньшей мере, неэффективно.
Если полуструктурированной информации становится много, а работаем мы с ней, как со структурированной, то логично её разобрать, структурировать, гранулировать соответствующим задаче образом.
Если зашла речь о кубах… Кубы SSAS очень неплохая штука, но есть нюанс — процессинг. Коррекция данных задним числом может крепко нас озадачить. Процессить все партиции в больших кубах бывает очень дорого. Если бизнес-пользователь привык использовать в качестве клиента Excel, то можно в качестве первичного хранилища использовать Vertica, на нем мы производим основную работу ad-hoc и т.п. Рядом делаем автономное хранилище MOLAP с источником Vertica. Таким образом получим еще один уровень отказоустойчивости (если положим кластер Vertica или вынуждены будем его остановить для обслуживания полностью) аналитика на кубах будет доступна.
Нужно рассматривать Vertica, как часть архитектуры, а не заменитель всего. Vertica сама не решит все проблемы, она только инструмент. Импровизируйте
Если полуструктурированной информации становится много, а работаем мы с ней, как со структурированной, то логично её разобрать, структурировать, гранулировать соответствующим задаче образом.
Если зашла речь о кубах… Кубы SSAS очень неплохая штука, но есть нюанс — процессинг. Коррекция данных задним числом может крепко нас озадачить. Процессить все партиции в больших кубах бывает очень дорого. Если бизнес-пользователь привык использовать в качестве клиента Excel, то можно в качестве первичного хранилища использовать Vertica, на нем мы производим основную работу ad-hoc и т.п. Рядом делаем автономное хранилище MOLAP с источником Vertica. Таким образом получим еще один уровень отказоустойчивости (если положим кластер Vertica или вынуждены будем его остановить для обслуживания полностью) аналитика на кубах будет доступна.
Нужно рассматривать Vertica, как часть архитектуры, а не заменитель всего. Vertica сама не решит все проблемы, она только инструмент. Импровизируйте
Ну не стоит сравнивать CH с Vertica… В КХ вы скорее всего только логи будете лить и проектировать таблицы со справочниками в виде звезды, а после привыкать к движкам и костыльному языку запросов…
Отличная статья! Все никак не мог своего коллегу убедить еще 3 года назад написать про эту СУБД (сам он с ней работает уже давно-как только в России появилась наверное).
Однако, есть и не полностью раскрытые моменты. Например, что понимается в статье про «полуструктурированные данные»? (ведь данные либо структурированы, либо неполно структурированы)-имелось в виду про неполно структурированные данные или если нет, то прошу описать по подробнее. Также в будущем хорошо бы провести сравнение этой СУБД с аналитическими решениями других СУБД (MS SQL Server, Oracle и т д).
Однако, есть и не полностью раскрытые моменты. Например, что понимается в статье про «полуструктурированные данные»? (ведь данные либо структурированы, либо неполно структурированы)-имелось в виду про неполно структурированные данные или если нет, то прошу описать по подробнее. Также в будущем хорошо бы провести сравнение этой СУБД с аналитическими решениями других СУБД (MS SQL Server, Oracle и т д).
Sign up to leave a comment.
А нам все «вертикально» — СУБД Vertica