Comments 31
yusman, интересная статья, спасибо. Подскажите, насколько затратно по ресурсам поддерживать этот велосипед под названием Profile Loader?
С учетом специфики вашей работы не возникало ли серьезных проблем, связанных с такой реализацией переноса данных в реляционную СУБД?
И последний вопрос — неужели нет готовых коммерческих решений? Что сподвигло вас самостоятельно разработать механизм трансфера?
С учетом специфики вашей работы не возникало ли серьезных проблем, связанных с такой реализацией переноса данных в реляционную СУБД?
И последний вопрос — неужели нет готовых коммерческих решений? Что сподвигло вас самостоятельно разработать механизм трансфера?
Разработкой и основной поддержкой Profile Loader занимается один человек, при этом, это не основной его функционал. В целом система достаточно надежная и понятная в обслуживании, при этом работает достаточно быстро. Серьезных проблем с ней у нас не было.
С коммерческими продуктами все сложно, единственное решение, существовашее на рынке, нас не устроило по причине невозможности репликации вычисляемых полей, а в них как раз то и хранится полезная для аналитики информация.
С коммерческими продуктами все сложно, единственное решение, существовашее на рынке, нас не устроило по причине невозможности репликации вычисляемых полей, а в них как раз то и хранится полезная для аналитики информация.
Назвал иерархические СУБД NoSQL и всё сразу стало стильно модно молодежно.
Вряд ли корректно называть иерархические СУБД NoSQL, что изначально означало Not Only SQL. Что как бы говорит о следующем шаге, о дополнительных возможностях и снятии ограничений наложенных реляционной моделью. Унаследованные иерархические СУБД — это, всё же, немного не то. Да и класс NoSQL гораздо шире.
Вряд ли корректно называть иерархические СУБД NoSQL, что изначально означало Not Only SQL. Что как бы говорит о следующем шаге, о дополнительных возможностях и снятии ограничений наложенных реляционной моделью. Унаследованные иерархические СУБД — это, всё же, немного не то. Да и класс NoSQL гораздо шире.
Спорить конечно на эту тему можно бесконечно, но по факту в современных NoSQL СУБД структуры примерно такие же, что и в старых, только названы по другому — JSON, Objects store и т.д… Что-то дает больше удобства, что-то большей гибкости, но всегда находится компропис и новые проблемы. История циклична.
Мы постарались описать только подход, его можно попробовать применить и на другие NoSQL СУБД, на какие конкретно — совершенно не важно, буть то Mongo или, например, DocumentDB.
Мы постарались описать только подход, его можно попробовать применить и на другие NoSQL СУБД, на какие конкретно — совершенно не важно, буть то Mongo или, например, DocumentDB.
Назвал иерархические СУБД NoSQL и всё сразу стало стильно модно молодежно
NoSQL это не только иерархические СУБД. Тот же Redis можно назвать NoSQL, что не сделает его иерархической СУБД. Если мы конечно не будем вдаваться в демагогию и называть СУБД типа Ключ-Значение частным случаем иерархической СУБД с одним уровнем вложенности.
NoSQL изначально означало «No SQL». Это уже потом появились альтернативные расшифровки, вроде «Not only SQL», «No! SQL» и так далее.
Вот, например, Мартин Фаулер в 2012 году предлагает расшифровку «Not only SQL», сравнивая с давно устоявшейся «No SQL».
http://martinfowler.com/bliki/NosqlDefinition.html.
Там же Фаулер приводит общие характеристики таких NoSQL СУБД:
Как минимум 1,2 и 5 условиям GT.M удовлетворяет. Так что, по-моему, вполне корректно называть GT.M NoSQL СУБД.
Фаулер, конечно, не истина в последней инстанции.
Вот, например, Мартин Фаулер в 2012 году предлагает расшифровку «Not only SQL», сравнивая с давно устоявшейся «No SQL».
http://martinfowler.com/bliki/NosqlDefinition.html.
Там же Фаулер приводит общие характеристики таких NoSQL СУБД:
- Not using the relational model (nor the SQL language)
- Open source
- Designed to run on large clusters
- Based on the needs of 21st century web properties
- No schema, allowing fields to be added to any record without controls
Как минимум 1,2 и 5 условиям GT.M удовлетворяет. Так что, по-моему, вполне корректно называть GT.M NoSQL СУБД.
Фаулер, конечно, не истина в последней инстанции.
Логическая репликация на триггерах — ок. А нету вот такого же, но с перламутровыми для хадупа?
1. А смысл в этой легаси GT.m?
2. Вы (впрочем, как и большинство) путаете SQL и реляционность. :)
3. Какой вообще смысл в т.н. NoSQL? Это все равно, что в mysql будет 2 поля: первичный ключ и каша из данных. Выборка по первичному ключу и вставки, так как больше нету индексов, должны летать. :)
Или я в чем-то ошибаюсь?
2. Вы (впрочем, как и большинство) путаете SQL и реляционность. :)
3. Какой вообще смысл в т.н. NoSQL? Это все равно, что в mysql будет 2 поля: первичный ключ и каша из данных. Выборка по первичному ключу и вставки, так как больше нету индексов, должны летать. :)
Или я в чем-то ошибаюсь?
1. А смысл в этой легаси GT.m?
Смысл в надежности.(за 8 лет не было серьезных сбоев) и быстроте продукта
2. Вы (впрочем, как и большинство) путаете SQL и реляционность. :)
Уточните пожалуйста, что было перепутано?
3. Какой вообще смысл в т.н. NoSQL? Это все равно, что в mysql будет 2 поля: первичный ключ и каша из данных. Выборка по первичному ключу и вставки, так как больше нету индексов, должны летать. :)
И да и нет. Такие иерархические NoSQL-структуры хороши тем, что можно, например создавать индексы прямо в «поддеревьях», так как не все задачи сводятся с простому получению значения по ключу, присутствуют так же массированные операции.
>Смысл в надежности.(за 8 лет не было серьезных сбоев) и быстроте продукта
Как это достигается? Транзакции пишутся сразу? У меня за 8 лет тоже сбоев не было на mysql. Правда, нагрузок тоже.
>Уточните пожалуйста, что было перепутано?
SQL — это лишь язык запросов, интерфейс доступа, его можно успешно применять и для нереляционных баз.
Вот Сфинкс имеет несколько интерфейсов, в том числе и SQL.
>например создавать индексы прямо в «поддеревьях»
А обновить только один ключ в каше можно? :) Или нужно перезаписывать всю кашу?
Такие индексы будут тупить при обновлении?
Ну и на сколько они эффективны по сравнению с индексом по полю?
Как это достигается? Транзакции пишутся сразу? У меня за 8 лет тоже сбоев не было на mysql. Правда, нагрузок тоже.
>Уточните пожалуйста, что было перепутано?
SQL — это лишь язык запросов, интерфейс доступа, его можно успешно применять и для нереляционных баз.
Вот Сфинкс имеет несколько интерфейсов, в том числе и SQL.
>например создавать индексы прямо в «поддеревьях»
А обновить только один ключ в каше можно? :) Или нужно перезаписывать всю кашу?
Такие индексы будут тупить при обновлении?
Ну и на сколько они эффективны по сравнению с индексом по полю?
Как это достигается? Транзакции пишутся сразу? У меня за 8 лет тоже сбоев не было на mysql. Правда, нагрузок тоже.
Как это достигается сказать сложно, может быть зрелостью решения и отсутствием лишнего функционала, превращающего СУБД в кухонный комбаин?
SQL — это лишь язык запросов, интерфейс доступа, его можно успешно применять и для нереляционных баз.
Вот Сфинкс имеет несколько интерфейсов, в том числе и SQL.
Как правило, SQL натянутый на нереляционные структуры всегда не полноценный, да и сами эти NoSQL-структуры надо предварительно подготавливать каждый раз. Тут же мы один раз мы делаем некий «маппинг» и превращаем наши структуры в удобные таблицы на РСУБД с нормальный SQL, с отсутствием необходимости обучать наших пользователей дополнительным инструментам.
А обновить только один ключ в каше можно? :) Или нужно перезаписывать всю кашу?
Такие индексы будут тупить при обновлении?
Ну и на сколько они эффективны по сравнению с индексом по полю?
Смотрите, если мы обновляем ветку в дереве — обновляется только она, поддеревья не переписываются.
Если обновляется ключ — переписывается новая ветка, но таких операций у нас нет, ибо это не эффективно.
Как правило, SQL натянутый на нереляционные структуры всегда не полноценный
Это уже второй вопрос.
Если движок не позволяет делать группировки/джойны/другое, то это не вина SQL. :)
Это всего лишь язык запросов. :)
Это не сама СУБД.
Это примерно как в чай в большистве случаев добавляют сахар.
Но это не значит, что чай равняется сахару :)
Какой вообще смысл в т.н. NoSQL? Это все равно, что в mysql будет 2 поля: первичный ключ и каша из данных. Выборка по первичному ключу и вставки, так как больше нету индексов, должны летать. :)
Или я в чем-то ошибаюсь?
У разных NoSQL БД есть свои особенности, которых может не быть в SQL базах данных. Например, в Redis есть тип данных сортированное множество (sorted set, zset), позволяющий решать специфичные задачи (например, кэширование) или HyperLogLog — вероятностная структура данных, потребляющая фиксированное количество памяти для подсчёта количества уникальных элементов.
Не нужно думать о NoSQL как о чём-то, что нужно использовать вместо SQL баз данных. Их можно использовать вместе.
Промазал веткой почему-то :)
А не глядели в сторону InterSystems Caché? Ведь, все, что крутится на gt.m, заведется сразу и на Caché?
Есть асинхронное зеркало, для реплики всего на сервер аналитики, без нагрузки на OLTP.
Есть SQLStorage Mapping для «натягивания» SQL- доступа на глобалы, но можно так же из журнала читать.
Есть наконец встроенная BI InterSystems DeepSee MDX based?
Есть асинхронное зеркало, для реплики всего на сервер аналитики, без нагрузки на OLTP.
Есть SQLStorage Mapping для «натягивания» SQL- доступа на глобалы, но можно так же из журнала читать.
Есть наконец встроенная BI InterSystems DeepSee MDX based?
Мне кажется все выше перечисленное нарушает концепцию ребят в части ODS (на Oracle).
А можно детально, что именно нарушает?
В вышеперечисленном необязательно использовать все. Для ODS как раз подойдет асинхронное зеркало и/или SQLStorage Mapping.
А с DeepSee не нужен и ODS (что, конечно, «нарушает»)
В вышеперечисленном необязательно использовать все. Для ODS как раз подойдет асинхронное зеркало и/или SQLStorage Mapping.
А с DeepSee не нужен и ODS (что, конечно, «нарушает»)
Асинхронное зеркало и/или SQL Storage Mapping умеет реплицировать в Oracle?
Спасибо за статью! Интересно.
Пара вопросов.
— Не понял про триггеры. Получается что триггеры можно вешать на CDI?
— Иерархические ну или объектные СУБД удобны «отсутствием» схемы данных (ваш пример про 2 и 22 телефона). Как в этом случае формируется структура таблицы на стороне ODS? И поддерживаете или же думаете реализовывать поддержку репликации DDL? А может это вопрос как раз к механизму создания таблиц аудита на стороне Profile.
Пара вопросов.
— Не понял про триггеры. Получается что триггеры можно вешать на CDI?
— Иерархические ну или объектные СУБД удобны «отсутствием» схемы данных (ваш пример про 2 и 22 телефона). Как в этом случае формируется структура таблицы на стороне ODS? И поддерживаете или же думаете реализовывать поддержку репликации DDL? А может это вопрос как раз к механизму создания таблиц аудита на стороне Profile.
Не понял про триггеры. Получается что триггеры можно вешать на CDI?
Триггеры вешаются только на «физические» значения, но в момент срабатывания этих триггеров вычитаются и CDI.
поддерживаете или же думаете реализовывать поддержку репликации DDL? А может это вопрос как раз к механизму создания таблиц аудита на стороне Profile.
С репликацией DDL все сложно, во-первых GT.m не контролирует структуры глобалов, во-вторых иногда приходится думать как разложить структуры правильно.
Иерархические ну или объектные СУБД удобны «отсутствием» схемы данных (ваш пример про 2 и 22 телефона). Как в этом случае формируется структура таблицы на стороне ODS?
По разному, это как и дополнительное количество больших полей, так и новые таблицы. Тут не все однозначно и зависит уже больше от конечной задачи репликации
В части триггеров, кажется понял. Т.е. CDI получаете уже тогда когда дельту вычитываете?
И ещё. Не сочтите за придирку. Но, можно ли назвать то, что у вас получилось репликацией? По сути у вас просто получился ETL из NoSQL источника (GT.m) в ODS (Oracle)?
И ещё. Не сочтите за придирку. Но, можно ли назвать то, что у вас получилось репликацией? По сути у вас просто получился ETL из NoSQL источника (GT.m) в ODS (Oracle)?
Поправка, результаты CDI не сохраняются в GT.m, они вычисляются во время забора изменений. Но в момент чтения данные в CDI будут консистентны.
Да, можно это и назвать ETL(так как имеем Extract — transform — Load). Но можно и репликацию средствами Oracle GoldenGate или Attunity назвать ETL процессом с натяжкой))) Но почему «репликация»? В будущем мы будем увеличивать «риалтаймовость» системы и надеимся довести ее до нескольких секунд. Сейчас это несколько минут.
Да, можно это и назвать ETL(так как имеем Extract — transform — Load). Но можно и репликацию средствами Oracle GoldenGate или Attunity назвать ETL процессом с натяжкой))) Но почему «репликация»? В будущем мы будем увеличивать «риалтаймовость» системы и надеимся довести ее до нескольких секунд. Сейчас это несколько минут.
Трансформации в Oracle GoldenGate или Attunity это скорее возможность, у вас же трансформации — необходимость :) Но в случае NoSql по другому, я думаю, и быть не может.
Можете потом свои наработки продать Informatica, они назовут это модным словом адаптер (PowerExchange for GT.m) :)
«Риалтаймовость» — это круто! Желаю успехов и удачи в новых релизах! :)
Можете потом свои наработки продать Informatica, они назовут это модным словом адаптер (PowerExchange for GT.m) :)
«Риалтаймовость» — это круто! Желаю успехов и удачи в новых релизах! :)
Sign up to leave a comment.
Как мы NoSQL в «реляционку» реплицировали