How to become an author
Search
Write a publication
Pull to refresh

Comments 44

Советую в подобных статьях вот это "Самый простой и ёмкий ответ — это база данных. В основе которой — хранилище "ключ-значение"; грубо говоря, ConcurrentDictionary, в котором данные расположены на нескольких машинах." помещать в шапку. Жутко бесит когда сперва идет простыня о продукте, но даже не понятно о каком :)
В остальном, спасибо.

Total votes 12: ↑10 and ↓2+8
>Плохая новость: нам потребуется установленный Java Runtime 7+. Хорошая новость: с этого момента про Java можно забыть.

чтож не вся статья ф таком стиле;
Плохая новость: мы работаем на винде. Хорошая новость: забейте на это и абстрагируйтесь от ос
Плохая новость: мы работаем с .net. Хорошая новость: забейте на это и абстрагируйтесь от vm
Плохая новость: мы работаем x86. Хорошая новость: забейте на это и абстрагируйтесь от железа
Total votes 10: ↑1 and ↓9-8
Было бы интересно почитать про работу с Ignite из C++.
Total votes 2: ↑2 and ↓0+2

Самое интересное (страшное), что .net ignite запускает jvm внутри себя, и как этот сендвич будет в продакшене работать никакой уверенности нет, в Сбере ж на java его используют, а других компаний использующих его и нет (ну или нет инфы о них)

Total votes 1: ↑0 and ↓1-1

Что значит кроме сбера компаний нет, откуда такие домыслы? Информация в открытом доступе: https://www.gridgain.com/customers/featured-customers


На словах может оно и страшно, две виртуальные машины в одном процессе, но если вдуматься — а что в этом такого? Они никак друг другу не мешают. Зато работает быстро, обмен данными через кусок unmanaged памяти. В продакшене всё хорошо.


Также в планах есть вынесение JVM в отдельный процесс и полноценный тонкий клиент на чистом дотнете.

Total votes 2: ↑2 and ↓0+2
1) А что дает список компаний? Важно то, для чего они применяют Ignite. Можете сказать какие компании используют Ignite как замену классической СУБД на больших данных и высокой нагрузке?
2) К чему относится Ignite исходя из CAP теоремы, к CP или CA?
This comment wasn’t rated yet0
1) Этот вопрос станет актуален, когда выйдет persistence.
2) CP
Total votes 1: ↑1 and ↓0+1
По второму пункту корректнее будет сказать, что оно регулируемо. Можно качнуть в сторону AP, можно в сторону CP.
Total votes 1: ↑1 and ↓0+1
1) Перепутал, да AP и CP соответственно. А за счет чего достигается AP? При этом гарантируется хотябы консистентность в конечном итоге?
2) Скажите, если у меня есть две кэша на разных нодах Partitioned и включен бэкап. Это будет распределенная транзакция? И будут ли атомарно операции записи в кэш и актуализация бэкапа? Оно работает аналогично синхронной репликации?
This comment wasn’t rated yet0

Ну как минимум 2 неуправляемых кучи, 2 GC, 2 stop the world, куча jvm настроек, которые непонятно как отразятся на работе связки.
Лучше не JVM вытаскивать а порт сделать, тогда комьюнити потянется, а так — скрестили 2 технологии в одном процессе.

This comment wasn’t rated yet0
2 кучи, 2 GC

Давайте предметно, какие проблемы вы предвидите?
Обычный .NET код сплошь и рядом дёргает системные API, у которых своя unmanaged куча, и что?


Проблемы тут могут быть в x86 (32 bit), где сильно ограничено адресное пространство. В x64 с этим проблем нет. Но речь идёт о big data, так что 32 бита нас не особо беспокоят.


2 stop the world

Не все GC делают stop the world, это раз. Аллокации в managed heap на стороне Java минимальны, это два. Пользовательские данные хранятся в неуправляемой куче через Unsafe.


порт сделать

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

This comment wasn’t rated yet0
Порт — это перенос сотен тысяч строк нетривиального кода, полный отказ от стандартных механизмов сериализации, и удвоение работы по имплементации и поддержке каждого тикета, раздувание штата.
Обертка — это быстрый подъем функционала, отсутствие дупликации. Ценой некоторых потерь в производительности, которые едва ли видны на фоне сетевого взаимодействия.

Это трейдофф, в котором мы выбрали первое, о чем до сих пор ни разу не пожалели. .NET не только в продакшене бегает, его уже другие вендоры эмбедяд в свои продукты.

С точки зрения комьюнити этот выбор достаточно перпенедикулярен.
Total votes 2: ↑2 and ↓0+2
Также в планах есть вынесение JVM в отдельный процесс и полноценный тонкий клиент на чистом дотнете.

А это не будет затратнее? Добавите целых 2 прослойки сетевого взаимодействия, по 1 на каждой из сторон. Что есть сейчас — очень привлекательно. Тут вообще вопрос в том, что зачем брать отдельным сервисом какое-то хранилище, если его можно использовать прям в этом же процессе, т.е. избавить от оверхеда на сетевой трафик запрос-ответ и инфраструктуру их обслуживания.
Total votes 1: ↑1 and ↓0+1

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

This comment wasn’t rated yet0
Скажите, «вынесение JVM в отдельный процесс» будет единственным вариантом использованиям, или опция запуска в том же процессе останется? Такое ощущение, что для .NET Core Вы в итоге запилите как раз «тонкий клиент», т.к. это проще.
Total votes 1: ↑1 and ↓0+1

Существующая опция останется, это важный сценарий использования, отказываться от него никаких причин нет.


Работа над тонким клиентом уже идёт, он будет доступен в версии 2.4 (конец года).


Обе опции будут поддерживаться под .NET Core 2.0. "Серверный режим" заводится пока только под windows (любая версия уже работает), тонкий клиент работает и под Linux (если взять ночной билд, можно уже сейчас это попробовать: https://myget.org/gallery/apache-ignite-net-nightly).

Total votes 1: ↑1 and ↓0+1
Мы используем Ignite в крупном проекте на Java. Статья совсем не информативная. Это не просто база данных. А in memory data grid (база данных в памяти, не персистент!). Плюс его можно использовать просто как кеш (JCache, Hibernate L2 cache и др. как Hazelcast например). В общем чтобы рассказать про Ignite надо несколько статей и намного другого содержания.
Total votes 3: ↑2 and ↓1+1
чтобы рассказать про Ignite надо несколько статей

Именно поэтому в данной статье я попытался упрощённо донести суть дела.
Формально да, БД — не точное определение, но "in-memory data fabric (grid)" мало кому о чём-то говорит, проверено.


его можно использовать просто как кеш

Про это в статье есть, и не один раз.

This comment wasn’t rated yet0
Т.е. никакого persistency вообще нет?
This comment wasn’t rated yet0

Полноценный персистенс будет в 2.1 (через пару месяцев), а пока есть различные варианты write-behind или write-through в дисковую БД. Изначально это in-memory система, в угоду производительности.

This comment wasn’t rated yet0
Этот Ignite вроде бы всем хорош. Но вот только прежде чем интегрировать его в свой проект, нужно хорошо его потестить, насколько он будет выполнять поставленные задачи вашего проекта.
У нас на проекте была необходимость динамически создавать таблицы разной структуры, а Ignite как я понял обязательно требует класс который будет исполнять роль table definition, так вот у меня не завелось никак кроме как созданием класса в рантайме с помощью javassist, и после этого начинаются пляски с бубном — при старте в локальном режиме оно работает прекрасно, и sql запросы выполняются хорошо, а вот в распределенном режиме вылетают разные ошибки где-то внутри его ядра.
Так же не нашел решения проблемы, когда при создании кеша нужно указать какие типы он будет содержать, а у меня ведь рантайм… опять же обходной путь — создавать новый кеш на каждую новую таблицу/тип. Но после этого sql запросы приходится писать так:
selet * from "mydb".mydb


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

Но в проекте, где таблицы известны на этапе разработки, ignite работает прекрасно как hibernate кеш.

Вывод: требует времени на решение проблем, которых нет в более привычных базах данных. Так что он не серебряная пуля, как мне показалось после прочтения доки, а инструмент для определенных задач
Total votes 1: ↑1 and ↓0+1

Ответ ниже, промахнулся

This comment wasn’t rated yet0
По поводу классов — уже ответили ниже, они не требуются. Что касается динамического создания таблиц и более удобного использования схем — такой функционал появится в версии 2.1 в середине июня.
Total votes 1: ↑1 and ↓0+1
Ignite как я понял обязательно требует класс который будет исполнять роль table definition

Это не так, через BinaryObject API можно работать с кэшем, делать SQL запросы без единого класса.


Пример на C#: BinaryModeExample.cs


BinaryObject поддерживает добавление и удаление полей в любой момент.
Единственное ограничение связано сейчас с SQL: требуется пересоздание кэша, если нужно поменять SQL столбцы или индексы. Но классы по прежнему не нужны, всё делается без каких-либо хаков.

This comment wasn’t rated yet0

Есть несколько вопросов —


  1. Вы не упомянули, но на офф сайте написано, что это все in-memory — т.е. выключили машинку — потеряли базу, правильно?
  2. А как ноды общаются и синхронизируются между собой, ну например, у меня 3 VM, на каждом запущено по Apache Ignite — какие порты открывать, какой протокол, как и через что делается node discovery? Или это только для одного сервера ?
  3. Если я добавляю ноду — насколько быстро она получит нужные данные в Replicated режиме? Будет ли она собирать c каждого инстанса по отдельному диапазону или просто с одной из реплик качнет все что нужно?
  4. Я правильно понимаю что для запуска нужен только наггет пакет? т.е. там внутри и jar для базы и обертка на.нет чтобы его стартовать?
Total votes 1: ↑1 and ↓0+1

Комменты не обновлялись. Вопросы 1 и 4 не актуальны.

This comment wasn’t rated yet0

  1. Персистенс возможен через Cache Store. Другой вариант — настройка реплик (CacheConfiguration.Backups), то есть только одновременный выход нескольких узлов приведёт к потере данных.


  2. Общаются по TCP, находить друг друга могут по-разному, есть multicast discovery, есть static (указать IP в конфиге). Порты по умолчанию 47500~47600 для discovery и 47100~47200 для коммуникации. Это НЕ для одного сервера. Предполагается кластер из некоторого числа серверов.


  3. Будет собирать с нескольких узлов. Данные разбиваются на партиции (1024 по умолчанию), партиции распределяются между узлами. За это всё отвечает Affinity Function. При входе нового узла каждая партиция запрашивается со случайного узла из тех, на которых она есть (в Partitioned режиме с Backups > 0 таких узлов тоже несколько).


  4. Верно, NuGet содержит в себе jar файлы, больше ничего не нужно.
Total votes 1: ↑1 and ↓0+1

понятно, а в случае если сетка падает\разделяется и восстанавливается — будет 2 Availability кластера да? А по восстановлению они как-то синхронизируются\обмениваются обновившимися данными или это за пределами функционала базы?

This comment wasn’t rated yet0

В случае сегментации ("split brain") будет два кластера, да. Можно реализовать свой SegmentationResolver в качестве плагина. Плагин GridGain предоставляет свою реализацию. См тут.

Total votes 1: ↑1 and ↓0+1

Спасибо за статью.
Хорошо бы ещё обзор в сравнении с Tarantool почитать...

Total votes 1: ↑1 and ↓0+1

Небольшая дискуссия образовалась там: Tarantool как основное хранилище данных для серверных приложений, написанных на .NET.


В Tarantool есть персистенс, но нет SQL, нет нормальной поддержки .NET/С++ и многого другого.


Скоро в Игнайте будет персистенс, и вопрос закроем окончательно.

This comment wasn’t rated yet0

Честно говоря, для Key-Value БД наличие SQL мне кажется больше недостатком, чем преимуществом… Ведь придётся ради его поддержки идти на компромиссы в системе.

This comment wasn’t rated yet0
Я навскидку не могу назвать мест, где нам пришлось пойти на большие компромиссы в других компонентах ради из-за поддержки SQL. Можно перефразировать: если бы SQL не было, другие части системы не претерпели бы существенных архитектурных изменений.

А преимущество SQL очевидно — простой язык, который всем понятен, и через который можно прозрачно интегрироваться с огромным количеством систем.
Total votes 1: ↑1 and ↓0+1
У меня кейс — есть большой объем данных в оперативной памяти и я хочу запустить новый .NET код на этих данных, так вот, Ignite ругнулся, что класс должен присутствовать в сборке. Пробовал около месяца назад.

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

Планируется ли какое-то решение? Насколько я понимаю в Java такая возможность в GridGain есть.

Спасибо.
This comment wasn’t rated yet0
Если это данные в кэше, то подкладывать классы в общем случае не требуется. Если же это исполняемый код (map-reduce, closures, services), то требуется. Сейчас идет работа над описанной вами фичей для Ignite.NET [1], и в каком-то виде она с очень большой вероятностью появится в версии 2.1 в середине июня.

Но скажу прямо, у нас пока остаются неразрешенные вопросы по дизайну этого функционала. Поэтому в первой версии мы скорее всего будем просить ограничиться ее использованием в девелопменте, но не в продакшене. Ключевая проблема — выгрузка динамически подгруженных assembly. Пока решения — один AppDomen, не выгружаем assembly вообще, либо же много доменов. К обоим вариантам есть очевидные замечания. Будем думать дальше. Если хотите — подключайтесь к обсуждению в JIRA.

[1] https://issues.apache.org/jira/browse/IGNITE-2492
Total votes 2: ↑2 and ↓0+2

Есть ли (или планируется ли) в Ignite поддержка DataFrames? Мы сейчас активно экспериментируем с GraphFrames и было бы интересно попробовать улучшить перформансе, сохранив граф в интайте-кэше.

Total votes 1: ↑1 and ↓0+1

Для Spark есть вот такая интеграция: Shared Apache Spark RDDs


Если нужно просто положить инстансы DataFrame в кэш — с этим не должно быть проблем.

This comment wasn’t rated yet0

Нет, вопрос, скорее, не просто про сохранение инстансев, а именно про "прозрачную" поддержу API DataFrames.
Как я вижу, Spark Shared RDD использует свой собственный тип IgniteRDD, а значит просто передать его на вход GraphFrames не получится, придется сначала создать DataFrames. Похоже, вот тут (https://issues.apache.org/jira/browse/IGNITE-3084) обсуждается тема поддержки DataFrames и, судя по статусу Unresolved, задача еще не реализована.

Total votes 1: ↑1 and ↓0+1
Должна появиться в обозримом будущем.
Total votes 1: ↑1 and ↓0+1
Это совершенно разные продукты. Общее сравнение лучше-хуже не является корректным.
Total votes 1: ↑1 and ↓0+1

Я бы не сказал, что это "совершенно разные продукты". Как раз таки в основе своей они одинаковые — распределённый кэш.


У Ignite богаче функционал самого кэша, и много других фич.

Total votes 1: ↑0 and ↓1-1

Решил, наконец, попробовать Ignite, но выяснилось, что сборка несовместима с .Net Core… Как же так?
Сейчас уже никто не выпускает новых пакетов для .Net, которые бы не были совместимы с Core.

This comment wasn’t rated yet0

Там всё меняется каждый день, то одно, то другое. Слишком сыро. Плюс сложности с обратной совместимостью проектов.


На данный момент принято решение дождаться выхода .NET Standard 2.0. Подробности в каментах тикета: https://issues.apache.org/jira/browse/IGNITE-2662


уже никто не выпускает

сильное преувеличение

This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr