Я участвую в переделке системы на мейнфрейме с кодом на Коболе на современные микросервисы на Котлине.
Код написан 25 лет назад, никто толком не понимает как он работает. Например, есть 70+ одинаковых job-ов, которые отличаются только одним числовым параметром... Почему сделали так? Тайна покрытая мраком, но никто даже не хочет это дело отрефакторить на одну джобу + файл с параметрами, так как все боятся трогать, типа работает - не трогай.
В коде джобов повсеместно встрчаются проверки условий для которых уже нет значений в базе DB2 и никто их не рефакторит по той же причине.
Логика этих джобов весьма запутанная и построенная на пакетном принципе типа в час Х запускается первая джоба, выгружает файл, в час Х+N минут запускается следующая, которая его фильтрует и сортирует и порождает новый файл, и так далее...
Причем для обработки засасываюся таблицы с сотнями милллионов строк, а по итогу после всех фильтраций и обработок на выходе получается файл в нескольо тысяч строк.
Мы когда пару джобов переписали с мейнфрема на Кафку + No SQL базу, оказалось что по факту там несколько тысяч обновлений в день и современные микросервисы это процессят моментально.
И все это движется медленно и печально, так как расковырять и понять код на Коболе местами затруднительно, зачастую джобы в несколько сот строк на коболе превращаются в десяток строк на котлине (после выкидывания всех археологический отложений)...
И мы еще только в начале пути, потом будет весьма нетривиальная задача сверить работу новой и старой систем...
На мой взгляд всем у кого системы на Коболе, с него надо уходить на современные технологи.
Может где то и есть "башни из слоновй кости" в которых написаны идеальные джобы на Коболе которые еще 50 лет будут "выполнять свои бизнес-функции"... но то что я вижу в реальности - это груды костылей, индусский код и отстуствие понимания как это все работает.
В некоторых сценариях — можно заменить Apache Spark.
В некоторых сценариях — можно использовать совместно с Apache Spark.
Обычно в Apache Ignite данные закачивают для дальнейшей обработки.
Зачем в личку? Давайте сюда. Насколько я знаю — вполне там нормальный SQL.
Единственно (до версии 1.7) для join-ов надо было данные колокейтить.
Да и в 1.7 их желательно колокейтить, так как в этом случае перфоманс максимальный.
Умеет ли оно выполнять распределенные SQL запросы?
Умеет. Пока только select-ы. Но над DML идет активная работа.
А если сравнить с Spark/Storm/Flink/Hawk?
Про Spark — может быть как замена Spark в некоторых условиях, а может работать как «ускоритель» Spark путем предоставления специального IgniteRDD которое лежит в памяти и может переиспользоваться.
Есть интеграция со Spark & Hadoop.
Есть SQL поверх NoSql данных.
Есть IGFS — in-memory реализация HDFS, которая может как сама по себе работать, так и проксировать / кешировать HDFS.
Ну и MapReduce тоже есть и всякое еще сверху.
Пример на моей текущей работе.
Нашли «ОЧЕНЬ ЖИРНОГО» клиента, но надо выиграть тендер у конкурентов.
Вот тут вся команда на месяц засела оптимизировать код. :)
Иначе тендер не выиграть.
А конкретно в вашем случае — докупить железо + минимальный прогон через профайлер, что бы уж совсем тупые ошибки отловить.
При игре в монетку как раз вероятность того что один из игроков будет в выигрыше, а другой в проигрыше как раз выше.
Читаем тут ищем абзац начинающийся с «Распределение арксинуса связано со случайным блужданием.» и читаем текст с пояснением ниже.
unit kaGarbageCollector;
interface
{$REGION 'interface uses'}
uses
// Стандартные модули:
Generics.Collections;
{$ENDREGION}
type
///<summary> Класс позволяющий упростить освобождение памяти.</summary>
TkaGarbageCollector = class
public
const
DEFAULT_TAG = 'DEFAULT_TAG';
private
items: TDictionary<TObject, string>;
public
constructor Create();
destructor Destroy; override;
///<summary> Добавить элемент в список и вернуть свежедобавленный элемент.</summary>
function add<T:class>(item: T): T; overload;
///<summary> Добавить помеченый элемент в список и вернуть свежедобавленный элемент.</summary>
function add<T:class>(const tag: string; item: T): T; overload;
/// <summary> Произвести сборку мусора с указанной меткой. </summary>
procedure gc(const tag: string);
end;
implementation
{$REGION 'TGarbageList'}
constructor TkaGarbageCollector.Create();
begin
items := TObjectDictionary<TObject, string>.Create([doOwnsKeys]);
end;
destructor TkaGarbageCollector.Destroy;
begin
items.free();
inherited Destroy;
end;
function TkaGarbageCollector.add<T>(item: T): T;
begin
result := add(DEFAULT_TAG, item);
end;
function TkaGarbageCollector.add<T>(const tag: string; item: T): T;
begin
items.add(item, tag);
result := item;
end;
procedure TkaGarbageCollector.gc(const tag: string);
var key: TObject;
item: TPair<TObject, string>;
gcList: TList<TObject>;
begin
gcList := TList<TObject>.Create();
try
for item in items do
begin
if (item.Value = tag) then
gcList.add(item.Key);
end;
for key in gcList do
items.remove(key);
finally
gcList.free();
end;
end;
{$ENDREGION}
Его можно применять начиная с Delphi 2009, так как он использует generics.
Это ТАК и есть. Руководство СФУ чуть ли не открытым текстом дало понять — не отчислять никого, только если совсем пропал с радаров. Но причина — не поиск себя, а подушевое финансирование, т.е. от кол-ва студентов зависит кол-во денег и это в корне неправильно.
У нас в Красноярске в СФУ студенты практически болт положили на учебу, измором берут препода, приходя на пересдачи по 5-8 раз.
Микросервисы они гораздо меньше чем джобы на мейнфрейме и их проще изменять независимо друг от друга (вплоть до переписывания на другом языке).
И да, на мейнфрейме толком нету стеджинга, есть дев и прод.
А на микросервисах будет и дев и стейджинг и прод, что позволит вносить изменения более безопасно.
Ну и найти спеца на Котлин/Джаву попроще чем на Кобол.
Но все это не исключает "человеческий" фактор и есть нехилый шанс, что все опять пойдет по тем же рельсам - "дописывания костылей сбоку".
Время покажет.
Я участвую в переделке системы на мейнфрейме с кодом на Коболе на современные микросервисы на Котлине.
Код написан 25 лет назад, никто толком не понимает как он работает. Например, есть 70+ одинаковых job-ов, которые отличаются только одним числовым параметром... Почему сделали так? Тайна покрытая мраком, но никто даже не хочет это дело отрефакторить на одну джобу + файл с параметрами, так как все боятся трогать, типа работает - не трогай.
В коде джобов повсеместно встрчаются проверки условий для которых уже нет значений в базе DB2 и никто их не рефакторит по той же причине.
Логика этих джобов весьма запутанная и построенная на пакетном принципе типа в час Х запускается первая джоба, выгружает файл, в час Х+N минут запускается следующая, которая его фильтрует и сортирует и порождает новый файл, и так далее...
Причем для обработки засасываюся таблицы с сотнями милллионов строк, а по итогу после всех фильтраций и обработок на выходе получается файл в нескольо тысяч строк.
Мы когда пару джобов переписали с мейнфрема на Кафку + No SQL базу, оказалось что по факту там несколько тысяч обновлений в день и современные микросервисы это процессят моментально.
И все это движется медленно и печально, так как расковырять и понять код на Коболе местами затруднительно, зачастую джобы в несколько сот строк на коболе превращаются в десяток строк на котлине (после выкидывания всех археологический отложений)...
И мы еще только в начале пути, потом будет весьма нетривиальная задача сверить работу новой и старой систем...
На мой взгляд всем у кого системы на Коболе, с него надо уходить на современные технологи.
Может где то и есть "башни из слоновй кости" в которых написаны идеальные джобы на Коболе которые еще 50 лет будут "выполнять свои бизнес-функции"... но то что я вижу в реальности - это груды костылей, индусский код и отстуствие понимания как это все работает.
А еще лучше — проверить код продукта за репорты уязвимостей в которых платят баунти :)
PR в H2 делаются, но там не все так просто, так как не каждый PR полезный Ignite будет полезен H2.
Только детские книги.
Остальные книги занимают мое жизненное пространство :)
С читалки/лопатофона все норм читать.
А не пробовали то же самое на Apache Ignite?
В некоторых сценариях — можно заменить Apache Spark.
В некоторых сценариях — можно использовать совместно с Apache Spark.
Обычно в Apache Ignite данные закачивают для дальнейшей обработки.
Парсер съел теги
Это что означает?
Что теперь я не смогу написать: val s = Text?
Единственно (до версии 1.7) для join-ов надо было данные колокейтить.
Да и в 1.7 их желательно колокейтить, так как в этом случае перфоманс максимальный.
Умеет. Пока только select-ы. Но над DML идет активная работа.
Про Spark — может быть как замена Spark в некоторых условиях, а может работать как «ускоритель» Spark путем предоставления специального IgniteRDD которое лежит в памяти и может переиспользоваться.
Apache Ignite реально супер швейцарский нож — фич целый вагон (большинство опциональны)
Есть интеграция со Spark & Hadoop.
Есть SQL поверх NoSql данных.
Есть IGFS — in-memory реализация HDFS, которая может как сама по себе работать, так и проксировать / кешировать HDFS.
Ну и MapReduce тоже есть и всякое еще сверху.
Интересно, а его за основу можно взять и «подменить» движок и заменить икноки?
Нашли «ОЧЕНЬ ЖИРНОГО» клиента, но надо выиграть тендер у конкурентов.
Вот тут вся команда на месяц засела оптимизировать код. :)
Иначе тендер не выиграть.
А конкретно в вашем случае — докупить железо + минимальный прогон через профайлер, что бы уж совсем тупые ошибки отловить.
Читаем тут ищем абзац начинающийся с «Распределение арксинуса связано со случайным блужданием.» и читаем текст с пояснением ниже.
Его можно применять начиная с Delphi 2009, так как он использует generics.
У нас в Красноярске в СФУ студенты практически болт положили на учебу, измором берут препода, приходя на пересдачи по 5-8 раз.