Comments 22
|в противовес привычной RDBMS-системе класс NoSQL-решений не может обеспечить полную поддержку ACID.
Oracle утверждает, что их решение выдерживает ACID: www.oracle.com/us/products/database/nosql/overview/index.html. Сам ничего не скажу про их базу, не сталкивался.
|Обеспечение надёжности в рамках одного сервера
К сожалению не улавливаю прямой связи надежности с последовательным и случайным чтением. Логи, да, согласен.
Oracle утверждает, что их решение выдерживает ACID: www.oracle.com/us/products/database/nosql/overview/index.html. Сам ничего не скажу про их базу, не сталкивался.
|Обеспечение надёжности в рамках одного сервера
К сожалению не улавливаю прямой связи надежности с последовательным и случайным чтением. Логи, да, согласен.
Marklogic — это NoSQL база данных с полным ACID (как утверждаю разрабы)
Очень интересно услышать «авторитетное» мнение того, что поставил "-1" моему сообщению. Рискну уйти далеко в минус… но вы видимо считаете, что уровень ваших знаний по теме позволяет вам так делать без объяснения причин? Вы тесно знакомы с Marklogic? Вы основываетесь на инфе из вики или на общих «так сделать нельзя...» делая это?
Из сообщения ниже…! не спорю с вами, просто описываю что знаю :)
> нет принципиальных ограничений сделать acid даже в nosql на одной машине.
В ML это работает и вне одной машины
> Но это сильно бьёт по скорости записи, что использовать nosql становится невыгодно
В ML есть «некоторые» :) проблемы с производительность, но также там есть еще 100500 способов оптимизации для её повышения. А некоторым людям, читая мои слова следует понимать, что эти методы не очевидны если вы не знакомы или плохо знакомы с этой DB и не имея достаточных знаний не стоит делать вывод о том, что это все равно будет работать страшно медленно… Да, ML это не покажет сверх высокую производительность, но его с лихвой хватит, чтобы покрыть большинство задач имея «NoSQL» данные.
Из сообщения ниже…! не спорю с вами, просто описываю что знаю :)
> нет принципиальных ограничений сделать acid даже в nosql на одной машине.
В ML это работает и вне одной машины
> Но это сильно бьёт по скорости записи, что использовать nosql становится невыгодно
В ML есть «некоторые» :) проблемы с производительность, но также там есть еще 100500 способов оптимизации для её повышения. А некоторым людям, читая мои слова следует понимать, что эти методы не очевидны если вы не знакомы или плохо знакомы с этой DB и не имея достаточных знаний не стоит делать вывод о том, что это все равно будет работать страшно медленно… Да, ML это не покажет сверх высокую производительность, но его с лихвой хватит, чтобы покрыть большинство задач имея «NoSQL» данные.
Рискну уйти далеко в минус, но вы, видимо, считаете, что уровень ваших знаний по теме позволяет вам утверждать что-то, что расходится с общепринятым, а также и обсуждаемым в статье мнением (конкретно — что NoSQL решения не могут в полной мере обеспечить ACID). Утверждать просто так, не утруждая себя объяснениями, доказательствами и ссылками?
Лично мне, например, очень интерессно было бы почитать более развернутый комментарий, который подтверждает ваше мнение, а не холиварный вброс.
На всякий случай — я вас не минусовал.
Лично мне, например, очень интерессно было бы почитать более развернутый комментарий, который подтверждает ваше мнение, а не холиварный вброс.
На всякий случай — я вас не минусовал.
5 лет fulltime разработки под ML думаю достаточный уровень.
Вы уж извините, но я не спорил ни с кем, просто написал, что такая db есть и стало обидно за минус.
> Утверждать просто так, не утруждая себя объяснениями, доказательствами и ссылками?
Поставивший мне минус не утруждал себя в знаниях ставя его…
> Лично мне, например, очень интерессно было бы почитать более развернутый комментарий, который подтверждает ваше мнение, а не холиварный вброс.
Что является доказательством правдивости моих слов? Вы им не верите? Их соответствие докам? Так может сразу идти и почитать эти доки? Вот мнение архитектора ML www.youtube.com/watch?v=3mOCOrFQ_N0 его будет достаточно? Вот тут www.marklogic.com можно найти его и еще много интересного про ML.
www.information-age.com/technology/information-management/123458126/putting-enterprise-nosql-acid-ambiguity-out
Видимо проблема в том, что я не составил тот самый google запрос (https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#newwindow=1&q=marklogic%20acid), который выдал бы подтверждения моих слов, если их не достаточно.
Вы уж извините, но я не спорил ни с кем, просто написал, что такая db есть и стало обидно за минус.
> Утверждать просто так, не утруждая себя объяснениями, доказательствами и ссылками?
Поставивший мне минус не утруждал себя в знаниях ставя его…
> Лично мне, например, очень интерессно было бы почитать более развернутый комментарий, который подтверждает ваше мнение, а не холиварный вброс.
Что является доказательством правдивости моих слов? Вы им не верите? Их соответствие докам? Так может сразу идти и почитать эти доки? Вот мнение архитектора ML www.youtube.com/watch?v=3mOCOrFQ_N0 его будет достаточно? Вот тут www.marklogic.com можно найти его и еще много интересного про ML.
www.information-age.com/technology/information-management/123458126/putting-enterprise-nosql-acid-ambiguity-out
Видимо проблема в том, что я не составил тот самый google запрос (https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#newwindow=1&q=marklogic%20acid), который выдал бы подтверждения моих слов, если их не достаточно.
> 5 лет fulltime разработки под ML думаю достаточный уровень.
Понимаете, мне, как человеку где-то в интернете, неизвестны ни ваш опыт, ни ваши достижения, ни ваши знания. Именно поэтому я и написал, что если вы утверждаете что-то, что резко контрастирует с обсуждаемой статьей, неплохо бы это что-то как-то подтвердить.
> Что является доказательством правдивости моих слов? Вы им не верите? Их соответствие докам? Так может сразу идти и почитать эти доки?
Вы только не обижайтесь, но — не верю. Я любым словам не верю. Более того, я самостоятельно проведенным тестам/измерениям не верю, пока не проведу их повторно в других условиях (это если мы о нюансах работы СУБД говорим).
Да, можно и доки почитать. Опять же мне, как человеку не в теме, неизвестно какие именно документы подтверждают ваши слова. А значит, надо искать, сопоставлять, анализировать. Хорошее занятие, безусловно, только требует времени которое не всегда в избытке. Да и подтверждать аргументами свою точку зрения — это скорее задача человека, который такую точку зрения высказал.
Отдельное спасибо за ссылки, особенно за ролик на ютубе — как раз просматриваю… тоесть, прослушиваю :)
Понимаете, мне, как человеку где-то в интернете, неизвестны ни ваш опыт, ни ваши достижения, ни ваши знания. Именно поэтому я и написал, что если вы утверждаете что-то, что резко контрастирует с обсуждаемой статьей, неплохо бы это что-то как-то подтвердить.
> Что является доказательством правдивости моих слов? Вы им не верите? Их соответствие докам? Так может сразу идти и почитать эти доки?
Вы только не обижайтесь, но — не верю. Я любым словам не верю. Более того, я самостоятельно проведенным тестам/измерениям не верю, пока не проведу их повторно в других условиях (это если мы о нюансах работы СУБД говорим).
Да, можно и доки почитать. Опять же мне, как человеку не в теме, неизвестно какие именно документы подтверждают ваши слова. А значит, надо искать, сопоставлять, анализировать. Хорошее занятие, безусловно, только требует времени которое не всегда в избытке. Да и подтверждать аргументами свою точку зрения — это скорее задача человека, который такую точку зрения высказал.
Отдельное спасибо за ссылки, особенно за ролик на ютубе — как раз просматриваю… тоесть, прослушиваю :)
нет принципиальных ограничений сделать acid даже в nosql на одной машине. Но это сильно бьёт по скорости записи, что использовать nosql становится невыгодно. Даже можно сделать «зеркалирование» с синхронным коммитом, но это еще медленнее.
Я бы отметил, что решение в рамках одного сервера сильно проигрывает в отказоустойчивости и высокой доступности, — и вряд ли может называться NoSQL-решением — хотя это лишь вопрос терминологии. А синхронное зеркалирование достигает цели высокой консистентности данных, но ухудшает одновременную доступность всего кластера, т.к. высокий поток на запись загружает одновременно все сервера. К тому же всё равно нужно будет продумывать задачи по вводу в строй упавшей ноды и прочие.
По поводу консистентности в Cassandra — ей подходит название eventually consistent, т.е. консистентна в какой-то момент времени в обозримом будущем.
Именно с этой оговоркой для нее можно применить и все 3 буквы из CAP.
Именно с этой оговоркой для нее можно применить и все 3 буквы из CAP.
eventually consistent это оксюморон.
1) Если частота записей больше, чем время, которое необходимо до получения консистентного состояния в кластере, то eventually consistent превращается в permanently inconsistent.
2) eventually consistent не дает абсолютно никаких гарантий, в отличие от strong consistency.
1) Если частота записей больше, чем время, которое необходимо до получения консистентного состояния в кластере, то eventually consistent превращается в permanently inconsistent.
2) eventually consistent не дает абсолютно никаких гарантий, в отличие от strong consistency.
Да, согласен. Но согласно CAP-теореме strong consistency исключает либо партицирование, либо доступность.
А с помощью указанных мной и вами оговорок на сегодняшний день возможно реализовать приближенную к CAP базу данных и во многих практических кейсах это как раз то, что надо.
А с помощью указанных мной и вами оговорок на сегодняшний день возможно реализовать приближенную к CAP базу данных и во многих практических кейсах это как раз то, что надо.
Partition tolerance это тоже оксюморон ;)
Банальная ситуация — сервис по продаже билетов в кино, на одну ноду приходит команда, которая бронирует билет и тут рвется связь. Вторая нода не знает что билет забронирован, тут приложение обращается ко второй ноде и пытается забронировать тот же билет.
Тут два варианта:
1) если билет таки удастся забронировать, то после восстановления связи будет две брони на одно место.
2) не писать пока нет связи с мастером, то ест сервис в одной из частей не доступен.
Даже если система ждет ответа е от всех нод, а от подмножества, то сеть может поделиться по границе подмножества. Короче честный partition tolerance без strong consistency сделать нельзя.
Это приводит к неутешительному выводу: для честного partition tolerance нужно иметь мастер-ноду, куда будет приходить вся запись, а также синхронный коммит, чтобы в случае падения мастера можно было переключиться на другу ноду (сделать её мастером). Понятно что падение мастера синхронно отследить не удастся, поэтому любая реальная система может быть только CP.
Кстати если почитать обсуждения cap теоремы, то для устранения этого «бага» понятие consistency поменяли, и оно больше похоже на atomicity в ACID.
Но не все так плохо. Если consistency и partition tolerance это бинарные понятия. Они или есть или нет. То availability это непрерывная величина между 0 и 1, причем существует она не сама по себе, а еще и зависит от инфраструктуры. Предположим что мы смогли инфраструктурно добиться доступности серверов бд в 99,99% и время на продвижение нового мастера менее 1 секунды. Это значит что приложение может просто повторять попытки записи в базу в течение и для пользователя система будет доступна на те же 99,99%.причем это легко делается на sql server.
Банальная ситуация — сервис по продаже билетов в кино, на одну ноду приходит команда, которая бронирует билет и тут рвется связь. Вторая нода не знает что билет забронирован, тут приложение обращается ко второй ноде и пытается забронировать тот же билет.
Тут два варианта:
1) если билет таки удастся забронировать, то после восстановления связи будет две брони на одно место.
2) не писать пока нет связи с мастером, то ест сервис в одной из частей не доступен.
Даже если система ждет ответа е от всех нод, а от подмножества, то сеть может поделиться по границе подмножества. Короче честный partition tolerance без strong consistency сделать нельзя.
Это приводит к неутешительному выводу: для честного partition tolerance нужно иметь мастер-ноду, куда будет приходить вся запись, а также синхронный коммит, чтобы в случае падения мастера можно было переключиться на другу ноду (сделать её мастером). Понятно что падение мастера синхронно отследить не удастся, поэтому любая реальная система может быть только CP.
Кстати если почитать обсуждения cap теоремы, то для устранения этого «бага» понятие consistency поменяли, и оно больше похоже на atomicity в ACID.
Но не все так плохо. Если consistency и partition tolerance это бинарные понятия. Они или есть или нет. То availability это непрерывная величина между 0 и 1, причем существует она не сама по себе, а еще и зависит от инфраструктуры. Предположим что мы смогли инфраструктурно добиться доступности серверов бд в 99,99% и время на продвижение нового мастера менее 1 секунды. Это значит что приложение может просто повторять попытки записи в базу в течение и для пользователя система будет доступна на те же 99,99%.причем это легко делается на sql server.
В целом согласен, хотя пример с бронированием билетов утрирован.
Наличие мастера не всегда нужно, нужны только ноды, которые знают, где какой кусок шарда сейчас продублирован, и куда сейчас можно обратиться за нужными данными.
Тогда ведь и консистентность можно считать функцией от времени, которое прошло с момента добавления данных, нужных для выборки?
Понятно что падение мастера синхронно отследить не удастся, поэтому любая реальная система может быть только CP
Наличие мастера не всегда нужно, нужны только ноды, которые знают, где какой кусок шарда сейчас продублирован, и куда сейчас можно обратиться за нужными данными.
availability это непрерывная величина между 0 и 1
Тогда ведь и консистентность можно считать функцией от времени, которое прошло с момента добавления данных, нужных для выборки?
В целом согласен, хотя пример с бронированием билетов утрирован.
Почему утрирован? Нормальный вполне пример, подобные системы в кинотеатрах и на вокзалах стоят.
Наличие мастера не всегда нужно, нужны только ноды, которые знают, где какой кусок шарда сейчас продублирован, и куда сейчас можно обратиться за нужными данными.
Для чтения мастер не нужен, а для записи нужен. У multimaster в общем случае возникают проблемы с consistency, когда параллельно две транзакции в разные мастеры пишут по одним и тем же ключам.
Тогда ведь и консистентность можно считать функцией от времени, которое прошло с момента добавления данных, нужных для выборки?
Считать можно вообще что угодно. Но смысла в этом обычно нет. Strong consistency это гарантия для приложения, eventual consistency это просто слова, которые ничего не дают приложению.
На примере той же продажи билетов. Если есть eventual consistency в 10 секунд, то как это поможет не продать более одного билета на одно место?
Если eventual consistency имеет такое маленькое значение, что в реальности наблюдатель никогда не увидит кластер в неконсистентном состоянии, то в чем разница со strong consistency? Да и стоить это будет одинаково.
Да, пример с билетами вполне из реальной жизни, но я о другом: реализовывать так его никто не будет. Если везде пытаться применить один подход — давно была бы одна «идеальная база данных», применимая везде и всюду, также и наоборот, разные проблемы решаются разными средствами. Например, в Redis можно делать wildcard запросы по ключам, но на практике в production этого никто не делает — у него другое назначение.
Базы eventually consistent нужны совершенно для других сценариев. Например, подсчет статистики, аналитика, системы сообщений/комментариев (да-да, если сообщение придет на 5 секунд позже — это не трагедия). Для таких систем можно добиться близкой к идеальной доступности, работоспособности в случае, когда пропадет связь внутри кластера, и консистентности в обозримом будущем для конкретно взятых данных.
Вот еще пример (тоже из реальной жизни): пускай мы храним в eventually consistent базе данных информацию поведенческих поведенческих пользователей, основанную на анализе их текущей активности. Пускай у нас есть некий алгоритм, изменяющий регрессионные коэффициенты, отвечающие за причисление пользователю тех или иных свойств/аттрибутов. И есть другая система, которая подбирает контекстную рекламу, таргетированную на определенную группу людей. В данном случае нам все-равно, что мы узнаем, что пользователь женщина, которая кликает в основном на баннеры разных оттенков голубого цвета моментально или через 5-30 секунд — это вполне приемлемое и корректное поведение. Особенно учитывая, что между событием, которое произошло и необходимостью показать баннер пройдет как раз не меньше 5 секунд.
А теперь представьте себе реализацию этой системы в синхронном хранилище.
Введение функции консистентности от времени в этом контексте также важно. Точнее даже функции вероятности консистентности в зависимости от времени с момента правки данных.
Базы eventually consistent нужны совершенно для других сценариев. Например, подсчет статистики, аналитика, системы сообщений/комментариев (да-да, если сообщение придет на 5 секунд позже — это не трагедия). Для таких систем можно добиться близкой к идеальной доступности, работоспособности в случае, когда пропадет связь внутри кластера, и консистентности в обозримом будущем для конкретно взятых данных.
Вот еще пример (тоже из реальной жизни): пускай мы храним в eventually consistent базе данных информацию поведенческих поведенческих пользователей, основанную на анализе их текущей активности. Пускай у нас есть некий алгоритм, изменяющий регрессионные коэффициенты, отвечающие за причисление пользователю тех или иных свойств/аттрибутов. И есть другая система, которая подбирает контекстную рекламу, таргетированную на определенную группу людей. В данном случае нам все-равно, что мы узнаем, что пользователь женщина, которая кликает в основном на баннеры разных оттенков голубого цвета моментально или через 5-30 секунд — это вполне приемлемое и корректное поведение. Особенно учитывая, что между событием, которое произошло и необходимостью показать баннер пройдет как раз не меньше 5 секунд.
А теперь представьте себе реализацию этой системы в синхронном хранилище.
Введение функции консистентности от времени в этом контексте также важно. Точнее даже функции вероятности консистентности в зависимости от времени с момента правки данных.
Да, пример с билетами вполне из реальной жизни, но я о другом: реализовывать так его никто не будет.
А как будет?
Например, подсчет статистики, аналитика, системы сообщений/комментариев
Для этого уже давно есть материализованные\индексированные представления. В SQL Server появились updateable columnstore индексы. А для больших объемов также давно есть OLAP системы.
А теперь представьте себе реализацию этой системы в синхронном хранилище.
Представил, а в чем проблема? Рекомендации ведь не будут на каждый клик пересчитываться, иначе мощностей никаких не хватит. А писать клики в permanent inconsistent (eventual consistent) базу или в обычную с ACID гарантиями — разницы нет, а можно вообще сохранять на локальном диске веб-сервера, а потом прогонять через механизм расчета рекомендаций.
По сути нет ни одного сценария, где eventual consistent было бы выгоднее, чем strong consistent.
Да нет же, суть не в потребности в OLAP/columnstore.
Хотя если знаете бесплатные/opensource OLAP, способные выдержать 10к записей в секунду в 7 проекций на среднем сервере (2x Xeon E5-2620, 8x8GB RDIMM 1600 MHz) — мы его с удовольствием попробуем.
Возвращаясь к пользователям, показы баннеров/наведения мыши/клики никто не пишет в такую базу, для них отдельная система. А в приведенном примере только коэффициенты могут обновляться в почти реальном времени, и влиять на информацию в базе с профилями.
Кстати, по поводу рекомендаций вы тоже хорошо подметили, именно для них eBay использует Cassandr'у, с ее негарантированной консистентностью. Никто не утверждает, что традиционными средствами нельзя достичь того, что можно сделать с помощью nosql баз. Но всюду пихать ACID — неразумно, точно так же, как и пытаться все решить с помощью nosql.
P.S. Наша дискуссия напоминает общение фанатов iphone и android. Одни — хотят красоты и простоты из коробки, другие — хотят всего остального и побольше :)
Хотя если знаете бесплатные/opensource OLAP, способные выдержать 10к записей в секунду в 7 проекций на среднем сервере (2x Xeon E5-2620, 8x8GB RDIMM 1600 MHz) — мы его с удовольствием попробуем.
Возвращаясь к пользователям, показы баннеров/наведения мыши/клики никто не пишет в такую базу, для них отдельная система. А в приведенном примере только коэффициенты могут обновляться в почти реальном времени, и влиять на информацию в базе с профилями.
Кстати, по поводу рекомендаций вы тоже хорошо подметили, именно для них eBay использует Cassandr'у, с ее негарантированной консистентностью. Никто не утверждает, что традиционными средствами нельзя достичь того, что можно сделать с помощью nosql баз. Но всюду пихать ACID — неразумно, точно так же, как и пытаться все решить с помощью nosql.
P.S. Наша дискуссия напоминает общение фанатов iphone и android. Одни — хотят красоты и простоты из коробки, другие — хотят всего остального и побольше :)
По порядку:
1) Скорость записей упирается в диски. Хотя я даже на обычном SQL Server делал 10к записей в секунду пачками по 5к в транзакции. Уровень надежности не ниже записи в любую nosql базу.
2) Рекомендации не пересчитывают на каждое событие ибо это очень дорогая операция, которая далеко не в скорость записи упирается. А влияние одного события на рекомендации ничтожное. Я делал системы рекомендаций и прекрасно знаю как они работают.
3) В принципе существуют системы для онлайн пересчета аналитики по событиям, им необязательно писать каждое событие на диск.
4) По поводу ebay не знаю, возможно при их объемах и нагрузке Cassandra помогает. Но далеко не каждый проект вырастает до масштабов ebay, а nosql на старте проекта только мешает. Из за отсутствия гарантий приходится или сильно больше кода писать, или мириться с багами.
5) Использование NoSQL, там где прекрасно справится РСУБД, очень напоминает предварительную оптимизацию, которая, как известно, зло. Причем, как ни странно, NoSQL требует больше ресурсов (много памяти и несколько серверов), по сравнению с какойнить бесплатной РСУБД.
Я знаю что есть типовые сценарии, для которых NoSQL работает лучше РСУБД. Но я бы не брался 100% утверждать на старте проекта, что именно такой сценарий будет в приложении
1) Скорость записей упирается в диски. Хотя я даже на обычном SQL Server делал 10к записей в секунду пачками по 5к в транзакции. Уровень надежности не ниже записи в любую nosql базу.
2) Рекомендации не пересчитывают на каждое событие ибо это очень дорогая операция, которая далеко не в скорость записи упирается. А влияние одного события на рекомендации ничтожное. Я делал системы рекомендаций и прекрасно знаю как они работают.
3) В принципе существуют системы для онлайн пересчета аналитики по событиям, им необязательно писать каждое событие на диск.
4) По поводу ebay не знаю, возможно при их объемах и нагрузке Cassandra помогает. Но далеко не каждый проект вырастает до масштабов ebay, а nosql на старте проекта только мешает. Из за отсутствия гарантий приходится или сильно больше кода писать, или мириться с багами.
5) Использование NoSQL, там где прекрасно справится РСУБД, очень напоминает предварительную оптимизацию, которая, как известно, зло. Причем, как ни странно, NoSQL требует больше ресурсов (много памяти и несколько серверов), по сравнению с какойнить бесплатной РСУБД.
Я знаю что есть типовые сценарии, для которых NoSQL работает лучше РСУБД. Но я бы не брался 100% утверждать на старте проекта, что именно такой сценарий будет в приложении
[Удалено] Промахнулся
Я просто оставлю это здесь. Причащайтесь)
www.orientechnologies.com/orientdb-vs-mongodb/
www.orientechnologies.com/orientdb-vs-mongodb/
Sign up to leave a comment.
Разбираем ACID по буквам в NoSQL