Ждём ODBC Schema Exploration и можно будет юзать почти как обычную БД :)

Есть несколько моментов. Давайте пройдемся по пунктам.
  • СУБД — узкое место при сохранении данных
    Непонятно, как PDS решает эту «проблему». Данные все равно на диск писать надо.
  • СУБД — единая точка отказа
    Често говоря, зувучит как спекуляция. Якобы нет масштабируемых отказоустойчивых СУБД.
  • Невозможность одновременно выполнять SQL поверх данных в Ignite и в СУБД
    Аргумент конечно хороший. Но нет ни слова про ACID. SQL — просто язык запросов. Интересно как релизован(и реализован ли ACID в случае работы с PDS)?
  • Необходимость прогрева
    Ну вот вообще непонятно. Прогревать нужно и в случае PDS. А если использовать «lazy-run», то возникает вопрос, зачем мне вообще in-memory. Т.е. если после поднятия некоторое время нода будет работать со скоростью обычной реляционной базы и я могу себе это позволить, то получается что in-memory мне и не нужен. Если же для меня критична скорость работы, то возникает вопрос что случится если(а так и будет) часть данных, необходимых для запроса, лежит на нодах, которые не падали, а часть на только что поднятой. Верно ли, что в таком случае время ответа будет равно времени ответа самой медленной ноды(читай реляционной БД)?
Добрый день!

СУБД — узкое место при сохранении данных
Непонятно, как PDS решает эту «проблему». Данные все равно на диск писать надо.

Проблема решается через горизонтальное масштабирование. Традиционные реляционные СУБД сложно и дорого масштабировать, и даже когда они масштабируются, они масштабируются на уровень нескольких узлов. Apache Ignite может размещаться на десятках и сотнях узлов, работать на нескольких связанных геораспределенных кластерах, размазывая IO и его издержки.

СУБД — единая точка отказа
Често говоря, зувучит как спекуляция. Якобы нет масштабируемых отказоустойчивых СУБД.

Здесь речь идет, скорее, о классических реляционных СУБД, которые обычно плохо горизонтально масштабируются и имеют ограниченные возможности обеспечения отказоустойчивости при сохранении ACID-гарантий. Если говорить о сравнении с разными классами продуктов для хранения данных, можно привести такую иллюстрацию:


Здесь замечу также, что Apache Ignite является в том числе распределенной СУБД с поддержкой ACID и SQL, но помимо этого имеется множество других возможностей, которые в СУБД других классов зачастую отсутствуют.

Невозможность одновременно выполнять SQL поверх данных в Ignite и в СУБД
Аргумент конечно хороший. Но нет ни слова про ACID. SQL — просто язык запросов. Интересно как релизован(и реализован ли ACID в случае работы с PDS)?

При использовании PDS гарантии ACID остаются в силе.

Необходимость прогрева
Ну вот вообще непонятно. Прогревать нужно и в случае PDS. А если использовать «lazy-run», то возникает вопрос, зачем мне вообще in-memory. Т.е. если после поднятия некоторое время нода будет работать со скоростью обычной реляционной базы и я могу себе это позволить, то получается что in-memory мне и не нужен.

Ранее в принципе не было возможности стартовать быстро, с диска. У некоторых задач есть потребность после рестарта кластера какое-то время поработать медленно, но начать принимать запросы сразу, и после прогрева получить все преимущества распределенного in-memory. Теперь необходимость такого сценария не блокирует выбор Apache Ignite.

Обращу внимание, что важными сторонами Ignite является не только In-Memory, но еще, например, горизонтальная масштабируемость и функционал грида. Далее, в зависимости от задачи, от платформы выбирается тот набор функций, который лучше всего подходит задаче.

Если же для меня критична скорость работы, то возникает вопрос что случится если(а так и будет) часть данных, необходимых для запроса, лежит на нодах, которые не падали, а часть на только что поднятой. Верно ли, что в таком случае время ответа будет равно времени ответа самой медленной ноды(читай реляционной БД)?

Если часть необходимых для запроса данных лежит на узле, где они еще не поднялись с диска, то они будут прочитаны с диска, время выполнения запроса будет соответствующим. Но такой запрос хотя бы можно будет выполнить. Что важнее для задачи — выполнить любой ценой или выполнить только быстро — зависит от задачи. И для того, и для другого сценария есть инструменты реализации.
Ок. Давайте еще разок.
СУБД — узкое место при сохранении данных. С помощью технологий вычисления в памяти и горизонтального масштабирования можно добиться значительно более высоких показателей чтения данных. Но при этом запись останется узким местом, поскольку платформе нужно будет дублировать операции записи в СУБД, которая почти всегда масштабируется намного хуже, если масштабируется вообще. А потребность в быстрой записи иногда может быть выше потребности в быстром чтении.

Тщетно пытаюсь нагрепать в оригинальной статье слово «реляционная». Какая-то подмена понятий выходит. Ну да ладно. Так вот, из ответа
Проблема решается через горизонтальное масштабирование. Традиционные реляционные СУБД сложно и дорого масштабировать, и даже когда они масштабируются, они масштабируются на уровень нескольких узлов. Apache Ignite может размещаться на десятках и сотнях узлов, работать на нескольких связанных геораспределенных кластерах, размазывая IO и его издержки.

Мне совсем неясно, чем ваше решение лучше той же кассандры(имеется ввиду часть с распределенной записью)? И если уж в оригинале имеется ввиду сравнение именно с реляционной базой, то надо бы об этом написать.
Здесь замечу также, что Apache Ignite является в том числе распределенной СУБД с поддержкой ACID и SQL, но помимо этого имеется множество других возможностей, которые в СУБД других классов зачастую отсутствуют.

Короче из текста и таблицы выходит, что у вас 100% ACID со скоростью In-Memory БД и из CAP у вас есть все 3 пункта. Жажду подробностей.

В кулуарах слышал, что будет ACID, а в статье действительно про это нет. Какие гарантии тогда даёт Ignite?

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