Comments 5
Ждём ODBC Schema Exploration и можно будет юзать почти как обычную БД :)
UFO just landed and posted this here
Добрый день!
Проблема решается через горизонтальное масштабирование. Традиционные реляционные СУБД сложно и дорого масштабировать, и даже когда они масштабируются, они масштабируются на уровень нескольких узлов. Apache Ignite может размещаться на десятках и сотнях узлов, работать на нескольких связанных геораспределенных кластерах, размазывая IO и его издержки.
Здесь речь идет, скорее, о классических реляционных СУБД, которые обычно плохо горизонтально масштабируются и имеют ограниченные возможности обеспечения отказоустойчивости при сохранении ACID-гарантий. Если говорить о сравнении с разными классами продуктов для хранения данных, можно привести такую иллюстрацию:
Здесь замечу также, что Apache Ignite является в том числе распределенной СУБД с поддержкой ACID и SQL, но помимо этого имеется множество других возможностей, которые в СУБД других классов зачастую отсутствуют.
При использовании PDS гарантии ACID остаются в силе.
Ранее в принципе не было возможности стартовать быстро, с диска. У некоторых задач есть потребность после рестарта кластера какое-то время поработать медленно, но начать принимать запросы сразу, и после прогрева получить все преимущества распределенного in-memory. Теперь необходимость такого сценария не блокирует выбор Apache Ignite.
Обращу внимание, что важными сторонами Ignite является не только 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, но еще, например, горизонтальная масштабируемость и функционал грида. Далее, в зависимости от задачи, от платформы выбирается тот набор функций, который лучше всего подходит задаче.
Если же для меня критична скорость работы, то возникает вопрос что случится если(а так и будет) часть данных, необходимых для запроса, лежит на нодах, которые не падали, а часть на только что поднятой. Верно ли, что в таком случае время ответа будет равно времени ответа самой медленной ноды(читай реляционной БД)?
Если часть необходимых для запроса данных лежит на узле, где они еще не поднялись с диска, то они будут прочитаны с диска, время выполнения запроса будет соответствующим. Но такой запрос хотя бы можно будет выполнить. Что важнее для задачи — выполнить любой ценой или выполнить только быстро — зависит от задачи. И для того, и для другого сценария есть инструменты реализации.
В кулуарах слышал, что будет ACID, а в статье действительно про это нет. Какие гарантии тогда даёт Ignite?
Sign up to leave a comment.
Apache Ignite 2.1 — теперь со вкусом Persistence