Добавлю, что типичный оверхед на JNI составляет несколько десятков наносекунд. Reverse JNI на момент замеров (JDK 7) был немного медленнее, чем прямой. В рамках распределенной системы, где типичный latency измеряется миллисекундами, оверхед JNI амортизируется практически в ноль.
Не совсем так. C# делегирует часть работы в Java. При этом узел C# может быть как клиентом, так и сервером. Один из плюсов такой модели — возможность исполнять реальный .NET-код в кластере. Тонкий .NET-клиент таким функционалом обладать не может.
Если это данные в кэше, то подкладывать классы в общем случае не требуется. Если же это исполняемый код (map-reduce, closures, services), то требуется. Сейчас идет работа над описанной вами фичей для Ignite.NET [1], и в каком-то виде она с очень большой вероятностью появится в версии 2.1 в середине июня.
Но скажу прямо, у нас пока остаются неразрешенные вопросы по дизайну этого функционала. Поэтому в первой версии мы скорее всего будем просить ограничиться ее использованием в девелопменте, но не в продакшене. Ключевая проблема — выгрузка динамически подгруженных assembly. Пока решения — один AppDomen, не выгружаем assembly вообще, либо же много доменов. К обоим вариантам есть очевидные замечания. Будем думать дальше. Если хотите — подключайтесь к обсуждению в JIRA.
Я навскидку не могу назвать мест, где нам пришлось пойти на большие компромиссы в других компонентах ради из-за поддержки SQL. Можно перефразировать: если бы SQL не было, другие части системы не претерпели бы существенных архитектурных изменений.
А преимущество SQL очевидно — простой язык, который всем понятен, и через который можно прозрачно интегрироваться с огромным количеством систем.
Порт — это перенос сотен тысяч строк нетривиального кода, полный отказ от стандартных механизмов сериализации, и удвоение работы по имплементации и поддержке каждого тикета, раздувание штата.
Обертка — это быстрый подъем функционала, отсутствие дупликации. Ценой некоторых потерь в производительности, которые едва ли видны на фоне сетевого взаимодействия.
Это трейдофф, в котором мы выбрали первое, о чем до сих пор ни разу не пожалели. .NET не только в продакшене бегает, его уже другие вендоры эмбедяд в свои продукты.
С точки зрения комьюнити этот выбор достаточно перпенедикулярен.
По поводу классов — уже ответили ниже, они не требуются. Что касается динамического создания таблиц и более удобного использования схем — такой функционал появится в версии 2.1 в середине июня.
Полноценный MVCC появится в ближайшем будущем. В интернете можете найти много статей на эту тему. Если на фундаментальном уровне, то раздел 9 (Transaction Processing, Concurrency Control, and Recovering) отсюда [1]. Только нам это нужно распределенно :-)
Начать можно с официального сайта: http://ignite.apache.org/
На данный момент описать продукт в двух словах проблематично. Официальная формулировка — data fabric, то есть интегрированная платформа для распределенных вычислений и работы с данными.
Многие (если не все) продукты такого класса лет 10 назад начинали с простого use case: распределенный кэш и map-reduce, горизонтальное масштабирование. За годы требования бизнеса и конкуренция возросли, поэтому они трансформировались в эдакие универсальные конструкторы для работы с данными.
Ключевые фичи конкретно Ignite: distributed cache, распределенный SQL поверх данных в памяти (+ JDBC и ODBC драйвера), map-reduce, стриминг, распределенная файловая система, множество интеграций (web sessions, hibernate L2 cache, ...), API для .NET и C++, и т. д…
[1] issues.apache.org/jira/browse/IGNITE-4191
Но скажу прямо, у нас пока остаются неразрешенные вопросы по дизайну этого функционала. Поэтому в первой версии мы скорее всего будем просить ограничиться ее использованием в девелопменте, но не в продакшене. Ключевая проблема — выгрузка динамически подгруженных assembly. Пока решения — один AppDomen, не выгружаем assembly вообще, либо же много доменов. К обоим вариантам есть очевидные замечания. Будем думать дальше. Если хотите — подключайтесь к обсуждению в JIRA.
[1] https://issues.apache.org/jira/browse/IGNITE-2492
А преимущество SQL очевидно — простой язык, который всем понятен, и через который можно прозрачно интегрироваться с огромным количеством систем.
2) CP
Обертка — это быстрый подъем функционала, отсутствие дупликации. Ценой некоторых потерь в производительности, которые едва ли видны на фоне сетевого взаимодействия.
Это трейдофф, в котором мы выбрали первое, о чем до сих пор ни разу не пожалели. .NET не только в продакшене бегает, его уже другие вендоры эмбедяд в свои продукты.
С точки зрения комьюнити этот выбор достаточно перпенедикулярен.
[1] https://www.amazon.ca/Fundamentals-Database-Systems-Ramez-Elmasri/dp/0133970779
На данный момент описать продукт в двух словах проблематично. Официальная формулировка — data fabric, то есть интегрированная платформа для распределенных вычислений и работы с данными.
Многие (если не все) продукты такого класса лет 10 назад начинали с простого use case: распределенный кэш и map-reduce, горизонтальное масштабирование. За годы требования бизнеса и конкуренция возросли, поэтому они трансформировались в эдакие универсальные конструкторы для работы с данными.
Ключевые фичи конкретно Ignite: distributed cache, распределенный SQL поверх данных в памяти (+ JDBC и ODBC драйвера), map-reduce, стриминг, распределенная файловая система, множество интеграций (web sessions, hibernate L2 cache, ...), API для .NET и C++, и т. д…