» » » Много, быстро, распределенно: как выбирать In-Memory Data Grid решение

 

Много, быстро, распределенно: как выбирать In-Memory Data Grid решение

Автор: admin от 9-10-2017, 10:40, посмотрело: 100

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

Нил Стивенсон, «Криптономикон»


Много, быстро, распределенно: как выбирать In-Memory Data Grid решение

[i]Фото модуля памяти на магнитных сердечниках в мейнфрейме IBM 1401, использованное в качестве фона на этом изображении, напоминает нам о временах, когда компьютеры были большими, а память — дорогой. Сегодня, как мы узнаем из поста ниже, все поменялось...[/i]



IMDG, гриды, In-Memory Data Grids — как только не называют системы, которые оказались темой поста. И хотя название совершенно правдиво, да и гриды, как инструмент, всё более популярны, многие до сих пор путают их то с системами распределённых кэшей, то с NoSQL-базами данных, а то и вовсе полагают, что «если разместить MySQL на RAM-диске, то получится почти IMDG».



Ещё не так давно решение накапливать информацию, а уже после её обрабатывать, казалось логичным, а появившиеся языки запросов к хранилищам информации выглядели отличным решением: каждая стадия процесса работы с информацией была выделенной и достаточно хорошо контролируемой. Но времена меняются, и сегодня всё чаще бизнес заявляет о желании обрабатывать информацию не «вчерашнюю», а текущую, в буквальном смысле иметь «обработку в онлайне», причём по отношению к информации достаточно больших объёмов. И здесь, хотим мы этого или нет, мы вынуждены искать новые инструменты.



видео этого доклада — прим. автора[/i]). Чем выше уровень consistency и isolation, тем более предсказуемо ведёт себя система и тем проще её программировать. Самая лучшая гарантия — strict serializability (strong-1SR): это сочетание уровня изоляции транзакций serializability и уровня consistency — linearizability. Система, которая предоставляет strict serializability, и есть мечта.



Возможна ли такая система? Нас, конечно, будут интересовать распределённые системы. Тут мы вспомним CAP-теорему и скажем, что в случае CP (CA) такая система возможна и даже существует — Google Spanner. Однако, только Google может позволить себе такую систему — из-за очень высоких требований к инфраструктуре. И то приходится мириться с задержками на репликацию данных между континентами.



Хотелось бы иметь систему, которая гарантирует strict consistency в случае AP, то есть когда возможны сетевые проблемы, а также в случае, если нужно быстрое время отклика. Таких систем нет и быть не может, что показано, например, в PhD Peter Bailis.



Возвращаясь к теме выбора IMDG: задумайтесь, какие гарантии даёт то или иное решение, не нарушают ли рекламные обещания производителя теоретические ограничения распределённых систем? Можно ли положиться на IMDG, если у вас сгорел порт на свитче, или происходит длительная сборка мусора в JVM, или трактор разорвал кабель между вашими DC?



Виктор Гамов (Confluent; ранее HazelCast)



[i]— Так уж повелось, что чуть ли не каждое IMDG-решение позиционирует себя как самое лучшее для пользователей (если не для всех, то для многих). Можно ли в такой теме однозначно говорить о лучшем/худшем?[/i]



Я бы говорил о use case, а не о понятии «лучший/худший». Нужно отталкиваться от моментов, связанных с внутренней архитектурой проекта. IMDG-решения развиваются каждое в своём направлении, и сравнивать их без ответа на вопрос «лучший для своего» — неверно.

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



В любом случае, о гридах нужно говорить с позиции разработчика, и исходить нужно, во-первых, из задачи, которую этот разработчик решает, а во-вторых, из его предыдущего опыта и используемого в проекте стека.



[i]— На рынке много «чисто IMDG»-решений и практически лишь одно (Ignite/GridGain), которое себя позиционирует как нечто большее. Правильно ли говорить в такой ситуации, что для всех решений найдётся своя ниша, или можно сказать, что кто-то технологически ушёл вперед, а кто-то ещё не освоил дополнительные функции?[/i]



Я напомню фразу времен бурного роста Microsoft: «Давайте сконцентрируемся на всем!»

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



IMDG сильны в трёх моментах: хранение данных, вычисления над этими данными и распределённые коммуникации. Остальной функционал добавляется тогда, когда в нём возникает потребность. Думаю, GridGain реализуют некоторые интересные функции, в том числе и с учётом пожеланий заказчиков (например, в рамках своего сотрудничества со СберТехом), в то время как другие IMDG-решения не видят непосредственной необходимости распылять силы на расширение функционала своего продукта.



С другой стороны, бенефиты от такой узкой системы, как IMDG, получают, в первую очередь, разработчики, а не конечные пользователи. И уже разработчики решают, как они воспользуются возможностями, предлагаемыми IMDG, и как им изменить логику работы приложения, чтобы использовать эти возможности. (Ссылка на доклад Виктора на английском языке — прим. автора).



[i]— Долгое время концепция IMDG казалась оторванной от реальности: хранить все данные целиком в памяти было дорого и как-то нерационально, да и приложения работали через интерфейсы, оптимизированные под выборку и обработку аккуратно отобранной части данных. Сегодня IMDG всё чаще используют как некую «серебряную пулю». Можно ли ожидать, что эта технология будет на рынке достаточно долго, что это не очередное модное направление, которое однажды сменится другим?[/i]



Думаю, да. На мой взгляд, стоимость памяти будет падать, стоимость серверов также снижается, скорость связи по сети растёт — если ваша задача требует надёжного хранения больших объёмов данных с быстрым к ним доступом, использование IMDG будет ещё долгое время отличным выбором. Такого рода задачи будут всегда, поэтому гриды как инструмент будут востребованы.



Здесь я могу заметить, что IMDG прекрасно встраивается в схему потоковой обработки данных. Если у нас есть поток информации, и мы хотим делать по нему статистику в реальном времени, то с IMDG данные будут обрабатываться сразу (не сохраняясь, скажем, на дисках — прямо в памяти, но при этом с гарантией сохранности информации, даже при выходе из строя ноды в кластере) и сразу же могут использоваться далее — скажем, выводиться на некий дашборд. При этом, заметьте, нет необходимости сначала загружать данные в некую базу данных (на диск), потом обрабатывать их, перекладывая на диске же, и затем считывать с диска «наружу» — мы всё время держим их в памяти, существенно экономя на перемещении ненужных нам в долговременном хранении данных «туда и обратно».



Будет ли IMDG «серебряной пулей»? Вряд ли: это, как я уже говорил, нишевое решение, но востребованы гриды точно будут.





Обсуждать эту темe можно долго: спорить, соглашаться, холиварить и даже иногда бить в щи… И если первые три варианта можно реализовать в комментах, то за четвертым (хотя и первые три тоже можно будет практиковать) надо куда-то да ехать. Куда? Можно на Java-конференцию Joker 2017 (3-4 ноября, СПб) или на DevOps-конференцию DevOops 2017 (20 октября, СПб), — тут будет, с кем поговорить о хранилищах.

Источник: Хабрахабр

Категория: Железо » Гаджеты

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *