Всем привет! Возможно, вы знаете, что 20-21 июня в Амстердаме пройдет In-Memory Computing Summit 2017 – Europe. Все детали тут.



Мероприятие, ставшее уже традиционным в США, с этого года также будет ежегодно собирать экспертов из Европы и Азии на новой европейской площадке. На различных секциях конференции выступят представители компаний ING, Intel, Tata Consultancy Services, The Glue, Redis Labs, ScaleOut Software и WSO2.

У меня есть несколько бесплатных билетов, которыми я с удовольствием поделюсь с вами.
Напишите мне на почту mkuznetsov@gridgain.com или в личные сообщения на Хабре. От вас — ФИО и название компании на английском языке, адрес электронной почты и мобильный телефон.

Приезжайте, будет круто!

В мае вышла новая мажорная версия Apache Ignite — распределенной платформы, оптимизированной для работы с оперативной памятью, которая объединяет в себе хранилище вида ключ-значение с SQL99-совместимой базой данных, предлагая полную ACID-совместимость, высокую доступность, а также близкое к линейному масштабирование с нескольких узлов до тысяч, которые могут размещаться на собственном оборудовании либо в облаке. Ядро Apache Ignite написано на Java, но платформа, помимо экосистемы Java, поддерживает нативную интеграцию с приложениями на .NET и C++.

Apache Ignite эластично масштабируется в рамках одного или нескольких геораспределенных кластеров, предоставляя гибко настраиваемое шардирование и автоматическую ребалансировку при динамическом добавлении или удалении узлов, обеспечивая прозрачный и быстрый доступ к данным и вычислениям путем использования собственного API либо классического SQL.

В версии 2.0 были значительно переработаны многие вещи «под капотом», следствием стала возможность реализации ряда значительных функциональных изменений, часть из которых заметна уже сейчас, а часть появится в ближайших версиях.

Забегая вперед, мы будем проводить 2 мероприятия, которые связаны с Apache Ignite, подробнее о них можно прочитать в конце статьи.

Давным давно, когда деревья компьютеры были большими, а процессоры одноядерными, все приложения запускались в один поток и не испытывали сложностей синхронизации.

Современные же приложения стремятся использовать все имеющиеся ресурсы, в частности, все доступные CPU.

К сожалению, использовать стандартные структуры данных при многопоточной обработке не представляется возможным, поэтому в Java 5 появились потокобезопасные структуры данных,
т.е. функционирующие исправно, при использовании из нескольких потоков одновременно, и расположились они в пакете java.util.concurrent.

Однако, не взирая на всю технологическую мощь, заложенную в пакет java.util.concurrent, обработка информации потокобезопасными коллекциями возможна лишь в рамках одного компьютера, а это порождает проблему масштабируемости.

А что если нужно, в реальном времени, обрабатывать информацию о 100 миллионах клиентов,
когда датасет занимает 100Тб, а каждую секунду нужно совершить 100+ тысяч операций?
Вряд ли это возможно, даже на самом крутом современном железе, а если и возможно — только представьте себе его стоимость!

Намного дешевле добиться такой же вычислительной мощности объединив множество обычных компьютеров в кластер.

Остается лишь вопрос межкомпьютерного взаимодействия привычными средствами, схожими по API с потокобезопасными коллекциями из пакета java.util.concurrent и дающими те же гарантии, но не на одном компьютере, а на всем кластере.

В последнее время имена GridGain и Apache Ignite нередко мелькают в интернетах. Однако, судя по комментариям (например, здесь), мало кто понимает, что же это за продукт и с чем его едят.

В этой статье я попытаюсь доступным языком объяснить, и на примерах кода показать, что умеет Apache Ignite.

Очередные Java-конференции JBreak и JPoint прошли на «ура». Здешние доклады всегда имеют резонанс, но многим запомнилось и кое-что ещё.

Буклет GridGain. Задачки про Грефа и Балмера, белорусского программиста с ведром картошки и, конечно, нетривиальное соблазнение тестировщицы Клавдии продолжают публиковать на различных ресурсах на радость автору, и многие уже даже не знают, каков их источник.

Прим. Переводчика. Статья может быть интересна архитекторам и разработчикам, планирующим построение решения на основе микросервисов, либо ищущим способы оптимизации текущего решения, особенно если работа идет с большими объемами данных. Перевод сделан на основе части 1 и части 2 цикла статей о микросервисах на Apache Ignite. Предполагается общее знакомство с экосистемой Java (Apache Ignite работает также с .NET, C++, а через REST и с другими языками, но примеры в статье будут апеллировать к Java), рекомендуется наличие базового знания Spring.

Сегодня микросервисная архитектура — это один из наиболее популярных подходов, на основе которого многие компании строят свои решения. Одно из ключевых преимуществ этого подхода — то, что он предполагает разделение решения на набор слабо связанных компонентов — микросервисов, — каждый из которых может иметь собственный жизненный и релизный циклы, команду разработки и т.д. У этих компонентов всегда есть хотя бы один механизм обмена данными, посредством которого микросервисы взаимодействуют друг с другом. Более того они могут создаваться с использованием разных языков и технологий, наиболее подходящих конкретному модулю системы.

Если вы используете решения на основе микросервисной архитектуры там, где есть высокая нагрузка и необходимо работать с активно растущими массивами данных, скорее всего, вы сталкивались или столкнетесь с проблемами классических подходов: