• MVCC как один из способов обеспечения изоляции транзакций
    +4

    Механизм MVCC перпендикулярен наличию или отсутствию блокировок. Потому утверждение, что MVCC является optimistic concurrency control, как и деление на «версионники» и «блокировочники», в корне неверны.


    Подобными постами вы показываете, что продаёте курсы, материал которых не понимаете.

  • Насколько много маркетинга в ACID?
    0
    Можете показать статьи или репорты об утере данных из-за fsynс, который не сохранил данные на диск?
  • Коронавирус: как мы себя обманываем
    +14

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

  • Распределённые приложения на C++ с минимумом усилий
    0
    Не уверен, что автоинкрементальные колонки появятся в продукте в обозримом будущем. Там очень много проблем. Гораздо лучше сразу привыкать к особенностям распределенных систем, и использовать глобально уникальные значения, типа UUID.
  • Внедрение зависимостей в сервис Apache Ignite.NET
    0
    Артем, спасибо за публикацию. Думаю, было бы очень полезно сделать такую интеграцию на уровне самого продукта, что бы пользователям не пришлось писать свои плагины. В Java версии это уже сделано [1] [2]. В .NET тоже можно было бы сделать специальную аннотацию, которая бы связывалась с DI-контейнерами.

    Если будет желание сделать такой contribution — приходите к нам на dev list :)

    [1] github.com/apache/ignite/blob/ignite-2.5/modules/core/src/main/java/org/apache/ignite/resources/SpringResource.java
    [2] github.com/apache/ignite/blob/ignite-2.5/modules/core/src/main/java/org/apache/ignite/resources/SpringApplicationContextResource.java
  • Как не сломать кластер Apache Ignite с самого начала
    0
    Apache Calcite нам не интересен, потому что все, что он делает, мы умеем делать сами — и парсинг, и JDBC, и оптимизации. Более того, распределенный SQL предполагает другие правила оптимиации запросов, поэтому полагаться на какую-то внещнюю систему для этого мы не можем.

    Что касается H2, он может быть сыроват в плане стораджа, но мы его и не используем. От H2 мы используем преимущественно движок локального выполнения запросов. Он не дико навороченный конечно, но работает вполне неплохо.

    Главные вызовы, которые сейчас перед нами стоят находятся вне функционала H2 и Calcite.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    +1
    Звучит загадочно. Таблица просто так не расползается по HDD и SSD. Она находится внутри tablespace, который хранит данные в файлах. Вероятнее всего, в вашем случае речь идет либо о кривой конфигурации, либо о неверных выводах.
  • Хранение данных на Виниле
    0
    Спасибо за интересную статью. Обращу внимание на ряд моментов касательно сравнения LSM vs BTree:
    1) MongoDB использует BTree [1]. «In our testing there are a very limited number of scenarios where MongoDB provides better characteristics when using LSM than the WiredTiger btree implementation»
    2) Проблема write amplification в BTree при переходе к LSM превращается в проблему баланса между size amplification и write amplification в зависимости от стратегии. Очень опасно утверждать, что какой-либо из подходов в плане баланса требований к чтениям, записям и capacity является лучше другого в большинстве сценариев
    3) Вопрос многоверсионности достаточно слабо связан c форматом хранения, и едва ли может рассматриваться преимуществом LSM
    4) Вопрос сжатия раскрыт поверхностно. Упоминается старый table compression MySQL, и PostgreSQL, который просто пошел по пути наименьшего сопротивления. Не упоминается index prefix compression, который есть почти у всех вендоров, и отлично сжимает secondary indexes. Не упоминаются продвинутые техники сжатия data pages, которые есть в MS SQL и Oracle, которые хоть и не даются бесплатно, но все же очень далеки от rocket science.

    [1] jira.mongodb.org/browse/SERVER-18396
  • Что нового в DataGrip 2018.1
    0

    Apache Ignite не хотите поддержать?

  • Apache Ignite.NET 2.4: Тонкий и кроссплатформенный
    +2
    Добавлю, что типичный оверхед на JNI составляет несколько десятков наносекунд. Reverse JNI на момент замеров (JDK 7) был немного медленнее, чем прямой. В рамках распределенной системы, где типичный latency измеряется миллисекундами, оверхед JNI амортизируется практически в ноль.
  • Релиз Apache Ignite 2.4 — Distributed Database and Caching Platform
    0
    Транзакционный SQL сейчас в стадии активной разработки [1]. Озвучить сроки выхода мы пока не готовы.
    [1] issues.apache.org/jira/browse/IGNITE-4191
  • Релиз Apache Ignite 2.4 — Distributed Database and Caching Platform
    0
    Выключать можно и с помощью Java API. Главный сценарий — быстрая загрузка данных.
  • Много, быстро, распределенно: как выбирать In-Memory Data Grid-решение
    0
    Не совсем так. C# делегирует часть работы в Java. При этом узел C# может быть как клиентом, так и сервером. Один из плюсов такой модели — возможность исполнять реальный .NET-код в кластере. Тонкий .NET-клиент таким функционалом обладать не может.
  • Много, быстро, распределенно: как выбирать In-Memory Data Grid-решение
    +1
    А, понял, мы же действительно еще не релизнули это :) Должно заработать в AI 2.3, который должен выйти до конца октября.
  • Много, быстро, распределенно: как выбирать In-Memory Data Grid-решение
    0
    А что вы вкладываете в schema exploration? Мы поддерживаем работу с метаданными, поэтому существующие схемы, таблицы и колонки должны быть видны.
  • Много, быстро, распределенно: как выбирать In-Memory Data Grid-решение
    0
    Есть еще JDBC и ODBC. В ближайшее время появится открытый протокол для создания клиентов на любой платформе или языке программирования.
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +1
    Это совершенно разные продукты. Общее сравнение лучше-хуже не является корректным.
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +1
    Должна появиться в обозримом будущем.
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +2
    Если это данные в кэше, то подкладывать классы в общем случае не требуется. Если же это исполняемый код (map-reduce, closures, services), то требуется. Сейчас идет работа над описанной вами фичей для Ignite.NET [1], и в каком-то виде она с очень большой вероятностью появится в версии 2.1 в середине июня.

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

    [1] https://issues.apache.org/jira/browse/IGNITE-2492
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +1
    Я навскидку не могу назвать мест, где нам пришлось пойти на большие компромиссы в других компонентах ради из-за поддержки SQL. Можно перефразировать: если бы SQL не было, другие части системы не претерпели бы существенных архитектурных изменений.

    А преимущество SQL очевидно — простой язык, который всем понятен, и через который можно прозрачно интегрироваться с огромным количеством систем.
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +1
    По второму пункту корректнее будет сказать, что оно регулируемо. Можно качнуть в сторону AP, можно в сторону CP.
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +1
    1) Этот вопрос станет актуален, когда выйдет persistence.
    2) CP
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +2
    Порт — это перенос сотен тысяч строк нетривиального кода, полный отказ от стандартных механизмов сериализации, и удвоение работы по имплементации и поддержке каждого тикета, раздувание штата.
    Обертка — это быстрый подъем функционала, отсутствие дупликации. Ценой некоторых потерь в производительности, которые едва ли видны на фоне сетевого взаимодействия.

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

    С точки зрения комьюнити этот выбор достаточно перпенедикулярен.
  • Для чего нужен Apache Ignite / GridGain, на примере .NET & C#
    +1
    По поводу классов — уже ответили ниже, они не требуются. Что касается динамического создания таблиц и более удобного использования схем — такой функционал появится в версии 2.1 в середине июня.
  • «Apache Ignite — наукоёмкий продукт»: GridGain Systems о in-memory computing, open source, российском рынке и не только
    +1
    Полноценный MVCC появится в ближайшем будущем. В интернете можете найти много статей на эту тему. Если на фундаментальном уровне, то раздел 9 (Transaction Processing, Concurrency Control, and Recovering) отсюда [1]. Только нам это нужно распределенно :-)

    [1] https://www.amazon.ca/Fundamentals-Database-Systems-Ramez-Elmasri/dp/0133970779
  • Знакомство с Apache Ignite: первые шаги
    0
    Ильшат, не подскажите чего именно, на ваш взгляд, не хватало в документации?
  • Открытая трибуна для разработчиков opensource-проектов
    0
    Его пилят много разработчиков, в том числе и я.
  • Знакомство с Apache Ignite: первые шаги
    +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++, и т. д…
  • Открытая трибуна для разработчиков opensource-проектов
    0
    С удовольствием расскажем про Apache Ignite. Один из немногих крупных OSS-проектов, который пилят в России.