Имхо, подавляющая часть потребностей версионирования решается банальным start date / end date, а не затеванием огорода с DV.
С возможностью быстро добавлять новые атрибуты чуть сложнее, но тоже все сложности DV того не стоят. Я скорее соглашусь на решение, где добавить колонку ничего не стоит (условные hbase, parquet) или исходную таблицу заменить view, а внутри сделать join исходной таблицы и таблицы с новыми атрибутами, чем обрекать себя на вечные страдания с DV.
Помню у заказчика был этот blitz, хотели на своем стенде разработки его развернуть, но на тот момент с этим были нюансы. Отрадно, что сейчас на сайте появилась возможность скачать дистрибутив.
Я верно понял, что была тула, которую писал человек, который знал эту особенность Oracle (имхо, вы верно подметили, что эта особенность из-за необходимости поддержки обратной совместимости) и в какой-то момент кто-то другой, уже не знающий этой особенности решил оптимизировать данный тул и убрал дописывание char?
Если все так:
1. Исходный разработчик молодец, но ему стоило написать тест об этом.
2. Разработчик выполнявший рефакторинг решил исправить то, в чем, видимо, сам не особо разбирался
А по итогу во всем обвинили Oracle :-)
Может быть кто-нибудь подскажет BI инструмент, удовлетворяющий следующим требованиям:
Не облако (установка на свои сервера, без доступа в интернет)
Возможность создавать дашборды
Возможность нормально встраивать эти дашборды в своё веб-приложение. Под нормально подразумеваю, что это не iframe, а, например, некая javascript библиотека или REST API или еще что-нибудь подобное.
Умение напрямую работать с БД, желательно через jdbc, не создавая своё промежуточное хранилище внутри BI
Вопросы скорее в воздух, но мало ли у vadsu найдется пара минут свободного времени на ответ:
1. На счет того, что хочется SQL и realtime, но все лежит во всяких Hadoop/Key-Value/NoSQL, а прорабатывались ли такие варианты, как предоставлять SQL через Impala (вместо Key-Value у HBase/Cassandra), а хранение в Kudu, вместо HDFS? Или даже более координально — Yandex ClickHouse?
2. Очень интересно про «Лабиринт», правильно понимаю, что в Key-Value лежит список узлов, а внутри каждого узла уже вся доп информация, которую по нему нашли + список связанных ребер? Если так, то как устроено хранение информации о финансовых связях между организациями, в том смысле, что такие связи порождают не статические ребра, а динамические (сегодня транзакция есть, завтра ее нет, послезавтра снова есть, это одно и тоже ребро или 2 разных?). Агрегируете до достаточно больших периодов, чтобы можно было работать как со статическими ребрами? У пользователей есть возможность запустить какой-нибудь «умный» алгоритм, который проанализирует подграф этого графа начиная с какого-либо узла хотя бы на глубину 2-3 в realtime?
Пока у меня сложилось впечатление, что хадуп начинается там, где есть куча серверов с DAS , при этом суммарный объем обрабатываемых данных не умещается на один такой сервер и по какой то причине нельзя все затолкать в нормальный NAS .
10/100 млн событий это всего или в день? Даже если в день, то тоже не проблема, пусть будет одна таблица и партиции в ней (надеюсь MySQL умеет партиции, если не умеет, то просто один день — одна новая таблица с аналогичной структурой), грузим тоже специализированной тулзой (Oracle sql*loader / PostgreSQL COPY, в MySQL наверное тоже что то такое есть) и дальше смело работаете, как вы выразились «в формате SQL». Ну и соответственно никакие хадупы тут не нужны.
У меня вопрос, все таки на какое железо ориентирован hadoop?
Исходя из личного опыта с задачками, где было много (ну или относительно много) данных, то весь затык всегда случался не на стороне сервера, а на стороне СХД. Условно даже на СХД начального уровня (например, IBM Storwise v3700) можно свободно хранить сотни терабайт данных, но скорость с которой современные магнитные диски выдают данные в разы уступает скорости с которой современные процессора способны переваривать эти данные. И собственно здесь у меня возникает непонимание — как мне поможет кластер серверов с хадупом, если СХД не может угнаться даже за одним более-менее мощным сервером?
Или подразумевается, что это кластер средненьких серверов и на каждом из них пара сотен ГБ встроенного стораджа на SSD и уже они собираются в кластер? Но если так, то при объемах в сотни ТБ можно разориться на железе…
Понятно, остается только мечтать, что может быть когда-нибудь в будущем и в наших краях пройдет достойная Java конференция. Вдруг Екатеринбуржские СберТех, СКБ-Контур, Яндекс и Наумен возьмут и про спонсируют мероприятие, ну а нам до соседей уж грех будет не скататься.
Очень грустно, в этом году не получилось выбраться ни сюда, ни в Мск не получится, а доклады прям хочется послушать. Реквестирую еще одну конференцию где-нибудь на урале (у нас в Перми или в Екатеринбурге).
Я так понимаю цену не озвучат, но было бы очень интересно хотя бы увидеть относительные цены СХД из этого цикла статей. Стоимость самой дешевой из рассмотренных СХД принимаем за единицу, стоимости всех остальных выражаем через нее.
Имхо, подавляющая часть потребностей версионирования решается банальным start date / end date, а не затеванием огорода с DV.
С возможностью быстро добавлять новые атрибуты чуть сложнее, но тоже все сложности DV того не стоят. Я скорее соглашусь на решение, где добавить колонку ничего не стоит (условные hbase, parquet) или исходную таблицу заменить view, а внутри сделать join исходной таблицы и таблицы с новыми атрибутами, чем обрекать себя на вечные страдания с DV.
Помню у заказчика был этот blitz, хотели на своем стенде разработки его развернуть, но на тот момент с этим были нюансы. Отрадно, что сейчас на сайте появилась возможность скачать дистрибутив.
Если все так:
1. Исходный разработчик молодец, но ему стоило написать тест об этом.
2. Разработчик выполнявший рефакторинг решил исправить то, в чем, видимо, сам не особо разбирался
А по итогу во всем обвинили Oracle :-)
1. На счет того, что хочется SQL и realtime, но все лежит во всяких Hadoop/Key-Value/NoSQL, а прорабатывались ли такие варианты, как предоставлять SQL через Impala (вместо Key-Value у HBase/Cassandra), а хранение в Kudu, вместо HDFS? Или даже более координально — Yandex ClickHouse?
2. Очень интересно про «Лабиринт», правильно понимаю, что в Key-Value лежит список узлов, а внутри каждого узла уже вся доп информация, которую по нему нашли + список связанных ребер? Если так, то как устроено хранение информации о финансовых связях между организациями, в том смысле, что такие связи порождают не статические ребра, а динамические (сегодня транзакция есть, завтра ее нет, послезавтра снова есть, это одно и тоже ребро или 2 разных?). Агрегируете до достаточно больших периодов, чтобы можно было работать как со статическими ребрами? У пользователей есть возможность запустить какой-нибудь «умный» алгоритм, который проанализирует подграф этого графа начиная с какого-либо узла хотя бы на глубину 2-3 в realtime?
Исходя из личного опыта с задачками, где было много (ну или относительно много) данных, то весь затык всегда случался не на стороне сервера, а на стороне СХД. Условно даже на СХД начального уровня (например, IBM Storwise v3700) можно свободно хранить сотни терабайт данных, но скорость с которой современные магнитные диски выдают данные в разы уступает скорости с которой современные процессора способны переваривать эти данные. И собственно здесь у меня возникает непонимание — как мне поможет кластер серверов с хадупом, если СХД не может угнаться даже за одним более-менее мощным сервером?
Или подразумевается, что это кластер средненьких серверов и на каждом из них пара сотен ГБ встроенного стораджа на SSD и уже они собираются в кластер? Но если так, то при объемах в сотни ТБ можно разориться на железе…
Ваши предложения по вариантам для нового проекта?в комментарии выше спросили быстрее