Из платных баз данных мы тестировали HP Vertica и Greenplum
Эти СУБД из другого сегмента. Если clickHouse для real-time аналитики(грузим и анализируем одновременно) то эти для такого использования: «загрузили данные, закомитились, проанализировали когда захотели».
Кстати, из приведенных вами запросов вообще не увидел «риалтаймовости» — для исторического анализа real-time особо не нужен.
Парни, привет, отличная статья!
Удивил фидбек по SAP HANA — ожидал от нее большего.
Кстати, почти все сравниваемые СУБД — не особо In-memory.
Кэширование блоков данных(причем на уровне ОС) != in-memory DBMS. Нет гарантий того, откуда эти данные берутся(диск/кеш), что с ними происходит и когда они вывалятся из кэша.
На мой взгляд критерий column-oriented был слишком строгим — можно было попробовать VoltDB например.
Так же не понятно, сколько раз запускался каждый запрос? Exasol умеет умеет оптимизировать запросы и среднее время запуска у него может сильно отличаться от времени первого выполнения.
Разумеется, на рынке есть и другие колоночные СУБД, не использующие разделяемые ресурсы, а также СУБД, поддерживающие MPP, но всеми четырьмя перечисленными свойствами обладает только Vertica.
Статья хоть и интересная, но ее можно было бы назвать «Сравнение велосипеда и автомобиля.» Смотрите, велосипед не надо заправлять и он может ехать быстрее чем машина по лесу!
Но велосипед и авто решают разные задачи.
В любом случае велосипед не даст вам конкурентного доступа, масштабирования и т.д., изменения данных без блокировок и много много другого.
Считаю, что такое сравнение хоть и интересное, но не корректное. Делать категоричные вывод точно не стоит.
При создании PK всегда создается индекс, происходит это не явно.
С номерами паспортов проблема в том, левая часть последовательности чисел меняется реже чем правая(как с номерами телефонов +7915 и т.д. ), что приводит к несбалансированности бинарного дерева индекса. В таких случаях идеально использовать реверсивный индекс.
Поправка, результаты CDI не сохраняются в GT.m, они вычисляются во время забора изменений. Но в момент чтения данные в CDI будут консистентны.
Да, можно это и назвать ETL(так как имеем Extract — transform — Load). Но можно и репликацию средствами Oracle GoldenGate или Attunity назвать ETL процессом с натяжкой))) Но почему «репликация»? В будущем мы будем увеличивать «риалтаймовость» системы и надеимся довести ее до нескольких секунд. Сейчас это несколько минут.
Не понял про триггеры. Получается что триггеры можно вешать на CDI?
Триггеры вешаются только на «физические» значения, но в момент срабатывания этих триггеров вычитаются и CDI.
поддерживаете или же думаете реализовывать поддержку репликации DDL? А может это вопрос как раз к механизму создания таблиц аудита на стороне Profile.
С репликацией DDL все сложно, во-первых GT.m не контролирует структуры глобалов, во-вторых иногда приходится думать как разложить структуры правильно.
Иерархические ну или объектные СУБД удобны «отсутствием» схемы данных (ваш пример про 2 и 22 телефона). Как в этом случае формируется структура таблицы на стороне ODS?
По разному, это как и дополнительное количество больших полей, так и новые таблицы. Тут не все однозначно и зависит уже больше от конечной задачи репликации
Как это достигается? Транзакции пишутся сразу? У меня за 8 лет тоже сбоев не было на mysql. Правда, нагрузок тоже.
Как это достигается сказать сложно, может быть зрелостью решения и отсутствием лишнего функционала, превращающего СУБД в кухонный комбаин?
SQL — это лишь язык запросов, интерфейс доступа, его можно успешно применять и для нереляционных баз.
Вот Сфинкс имеет несколько интерфейсов, в том числе и SQL.
Как правило, SQL натянутый на нереляционные структуры всегда не полноценный, да и сами эти NoSQL-структуры надо предварительно подготавливать каждый раз. Тут же мы один раз мы делаем некий «маппинг» и превращаем наши структуры в удобные таблицы на РСУБД с нормальный SQL, с отсутствием необходимости обучать наших пользователей дополнительным инструментам.
А обновить только один ключ в каше можно? :) Или нужно перезаписывать всю кашу?
Такие индексы будут тупить при обновлении?
Ну и на сколько они эффективны по сравнению с индексом по полю?
Смотрите, если мы обновляем ветку в дереве — обновляется только она, поддеревья не переписываются.
Если обновляется ключ — переписывается новая ветка, но таких операций у нас нет, ибо это не эффективно.
Смысл в надежности.(за 8 лет не было серьезных сбоев) и быстроте продукта
2. Вы (впрочем, как и большинство) путаете SQL и реляционность. :)
Уточните пожалуйста, что было перепутано?
3. Какой вообще смысл в т.н. NoSQL? Это все равно, что в mysql будет 2 поля: первичный ключ и каша из данных. Выборка по первичному ключу и вставки, так как больше нету индексов, должны летать. :)
И да и нет. Такие иерархические NoSQL-структуры хороши тем, что можно, например создавать индексы прямо в «поддеревьях», так как не все задачи сводятся с простому получению значения по ключу, присутствуют так же массированные операции.
Спорить конечно на эту тему можно бесконечно, но по факту в современных NoSQL СУБД структуры примерно такие же, что и в старых, только названы по другому — JSON, Objects store и т.д… Что-то дает больше удобства, что-то большей гибкости, но всегда находится компропис и новые проблемы. История циклична.
Мы постарались описать только подход, его можно попробовать применить и на другие NoSQL СУБД, на какие конкретно — совершенно не важно, буть то Mongo или, например, DocumentDB.
Разработкой и основной поддержкой Profile Loader занимается один человек, при этом, это не основной его функционал. В целом система достаточно надежная и понятная в обслуживании, при этом работает достаточно быстро. Серьезных проблем с ней у нас не было.
С коммерческими продуктами все сложно, единственное решение, существовашее на рынке, нас не устроило по причине невозможности репликации вычисляемых полей, а в них как раз то и хранится полезная для аналитики информация.
Отличная статья.
Но у Elastic или Sphinx есть дополнительное преимущество: в случае сбоя не получим неконсистентные данные между «словарем» и «индексом».
Расскажите, пожалуйста, с какими проблемами столкнулись, при работе с СУБД?
Возможно и никогда. Если вас всё устраивает по цене и производительности, то не надо уходить с облака.
Считайте и исследуйте этот вопрос самостоятельно. Если вы аналитическая компания, то для вас данные — это ваш хлеб. Я просто не могу дать вам совет в стиле «Если вы перевалите за XX ТБ — срочно переходите на Y». Очень много зависит от вашей специфики.
Опять же, крупные банки, фин. организации и т.д. врядли будут доверять свои данные левым компаниям, при том, что выигрыша по цене может даже и не быть, либо он будет минимальным — надо считать.
Эти СУБД из другого сегмента. Если clickHouse для real-time аналитики(грузим и анализируем одновременно) то эти для такого использования: «загрузили данные, закомитились, проанализировали когда захотели».
Кстати, из приведенных вами запросов вообще не увидел «риалтаймовости» — для исторического анализа real-time особо не нужен.
Удивил фидбек по SAP HANA — ожидал от нее большего.
Кстати, почти все сравниваемые СУБД — не особо In-memory.
Кэширование блоков данных(причем на уровне ОС) != in-memory DBMS. Нет гарантий того, откуда эти данные берутся(диск/кеш), что с ними происходит и когда они вывалятся из кэша.
На мой взгляд критерий column-oriented был слишком строгим — можно было попробовать VoltDB например.
Так же не понятно, сколько раз запускался каждый запрос? Exasol умеет умеет оптимизировать запросы и среднее время запуска у него может сильно отличаться от времени первого выполнения.
Что в итоге-то выбрали?
Такие есть — Greenplum, Aster, Kudu и т.п.
Но велосипед и авто решают разные задачи.
В любом случае велосипед не даст вам конкурентного доступа, масштабирования и т.д., изменения данных без блокировок и много много другого.
Считаю, что такое сравнение хоть и интересное, но не корректное. Делать категоричные вывод точно не стоит.
С номерами паспортов проблема в том, левая часть последовательности чисел меняется реже чем правая(как с номерами телефонов +7915 и т.д. ), что приводит к несбалансированности бинарного дерева индекса. В таких случаях идеально использовать реверсивный индекс.
Да, можно это и назвать ETL(так как имеем Extract — transform — Load). Но можно и репликацию средствами Oracle GoldenGate или Attunity назвать ETL процессом с натяжкой))) Но почему «репликация»? В будущем мы будем увеличивать «риалтаймовость» системы и надеимся довести ее до нескольких секунд. Сейчас это несколько минут.
Триггеры вешаются только на «физические» значения, но в момент срабатывания этих триггеров вычитаются и CDI.
С репликацией DDL все сложно, во-первых GT.m не контролирует структуры глобалов, во-вторых иногда приходится думать как разложить структуры правильно.
По разному, это как и дополнительное количество больших полей, так и новые таблицы. Тут не все однозначно и зависит уже больше от конечной задачи репликации
Как это достигается сказать сложно, может быть зрелостью решения и отсутствием лишнего функционала, превращающего СУБД в кухонный комбаин?
Как правило, SQL натянутый на нереляционные структуры всегда не полноценный, да и сами эти NoSQL-структуры надо предварительно подготавливать каждый раз. Тут же мы один раз мы делаем некий «маппинг» и превращаем наши структуры в удобные таблицы на РСУБД с нормальный SQL, с отсутствием необходимости обучать наших пользователей дополнительным инструментам.
Смотрите, если мы обновляем ветку в дереве — обновляется только она, поддеревья не переписываются.
Если обновляется ключ — переписывается новая ветка, но таких операций у нас нет, ибо это не эффективно.
Смысл в надежности.(за 8 лет не было серьезных сбоев) и быстроте продукта
Уточните пожалуйста, что было перепутано?
И да и нет. Такие иерархические NoSQL-структуры хороши тем, что можно, например создавать индексы прямо в «поддеревьях», так как не все задачи сводятся с простому получению значения по ключу, присутствуют так же массированные операции.
Мы постарались описать только подход, его можно попробовать применить и на другие NoSQL СУБД, на какие конкретно — совершенно не важно, буть то Mongo или, например, DocumentDB.
С коммерческими продуктами все сложно, единственное решение, существовашее на рынке, нас не устроило по причине невозможности репликации вычисляемых полей, а в них как раз то и хранится полезная для аналитики информация.
Но у Elastic или Sphinx есть дополнительное преимущество: в случае сбоя не получим неконсистентные данные между «словарем» и «индексом».
Расскажите, пожалуйста, с какими проблемами столкнулись, при работе с СУБД?
Считайте и исследуйте этот вопрос самостоятельно. Если вы аналитическая компания, то для вас данные — это ваш хлеб. Я просто не могу дать вам совет в стиле «Если вы перевалите за XX ТБ — срочно переходите на Y». Очень много зависит от вашей специфики.
Опять же, крупные банки, фин. организации и т.д. врядли будут доверять свои данные левым компаниям, при том, что выигрыша по цене может даже и не быть, либо он будет минимальным — надо считать.