Буду признателен за любую информацию по факту, что больше этой проблемой никто не затронут. У моих клиентов видите ли много виртуалок у разных провайдеров.
Да нет же, суть не в потребности в OLAP/columnstore.
Хотя если знаете бесплатные/opensource OLAP, способные выдержать 10к записей в секунду в 7 проекций на среднем сервере (2x Xeon E5-2620, 8x8GB RDIMM 1600 MHz) — мы его с удовольствием попробуем.
Возвращаясь к пользователям, показы баннеров/наведения мыши/клики никто не пишет в такую базу, для них отдельная система. А в приведенном примере только коэффициенты могут обновляться в почти реальном времени, и влиять на информацию в базе с профилями.
Кстати, по поводу рекомендаций вы тоже хорошо подметили, именно для них eBay использует Cassandr'у, с ее негарантированной консистентностью. Никто не утверждает, что традиционными средствами нельзя достичь того, что можно сделать с помощью nosql баз. Но всюду пихать ACID — неразумно, точно так же, как и пытаться все решить с помощью nosql.
P.S. Наша дискуссия напоминает общение фанатов iphone и android. Одни — хотят красоты и простоты из коробки, другие — хотят всего остального и побольше :)
Да, пример с билетами вполне из реальной жизни, но я о другом: реализовывать так его никто не будет. Если везде пытаться применить один подход — давно была бы одна «идеальная база данных», применимая везде и всюду, также и наоборот, разные проблемы решаются разными средствами. Например, в Redis можно делать wildcard запросы по ключам, но на практике в production этого никто не делает — у него другое назначение.
Базы eventually consistent нужны совершенно для других сценариев. Например, подсчет статистики, аналитика, системы сообщений/комментариев (да-да, если сообщение придет на 5 секунд позже — это не трагедия). Для таких систем можно добиться близкой к идеальной доступности, работоспособности в случае, когда пропадет связь внутри кластера, и консистентности в обозримом будущем для конкретно взятых данных.
Вот еще пример (тоже из реальной жизни): пускай мы храним в eventually consistent базе данных информацию поведенческих поведенческих пользователей, основанную на анализе их текущей активности. Пускай у нас есть некий алгоритм, изменяющий регрессионные коэффициенты, отвечающие за причисление пользователю тех или иных свойств/аттрибутов. И есть другая система, которая подбирает контекстную рекламу, таргетированную на определенную группу людей. В данном случае нам все-равно, что мы узнаем, что пользователь женщина, которая кликает в основном на баннеры разных оттенков голубого цвета моментально или через 5-30 секунд — это вполне приемлемое и корректное поведение. Особенно учитывая, что между событием, которое произошло и необходимостью показать баннер пройдет как раз не меньше 5 секунд.
А теперь представьте себе реализацию этой системы в синхронном хранилище.
Введение функции консистентности от времени в этом контексте также важно. Точнее даже функции вероятности консистентности в зависимости от времени с момента правки данных.
В целом согласен, хотя пример с бронированием билетов утрирован.
Понятно что падение мастера синхронно отследить не удастся, поэтому любая реальная система может быть только CP
Наличие мастера не всегда нужно, нужны только ноды, которые знают, где какой кусок шарда сейчас продублирован, и куда сейчас можно обратиться за нужными данными.
availability это непрерывная величина между 0 и 1
Тогда ведь и консистентность можно считать функцией от времени, которое прошло с момента добавления данных, нужных для выборки?
Да, согласен. Но согласно CAP-теореме strong consistency исключает либо партицирование, либо доступность.
А с помощью указанных мной и вами оговорок на сегодняшний день возможно реализовать приближенную к CAP базу данных и во многих практических кейсах это как раз то, что надо.
По поводу консистентности в Cassandra — ей подходит название eventually consistent, т.е. консистентна в какой-то момент времени в обозримом будущем.
Именно с этой оговоркой для нее можно применить и все 3 буквы из CAP.
Если верить их описанию, анализ — дело некой серверной части, которая может ответить как состав, так и коммерческое название препарата. Телефон просто отправляет туда отсканированную картинку.
Вот и меня насторожило видео, на котором они сканируют что-то, отправляют на телефон и получают результаты при том, что телефон не подключен к интернету (нет значка wifi/edge/3g), а если верить описанию — анализом занимается некий облачный сервис.
Или андроид все-таки можно подключить к интернету, не пользуясь ничем из перечисленного?
Не хочу вступать в глубокую полемику, но в big data это вполне приемлемо. Конечно, для банковских приложений таким подходом вы не воспользуетесь, но в рекламе, аналитике, пускай даже в машинном обучении — вполне.
При правильных настройках можно прийти к режиму работы «если ключ умер — значит он устаревший и неинтересный» (LRU политика).
Именно проблемы на Mt.Gox изначально привели к дестабилизации курса.
А когда на их сайте появилось заявление о прекращении работы — курс скакнул еще ниже примерно до $450/Btc.
Вероятнее всего, если информация о краже подтвердится, — курс опять поднимется, т.к. это будет означать, что причиной краха биржи стала не дырка в протоколе, а «человеческий фактор».
Хотя если знаете бесплатные/opensource OLAP, способные выдержать 10к записей в секунду в 7 проекций на среднем сервере (2x Xeon E5-2620, 8x8GB RDIMM 1600 MHz) — мы его с удовольствием попробуем.
Возвращаясь к пользователям, показы баннеров/наведения мыши/клики никто не пишет в такую базу, для них отдельная система. А в приведенном примере только коэффициенты могут обновляться в почти реальном времени, и влиять на информацию в базе с профилями.
Кстати, по поводу рекомендаций вы тоже хорошо подметили, именно для них eBay использует Cassandr'у, с ее негарантированной консистентностью. Никто не утверждает, что традиционными средствами нельзя достичь того, что можно сделать с помощью nosql баз. Но всюду пихать ACID — неразумно, точно так же, как и пытаться все решить с помощью nosql.
P.S. Наша дискуссия напоминает общение фанатов iphone и android. Одни — хотят красоты и простоты из коробки, другие — хотят всего остального и побольше :)
Базы eventually consistent нужны совершенно для других сценариев. Например, подсчет статистики, аналитика, системы сообщений/комментариев (да-да, если сообщение придет на 5 секунд позже — это не трагедия). Для таких систем можно добиться близкой к идеальной доступности, работоспособности в случае, когда пропадет связь внутри кластера, и консистентности в обозримом будущем для конкретно взятых данных.
Вот еще пример (тоже из реальной жизни): пускай мы храним в eventually consistent базе данных информацию поведенческих поведенческих пользователей, основанную на анализе их текущей активности. Пускай у нас есть некий алгоритм, изменяющий регрессионные коэффициенты, отвечающие за причисление пользователю тех или иных свойств/аттрибутов. И есть другая система, которая подбирает контекстную рекламу, таргетированную на определенную группу людей. В данном случае нам все-равно, что мы узнаем, что пользователь женщина, которая кликает в основном на баннеры разных оттенков голубого цвета моментально или через 5-30 секунд — это вполне приемлемое и корректное поведение. Особенно учитывая, что между событием, которое произошло и необходимостью показать баннер пройдет как раз не меньше 5 секунд.
А теперь представьте себе реализацию этой системы в синхронном хранилище.
Введение функции консистентности от времени в этом контексте также важно. Точнее даже функции вероятности консистентности в зависимости от времени с момента правки данных.
Наличие мастера не всегда нужно, нужны только ноды, которые знают, где какой кусок шарда сейчас продублирован, и куда сейчас можно обратиться за нужными данными.
Тогда ведь и консистентность можно считать функцией от времени, которое прошло с момента добавления данных, нужных для выборки?
А с помощью указанных мной и вами оговорок на сегодняшний день возможно реализовать приближенную к CAP базу данных и во многих практических кейсах это как раз то, что надо.
Именно с этой оговоркой для нее можно применить и все 3 буквы из CAP.
Или андроид все-таки можно подключить к интернету, не пользуясь ничем из перечисленного?
При правильных настройках можно прийти к режиму работы «если ключ умер — значит он устаревший и неинтересный» (LRU политика).
В будущем хотелось бы и выходы из БД, которые его поддерживают.
А когда на их сайте появилось заявление о прекращении работы — курс скакнул еще ниже примерно до $450/Btc.
Вероятнее всего, если информация о краже подтвердится, — курс опять поднимется, т.к. это будет означать, что причиной краха биржи стала не дырка в протоколе, а «человеческий фактор».