Имхо, подавляющая часть потребностей версионирования решается банальным 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 и уже они собираются в кластер? Но если так, то при объемах в сотни ТБ можно разориться на железе…
Ваши предложения по вариантам для нового проекта?в комментарии выше спросили быстрее