Получается довольно бессмысленно, но работает. void MyFunc(myDelegate deleg, int arg){deleg.Invoke(arg);}
Очень даже не бессмысленно.
Пусть нам нужно выполнить тяжёлую обработку большого набора данных. Такой метод может распараллеливать вычисления автоматически между потоками (PLINQ, Parallel.ForEach) или компьютерами (Ignite): IEnumerable<TRes> Apply<TArg, TRes>(Func<TArg, TRes> func, IEnumerable<TArg> args)
Давайте предметно, какие проблемы вы предвидите?
Обычный .NET код сплошь и рядом дёргает системные API, у которых своя unmanaged куча, и что?
Проблемы тут могут быть в x86 (32 bit), где сильно ограничено адресное пространство. В x64 с этим проблем нет. Но речь идёт о big data, так что 32 бита нас не особо беспокоят.
2 stop the world
Не все GC делают stop the world, это раз. Аллокации в managed heap на стороне Java минимальны, это два. Пользовательские данные хранятся в неуправляемой куче через Unsafe.
порт сделать
Полноценный порт потребует титанических усилий, значительно увеличит затраты на поддержку кода, и приведёт к менее гибкому решению. Смысла мало.
В случае сегментации ("split brain") будет два кластера, да. Можно реализовать свой SegmentationResolver в качестве плагина. Плагин GridGain предоставляет свою реализацию. См тут.
Персистенс возможен через Cache Store. Другой вариант — настройка реплик (CacheConfiguration.Backups), то есть только одновременный выход нескольких узлов приведёт к потере данных.
Общаются по TCP, находить друг друга могут по-разному, есть multicast discovery, есть static (указать IP в конфиге). Порты по умолчанию 47500~47600 для discovery и 47100~47200 для коммуникации. Это НЕ для одного сервера. Предполагается кластер из некоторого числа серверов.
Будет собирать с нескольких узлов. Данные разбиваются на партиции (1024 по умолчанию), партиции распределяются между узлами. За это всё отвечает Affinity Function. При входе нового узла каждая партиция запрашивается со случайного узла из тех, на которых она есть (в Partitioned режиме с Backups > 0 таких узлов тоже несколько).
Верно, NuGet содержит в себе jar файлы, больше ничего не нужно.
Полноценный персистенс будет в 2.1 (через пару месяцев), а пока есть различные варианты write-behind или write-through в дисковую БД. Изначально это in-memory система, в угоду производительности.
BinaryObject поддерживает добавление и удаление полей в любой момент.
Единственное ограничение связано сейчас с SQL: требуется пересоздание кэша, если нужно поменять SQL столбцы или индексы. Но классы по прежнему не нужны, всё делается без каких-либо хаков.
Именно поэтому в данной статье я попытался упрощённо донести суть дела.
Формально да, БД — не точное определение, но "in-memory data fabric (grid)" мало кому о чём-то говорит, проверено.
На словах может оно и страшно, две виртуальные машины в одном процессе, но если вдуматься — а что в этом такого? Они никак друг другу не мешают. Зато работает быстро, обмен данными через кусок unmanaged памяти. В продакшене всё хорошо.
Также в планах есть вынесение JVM в отдельный процесс и полноценный тонкий клиент на чистом дотнете.
А как обеспечивается апгрейд сервисов? То есть я хочу выкатить новую версию сервиса (пофикшен баг, добавлен метод), как сделать это, не прерывая работу всей системы?
Ignite вполне себе production-ready и работает в продакшне у разных серьёзных чуваков :)
https://www.gridgain.com/customers/featured-customers
Cassandra довольно сильно отличается от Ignite.
Там всё меняется каждый день, то одно, то другое. Слишком сыро. Плюс сложности с обратной совместимостью проектов.
На данный момент принято решение дождаться выхода .NET Standard 2.0. Подробности в каментах тикета: https://issues.apache.org/jira/browse/IGNITE-2662
сильное преувеличение
Очень даже не бессмысленно.
Пусть нам нужно выполнить тяжёлую обработку большого набора данных. Такой метод может распараллеливать вычисления автоматически между потоками (PLINQ, Parallel.ForEach) или компьютерами (Ignite):
IEnumerable<TRes> Apply<TArg, TRes>(Func<TArg, TRes> func, IEnumerable<TArg> args)P.S. .Net -> .NET
Я бы не сказал, что это "совершенно разные продукты". Как раз таки в основе своей они одинаковые — распределённый кэш.
У Ignite богаче функционал самого кэша, и много других фич.
Для Spark есть вот такая интеграция: Shared Apache Spark RDDs
Если нужно просто положить инстансы
DataFrameв кэш — с этим не должно быть проблем.Небольшая дискуссия образовалась там: Tarantool как основное хранилище данных для серверных приложений, написанных на .NET.
В Tarantool есть персистенс, но нет SQL, нет нормальной поддержки .NET/С++ и многого другого.
Скоро в Игнайте будет персистенс, и вопрос закроем окончательно.
Давайте предметно, какие проблемы вы предвидите?
Обычный .NET код сплошь и рядом дёргает системные API, у которых своя unmanaged куча, и что?
Проблемы тут могут быть в x86 (32 bit), где сильно ограничено адресное пространство. В x64 с этим проблем нет. Но речь идёт о big data, так что 32 бита нас не особо беспокоят.
Не все GC делают stop the world, это раз. Аллокации в managed heap на стороне Java минимальны, это два. Пользовательские данные хранятся в неуправляемой куче через Unsafe.
Полноценный порт потребует титанических усилий, значительно увеличит затраты на поддержку кода, и приведёт к менее гибкому решению. Смысла мало.
В случае сегментации ("split brain") будет два кластера, да. Можно реализовать свой
SegmentationResolverв качестве плагина. Плагин GridGain предоставляет свою реализацию. См тут.Персистенс возможен через Cache Store. Другой вариант — настройка реплик (
CacheConfiguration.Backups), то есть только одновременный выход нескольких узлов приведёт к потере данных.Общаются по TCP, находить друг друга могут по-разному, есть multicast discovery, есть static (указать IP в конфиге). Порты по умолчанию
47500~47600для discovery и47100~47200для коммуникации. Это НЕ для одного сервера. Предполагается кластер из некоторого числа серверов.Будет собирать с нескольких узлов. Данные разбиваются на партиции (1024 по умолчанию), партиции распределяются между узлами. За это всё отвечает Affinity Function. При входе нового узла каждая партиция запрашивается со случайного узла из тех, на которых она есть (в Partitioned режиме с Backups > 0 таких узлов тоже несколько).
Полноценный персистенс будет в 2.1 (через пару месяцев), а пока есть различные варианты write-behind или write-through в дисковую БД. Изначально это in-memory система, в угоду производительности.
Ответ ниже, промахнулся
Это не так, через
BinaryObjectAPI можно работать с кэшем, делать SQL запросы без единого класса.Пример на C#: BinaryModeExample.cs
BinaryObjectподдерживает добавление и удаление полей в любой момент.Единственное ограничение связано сейчас с SQL: требуется пересоздание кэша, если нужно поменять SQL столбцы или индексы. Но классы по прежнему не нужны, всё делается без каких-либо хаков.
Именно поэтому в данной статье я попытался упрощённо донести суть дела.
Формально да, БД — не точное определение, но "in-memory data fabric (grid)" мало кому о чём-то говорит, проверено.
Про это в статье есть, и не один раз.
Что значит кроме сбера компаний нет, откуда такие домыслы? Информация в открытом доступе: https://www.gridgain.com/customers/featured-customers
На словах может оно и страшно, две виртуальные машины в одном процессе, но если вдуматься — а что в этом такого? Они никак друг другу не мешают. Зато работает быстро, обмен данными через кусок unmanaged памяти. В продакшене всё хорошо.
Также в планах есть вынесение JVM в отдельный процесс и полноценный тонкий клиент на чистом дотнете.
А как обеспечивается апгрейд сервисов? То есть я хочу выкатить новую версию сервиса (пофикшен баг, добавлен метод), как сделать это, не прерывая работу всей системы?
Спасибо! Думаю, стоит ссылку на код добавить в статью :)
Исходный код где-то можно увидеть? Интересуюсь как разработчик LINQ провайдера для Apache Ignite.NET.
Solr ведь тоже апачевский open-source проект — ожидаешь, что примочки к нему будут открытые.
Зачем же так сразу?
Какие уж тут пироги, если даже SQL нету
Почему именно СУБД, как CacheStore реализуешь, так и будет писаться. Синхронная запись подразумевает "не быстрее чем то, куда пишем", разве нет?
Это валидный пункт. Вроде как в будущем появится. Изначально Игнайт — in-memory система.
Всегда была в виде write-through cache store: https://apacheignite.readme.io/docs/persistent-store