Комментарии 44
Советую в подобных статьях вот это "Самый простой и ёмкий ответ — это база данных. В основе которой — хранилище "ключ-значение"; грубо говоря, ConcurrentDictionary, в котором данные расположены на нескольких машинах." помещать в шапку. Жутко бесит когда сперва идет простыня о продукте, но даже не понятно о каком :)
В остальном, спасибо.
чтож не вся статья ф таком стиле;
Плохая новость: мы работаем на винде. Хорошая новость: забейте на это и абстрагируйтесь от ос
Плохая новость: мы работаем с .net. Хорошая новость: забейте на это и абстрагируйтесь от vm
Плохая новость: мы работаем x86. Хорошая новость: забейте на это и абстрагируйтесь от железа
Самое интересное (страшное), что .net ignite запускает jvm внутри себя, и как этот сендвич будет в продакшене работать никакой уверенности нет, в Сбере ж на java его используют, а других компаний использующих его и нет (ну или нет инфы о них)
Что значит кроме сбера компаний нет, откуда такие домыслы? Информация в открытом доступе: https://www.gridgain.com/customers/featured-customers
На словах может оно и страшно, две виртуальные машины в одном процессе, но если вдуматься — а что в этом такого? Они никак друг другу не мешают. Зато работает быстро, обмен данными через кусок unmanaged памяти. В продакшене всё хорошо.
Также в планах есть вынесение JVM в отдельный процесс и полноценный тонкий клиент на чистом дотнете.
2) К чему относится Ignite исходя из CAP теоремы, к CP или CA?
2) CP
2) Скажите, если у меня есть две кэша на разных нодах Partitioned и включен бэкап. Это будет распределенная транзакция? И будут ли атомарно операции записи в кэш и актуализация бэкапа? Оно работает аналогично синхронной репликации?
Ну как минимум 2 неуправляемых кучи, 2 GC, 2 stop the world, куча jvm настроек, которые непонятно как отразятся на работе связки.
Лучше не JVM вытаскивать а порт сделать, тогда комьюнити потянется, а так — скрестили 2 технологии в одном процессе.
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.
порт сделать
Полноценный порт потребует титанических усилий, значительно увеличит затраты на поддержку кода, и приведёт к менее гибкому решению. Смысла мало.
Обертка — это быстрый подъем функционала, отсутствие дупликации. Ценой некоторых потерь в производительности, которые едва ли видны на фоне сетевого взаимодействия.
Это трейдофф, в котором мы выбрали первое, о чем до сих пор ни разу не пожалели. .NET не только в продакшене бегает, его уже другие вендоры эмбедяд в свои продукты.
С точки зрения комьюнити этот выбор достаточно перпенедикулярен.
Также в планах есть вынесение JVM в отдельный процесс и полноценный тонкий клиент на чистом дотнете.
А это не будет затратнее? Добавите целых 2 прослойки сетевого взаимодействия, по 1 на каждой из сторон. Что есть сейчас — очень привлекательно. Тут вообще вопрос в том, что зачем брать отдельным сервисом какое-то хранилище, если его можно использовать прям в этом же процессе, т.е. избавить от оверхеда на сетевой трафик запрос-ответ и инфраструктуру их обслуживания.
Да, дополнительный оверхед будет. Но есть ситуации, когда тонкий клиент необходим — короткий жизненный цикл приложения, ограничения по ресурсам, и так далее.
Существующая опция останется, это важный сценарий использования, отказываться от него никаких причин нет.
Работа над тонким клиентом уже идёт, он будет доступен в версии 2.4 (конец года).
Обе опции будут поддерживаться под .NET Core 2.0. "Серверный режим" заводится пока только под windows (любая версия уже работает), тонкий клиент работает и под Linux (если взять ночной билд, можно уже сейчас это попробовать: https://myget.org/gallery/apache-ignite-net-nightly).
чтобы рассказать про Ignite надо несколько статей
Именно поэтому в данной статье я попытался упрощённо донести суть дела.
Формально да, БД — не точное определение, но "in-memory data fabric (grid)" мало кому о чём-то говорит, проверено.
его можно использовать просто как кеш
Про это в статье есть, и не один раз.
У нас на проекте была необходимость динамически создавать таблицы разной структуры, а Ignite как я понял обязательно требует класс который будет исполнять роль table definition, так вот у меня не завелось никак кроме как созданием класса в рантайме с помощью javassist, и после этого начинаются пляски с бубном — при старте в локальном режиме оно работает прекрасно, и sql запросы выполняются хорошо, а вот в распределенном режиме вылетают разные ошибки где-то внутри его ядра.
Так же не нашел решения проблемы, когда при создании кеша нужно указать какие типы он будет содержать, а у меня ведь рантайм… опять же обходной путь — создавать новый кеш на каждую новую таблицу/тип. Но после этого sql запросы приходится писать так:
selet * from "mydb".mydb
Так как джава классы создаются динамически, то удалить их динамически уже так просто не получится, что так же создает еще одну проблему.
Но в проекте, где таблицы известны на этапе разработки, ignite работает прекрасно как hibernate кеш.
Вывод: требует времени на решение проблем, которых нет в более привычных базах данных. Так что он не серебряная пуля, как мне показалось после прочтения доки, а инструмент для определенных задач
Ignite как я понял обязательно требует класс который будет исполнять роль table definition
Это не так, через BinaryObject
API можно работать с кэшем, делать SQL запросы без единого класса.
Пример на C#: BinaryModeExample.cs
BinaryObject
поддерживает добавление и удаление полей в любой момент.
Единственное ограничение связано сейчас с SQL: требуется пересоздание кэша, если нужно поменять SQL столбцы или индексы. Но классы по прежнему не нужны, всё делается без каких-либо хаков.
Есть несколько вопросов —
- Вы не упомянули, но на офф сайте написано, что это все in-memory — т.е. выключили машинку — потеряли базу, правильно?
- А как ноды общаются и синхронизируются между собой, ну например, у меня 3 VM, на каждом запущено по Apache Ignite — какие порты открывать, какой протокол, как и через что делается node discovery? Или это только для одного сервера ?
- Если я добавляю ноду — насколько быстро она получит нужные данные в Replicated режиме? Будет ли она собирать c каждого инстанса по отдельному диапазону или просто с одной из реплик качнет все что нужно?
- Я правильно понимаю что для запуска нужен только наггет пакет? т.е. там внутри и jar для базы и обертка на.нет чтобы его стартовать?
Комменты не обновлялись. Вопросы 1 и 4 не актуальны.
Персистенс возможен через Cache Store. Другой вариант — настройка реплик (
CacheConfiguration.Backups
), то есть только одновременный выход нескольких узлов приведёт к потере данных.
Общаются по TCP, находить друг друга могут по-разному, есть multicast discovery, есть static (указать IP в конфиге). Порты по умолчанию
47500~47600
для discovery и47100~47200
для коммуникации. Это НЕ для одного сервера. Предполагается кластер из некоторого числа серверов.
Будет собирать с нескольких узлов. Данные разбиваются на партиции (1024 по умолчанию), партиции распределяются между узлами. За это всё отвечает Affinity Function. При входе нового узла каждая партиция запрашивается со случайного узла из тех, на которых она есть (в Partitioned режиме с Backups > 0 таких узлов тоже несколько).
- Верно, NuGet содержит в себе jar файлы, больше ничего не нужно.
Спасибо за статью.
Хорошо бы ещё обзор в сравнении с Tarantool почитать...
Небольшая дискуссия образовалась там: Tarantool как основное хранилище данных для серверных приложений, написанных на .NET.
В Tarantool есть персистенс, но нет SQL, нет нормальной поддержки .NET/С++ и многого другого.
Скоро в Игнайте будет персистенс, и вопрос закроем окончательно.
Честно говоря, для Key-Value БД наличие SQL мне кажется больше недостатком, чем преимуществом… Ведь придётся ради его поддержки идти на компромиссы в системе.
А преимущество SQL очевидно — простой язык, который всем понятен, и через который можно прозрачно интегрироваться с огромным количеством систем.
То есть получается, что нельзя один раз поднять данные в память, потом компилировать новый код и запускать на данных в гриде. Необходимо после каждой компиляции перезапускать грид.
Планируется ли какое-то решение? Насколько я понимаю в Java такая возможность в GridGain есть.
Спасибо.
Но скажу прямо, у нас пока остаются неразрешенные вопросы по дизайну этого функционала. Поэтому в первой версии мы скорее всего будем просить ограничиться ее использованием в девелопменте, но не в продакшене. Ключевая проблема — выгрузка динамически подгруженных assembly. Пока решения — один AppDomen, не выгружаем assembly вообще, либо же много доменов. К обоим вариантам есть очевидные замечания. Будем думать дальше. Если хотите — подключайтесь к обсуждению в JIRA.
[1] https://issues.apache.org/jira/browse/IGNITE-2492
Есть ли (или планируется ли) в Ignite поддержка DataFrames? Мы сейчас активно экспериментируем с GraphFrames и было бы интересно попробовать улучшить перформансе, сохранив граф в интайте-кэше.
Для Spark есть вот такая интеграция: Shared Apache Spark RDDs
Если нужно просто положить инстансы DataFrame
в кэш — с этим не должно быть проблем.
Нет, вопрос, скорее, не просто про сохранение инстансев, а именно про "прозрачную" поддержу API DataFrames.
Как я вижу, Spark Shared RDD использует свой собственный тип IgniteRDD, а значит просто передать его на вход GraphFrames не получится, придется сначала создать DataFrames. Похоже, вот тут (https://issues.apache.org/jira/browse/IGNITE-3084) обсуждается тема поддержки DataFrames и, судя по статусу Unresolved, задача еще не реализована.
Решил, наконец, попробовать Ignite, но выяснилось, что сборка несовместима с .Net Core… Как же так?
Сейчас уже никто не выпускает новых пакетов для .Net, которые бы не были совместимы с Core.
Там всё меняется каждый день, то одно, то другое. Слишком сыро. Плюс сложности с обратной совместимостью проектов.
На данный момент принято решение дождаться выхода .NET Standard 2.0. Подробности в каментах тикета: https://issues.apache.org/jira/browse/IGNITE-2662
уже никто не выпускает
сильное преувеличение
Для чего нужен Apache Ignite / GridGain, на примере .NET & C#