Здравствуйте, itslave, Вы писали:

I>Весь топик не асилил, но закат NoSQL и появление NewSQL уже обсудили?

Вот да, меня тоже это гложет.

Здравствуйте, ·, Вы писали:

НС>>Но если ты настаиваешь — тогда на этом и закончим, потому что аргументов по делу у тебя все равно не осталось.
·>Цитата не утверждает, что ES не nosql, а то что зависит от того что под этим понимать (терминология) и юзкейсов.

Внезапно, это ровно тоже самое, что написал и я.

·>И там, и там оно используется для индексации и запросов к неструктурированной текстовой информации.

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

Здравствуйте, ·, Вы писали:

·>Ты так говоришь, как будто нарушать ACID что-то плохое.

Зависит от задач.

·> Ведь ты слыхал об isolation levels. СУБД нарушают I и не только во всю.

Мы уже обсудили здесь, в чем разница sql и nosql в этом разрезе.

НС>>А вот в банках такое уже не прокатит.
·>А что прокатит?

РСУБД, распределенные транзакции и прочаятяжеловесная и дорогая хрень.

НС>>Еще раз — речь не про масштабные сбои, что форс-мажор, а про периодически слуяающиеся ошибки в конкретных единичных транзакциях. Где то такие ошибки допустимы, если они случаются нечасто, а где то нет.
·>Да не случаются некие магические "ошибки" в nosql.

В nosql не случаются, случаются в системах их использующих. И ничего магического в них нет, а есть куча рукопашного тюнинга типа того что описывал Cyberax (цена которого намного превышает потенциальную цену лицензий sql из большой тройки).

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Но если ты настаиваешь — тогда на этом и закончим, потому что аргументов по делу у тебя все равно не осталось.
НС>·>Цитата не утверждает, что ES не nosql, а то что зависит от того что под этим понимать (терминология) и юзкейсов.
НС>Внезапно, это ровно тоже самое, что написал и я.
Ок. Пусть так. Осталось разобраться почему в ELK оно nosql, а в SO — нет.

НС>·>И там, и там оно используется для индексации и запросов к неструктурированной текстовой информации.
НС>Не совсем так. В ELK хранение информации — одно из основных функций. А вот в ES — совершенно необязательно. Можно вообще хранение в ES не использовать и хранить только индексы и ключ, а данные доставать по ключу из внешнего источника.
В ELK информация хранится в логах (golden source). А logstash и ES их парсят и индексируют, для того, чтобы они визуализровались в Kibana за вменяемое время. Вряд ли хоть сколько-нибудь ценные логи грохают лишь на том основании, что они живут где-то в визуализаторе. Особо ценные логи на ленты пишут и в сейф кладут.

C>>>Можно сказать по-другому: РСУБД остались там, где производительность не важна или нет больших объёмов данных.
S>>Visa вряд ли nosql решения использует. Vertica еще есть.
C>Amazon использует nosql везде, Google их использует ещё более везде.

C>Чтобы был понятен объём — в этом году хранилище данных Амазона выдерживало 250 миллионов запросов в секунду.

Чтобы еще был понятен объем, они сначала вложили какое-то невменяемое количество денег и ресурсов в инфраструктуру всего этого дела. И это заслуга не NoSQL, а архитекторов и разработчиков компании. Аналогично с Гуглом.

На 2 ошибки выживших приходятся сотни сгинувших.

Здравствуйте, ·, Вы писали:

·>Ок. Пусть так. Осталось разобраться почему в ELK оно nosql, а в SO — нет.

Т.е. по остальным моментам вопросов не осталось, только по ELK?

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

Вот ты прицепился то к Кибане. Кибана это не единственный компонент ELK, а в контексте разговора вообще несущественный.
Еще раз, а то приходится по несколько раз все повторять. ES сам по себе может быть использован как угодно, может вообще не хранить данные. А вот ES в составе ELK не может, потому что logstash парсит данные на лету, не создавая промежуточных персистентных логов. А значит ES, помимо основной обязанности, выступает тут и как хранилище собранной из разных источников и приведенной к единой структуре инфы, поэтому его, в том числе, можно назвать и nosql, хотя это тоже будет сильно натянутым. А вот ES нельзя, потому что функция хранения там необязательная. Андестенд? Или опять песню про визуализаторы на бис?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Ты так говоришь, как будто нарушать ACID что-то плохое.
НС>Зависит от задач.
Верно. Асидность перпендикулярна сиквельности. ACID можно и на основе nosql построить, если нужно.

НС>·> Ведь ты слыхал об isolation levels. СУБД нарушают I и не только во всю.
НС>Мы уже обсудили здесь, в чем разница sql и nosql в этом разрезе.
Подытож, а то я уже запутался кто на чём сошелся.

НС>>>А вот в банках такое уже не прокатит.
НС>·>А что прокатит?
НС>РСУБД, распределенные транзакции и прочаятяжеловесная и дорогая хрень.
Ты, наверное, про ретейл и прочую мелочь. Там ещё да, но до поры, до времени, там ещё даже кобол и мейнфреймы живут, и не потому что надо, а потому что традиция, а нагрузки невелики, тяжеловесность ещё тянет. А вот в инвест-банках такое было в своё время, но уже давно не так.

НС>>>Еще раз — речь не про масштабные сбои, что форс-мажор, а про периодически слуяающиеся ошибки в конкретных единичных транзакциях. Где то такие ошибки допустимы, если они случаются нечасто, а где то нет.
НС>·>Да не случаются некие магические "ошибки" в nosql.
НС>В nosql не случаются, случаются в системах их использующих. И ничего магического в них нет, а есть куча рукопашного тюнинга типа того что описывал Cyberax (цена которого намного превышает потенциальную цену лицензий sql из большой тройки).
Как будто рсубд тюнить не надо и "магия" не случается. Не понимаю твоё возражение. Оно применимо к любому хоть сколько-либо сложному софту.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Ок. Пусть так. Осталось разобраться почему в ELK оно nosql, а в SO — нет.
НС>Т.е. по остальным моментам вопросов не осталось, только по ELK?
Да какие тут вопросы... сошлись на различной терминологии.

НС>·>Вряд ли хоть сколько-нибудь ценные логи грохают лишь на том основании, что они живут где-то в визуализаторе. Особо ценные логи на ленты пишут и в сейф кладут.
НС>Вот ты прицепился то к Кибане. Кибана это не единственный компонент ELK, а в контексте разговора вообще несущественный.
НС>Еще раз, а то приходится по несколько раз все повторять. ES сам по себе может быть использован как угодно, может вообще не хранить данные. А вот ES в составе ELK не может, потому что logstash парсит данные на лету, не создавая промежуточных персистентных логов. А значит ES, помимо основной обязанности, выступает тут и как хранилище собранной из разных источников и приведенной к единой структуре инфы, поэтому его, в том числе, можно назвать и nosql, хотя это тоже будет сильно натянутым. А вот ES нельзя, потому что функция хранения там необязательная. Андестенд? Или опять песню про визуализаторы на бис?
Это опять же зависит от конфигурации. Если это логи посещения веб-сайта, то действительно всем плевать и их можно не персистить. А вот логи каких-нибудь финансовых операций будут персиститься и храниться N лет в сейфе, иначе аудит не пройдёшь и бизнес не сможешь вести. Поэтому такая твоя классификация на nosql-ность какая-то странная, зависит от характера конкретных данных и погоды на марсе. Если я вдруг возьму postgres и буду его разворачивать на временных узлах в облаке для процессинга каких-то промежуточных результатов и выкидывать в конце — он от этого перестанет быть рсубд?
По-моему, nosql это в первую очередь системы хранения, индексирования и запросов по нереляционным данным, т.е. нереляционные базы данных. А уж что это за данные — лайки котиков, заказы на холодильники или валютные ордера — не важно.

Здравствуйте, ·, Вы писали:

·>Это опять же зависит от конфигурации. Если это логи посещения веб-сайта, то действительно всем плевать и их можно не персистить. А вот логи каких-нибудь финансовых операций будут персиститься и храниться N лет в сейфе, иначе аудит не пройдёшь и бизнес не сможешь вести.

Это не имеет отношения к ELK.

Здравствуйте, ·, Вы писали:

НС>>·>Ты так говоришь, как будто нарушать ACID что-то плохое.
НС>>Зависит от задач.
·>Верно. Асидность перпендикулярна сиквельности.

Де-факто — нет. Де-факто — есть хорошая корреляция между сиквельностью и нормальной поддержкой ACID.

·>Как будто рсубд тюнить не надо и "магия" не случается.

Тюнинг запросов и собственная подсистема обеспечения изоляции по сложности и стоимости отличаются на несколько порядков.

Здравствуйте, GarryIV, Вы писали:

GIV>Кстати Google Spanner это SQL или NoSQL?
Это newsql

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>И ты где-то наблюдал в достаточном кол-ве у новичков NoSQL?
НС>Да хоть попой ешь. У меня вон в одном из унаследованных проектов, который проще закопать чем допилить, монга.

Так попой или в одном? ))
Я-то не абсолютизировал.

Изначально Монга — это, грубо, сетевое файловое хранилище для документов, обладающее встроенной абстракцией вокруг горизонтального масштабирования.
Т.е., для новичка это замена сетевого диска, но не замена СУБД.
И если там такой сценарий — т.е. без связей, требующих целостность м/у самими документами, то ничего военного в этом нет.

Скорее всего, твоё "проще закопать" случилось по целой совокупности причин, чем по причине одной Монги, не?

"Проще закопать" — это ж про трудоёмкость, когда речь обычно о большом количестве ошибок, где ни одна из них не является критической, но критическим является их кол-во.

Ну или еще критическим может быть вопрос совместимости стеков технологий у подсистем объемлющей системы.
Это тоже немного перпендикулярно обсуждаемому SQL vs NoSQL.

Здравствуйте, Ops, Вы писали:

Ops>Это если рандом.

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


Ops>Но подозреваю, что реальные системы не совсем случайно работают, и может возникнуть ситуация, когда несколько потоков висят заметно долго.

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


V>>Т.е. вероятность того, что поток не продвинется на следующем такте очень быстро стремится к 0-лю с каждым заходом на новый круг.
Ops>Формулировка — . Случайное событие не зависит от предыдущих случайных событий.

Да ладно.
Формулировка ж из классики жанра — как лакмусовая бумажка для выявления понимающих второй закон термодинамики. ))

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

Т.е., чтобы получить, допустим, на 10-м обороте алгоритма вероятность ¹/₂, мы сначала должны были оказаться на 9-м обороте с вероятностью (¹/₂)⁹.
Обратив на этом обороте время, получается такой забавный трюк, что вероятность застревания в ближайшем будущем в 256 раз больше вероятности застревания в прошлом. ))
Ну и всё, собсно.
Иначе бы энтропия не росла.

Еще важный момент: в хороших lock-free алгоритмах (плохими не пользуюсь), чем больше нагрузка, тем меньше вероятность столкновения, бо данные забираются потребителем "пачками". Т.е. потребитель потенциально конфликтует (с некоторой небольшой вероятностью) лишь на каждый N-й передаваемый ему элемент, где N при увеличении нагрузки растёт. Т.е. мало того, что вероятность столкновений при увеличении нагрузки резко падает, так еще резко падает как общее кол-во interlocked-операций, так и общая нагрузка на механизм поддержания когерентности кеша. В моих тестах под нагрузкой межпоточные очереди по схеме "один источник — один приёмник" показывали до 20-ти раз увеличение быстродействия от средней нагрузки, сверху этого показывали отсуствие даже единичных конфликтов долгими часами. По схеме "много источников — один приёмник" показывали более частые конфликты, но всё-равно — один лишний оборот на тысячи элементов. Т.е. в пересчёте на элемент ни о чём.


Ops>Но с тем, что ты хотел сказать, пусть и получилось криво, в принципе согласен, с предыдущей оговоркой.

Оговоркой? ))
Если бы вероятность изменялась на каждом шаге, то ф-ия не была бы степенной.
Некуда тут вставлять оговорку.

Здравствуйте, IB, Вы писали:

V>>А если система принципиально способна давать ответы со скоростью их поступления, и если кривая быстродействия положительная (а она обязана быть положительной у грамотно спроектированной системы) — там "класть" физически нечего. Нет механизма "кладки".
IB>Ты серьезно утверждаешь, что NoSQL имеет бесконечную производительность? Типа dev/null ?

Я серьёзно утверждал нечто другое:

"Положить" что-либо можно лишь из-за разности быстродействия подсистем одной системы при наблюдающейся отрицательной кривой быстродействия в зависимости от нагрузки.

IB>Огонь, жги дальше )))

Пффф...
Жесть — это когда претендующий на специалиста по серверным СУБД (ключевое "серверным"), настолько злостно плавает в азах ТМО/СМО.
Злостно — потому что вместо того, чтобы спросить, опять торопится "клеймить".
Ты неисправим. ))

Кароч, левая часть формулы Литтла должна отвечать неравенству >= по мере продвижения запросов м/у подсистемами комплексной системы, тогда гарантируется конечность длины очередей на всех участках комплексной системы.

Для тех кто в танке: достаточно достичь мгновенной плотности обработки запросов в целом по системе не меньшей, чем максимальная ожидаемая плотность входящих в самую первую подсистему запросов и ву а ля. (Для тех, кто вовсе в "Армате" — последнее переводится в банальную пропускную способность сети через среднюю длину запросов в байтах + длину служебной инфы протокола).

Т.е. речь всегда не о мифической "бесконечности", разумеется, а лишь о системе соблюдающихся неравенств.

Например, в моей области (которое тоже сплошное ТМО/СМО) порой используется банальный подстраиваемый throttling + прочие разновидности квотирования для целей выравнивания производительности подсистем. Иначе в какую-нить "Чёрную Пятницу" ресурсы быстро исчерпаются из-за перекоса и всё тупо ляжет.

Здравствуйте, ·, Вы писали:

·> Ничего не говорящие факты меня не интересуют.
Совершенно верно, меня тоже. И по скольку факт не использования амазоном РСУБД ничего не говорит, то он меня и не интересует.

·>Не говори за всех. Киберакс писал. Если ты хочешь знать, то просто прочитай.
Он возможно знает чуть больше, но он тоже свечку не держал и решение не принимал, поэтому достоверность его данных не сильно отличается от нашей.

·>Нет, твоё заявление не учитывает законы физики и бизнеса. Это неадекватно.
Мое заявление учитывает законы физики, логики и бизнеса. Оно вам не нравится, но это не мешает быть ему адекватным.

·>Наоборот. Знают очень хорошо.
Тогда почему вы продолжаете называть эластик nosql-ем, когда сами они считают его поисковым сервисом?

·>Я задал конкретный вопрос "какие полезные фичи nosql". Зачем ты вообще упомянул "надежное хранение", R, питон и ML? Что сказать-то хотел?
Я хотел сказать то что сказал. Для сервиса предоставляющего надежное хранение данных, умение нативно работать с JSON, а так же XML и другими структурированными данными является полезной фичей.

·>Да такая же. Просто чуть парсер отличается. Не по кавычкам/скобкам делить на токены надо, а по пробелам/точкам.
А, ну ок, в следующий раз когда API будете делать, отдавайте данные плейнтекстом, разницы-то нет.

Здравствуйте, ·, Вы писали:

·>Давай.
"Не имеет смысла ни уточнять определение noSQL, ни просто говорить, что ES документноориентированная noSql хранилище"

·>И что? И зачем бы заменять весь?
Чтобы быть альтернативой, а не дополнением.

Здравствуйте, Sinclair, Вы писали:

V>>По-другому еще не было ни разу, так что, предлагаю доморощенному манипулятору малость расслабиться и не смущать неподготовленного читателя всякой ахинеей.
V>>"Трюкач" помнишь?
S>Я предупреждал.

Мдее...
Чтобы ЭТИ твои слова имели вес, надо чтобы у самого рыльце было не в пушку.
Там же рядом позволял себе "обычно так делают невежды".
Т.е. пока что ты грубо абузишь выданные тебе когда-то привилегии.
Типа читеришь.

Смишно же, когда врослому дядьке приходится объяснять основы общения на форумах...
Если ты участвуешь в споре как полноправный спорщик, то остальным глубочайше начхать, что ты при этом еще и модератор или там водопроводчик или еще мало ли кто. Изволил позволить себе потреблять время и терпение оппонентов — терпи сам.
Реакция на тебя такая же точно, как на любых других наглецов, когда те перестают видеть берега.
И по-другому никогда не будет, хоть размахайся баномётом по самое нимогу — это, таки, не вопрос жизни и смерти, чтобы пытаться через баномёт "нагибать".

В любом случае, по глупости ли, или по чудовищной близорукости своей, или из-за банальной интернетной борзости (более присущей, правда, поколению намного младше нашего, но мало ли?) — не суть. Прикрывая несдерживаемые свои непотребства модераторством аки фиговым листочком, в сухом остатке обитаешь на ролях активного генератора недоразумений.

Иногда тебя терпят, но иногда натурально уже задолбал.
Один здешний популярный бесноватый по состоянию на середину 2000-х уже более-менее угомонился, тебя же периодически прёт и прёт еще.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Это опять же зависит от конфигурации. Если это логи посещения веб-сайта, то действительно всем плевать и их можно не персистить. А вот логи каких-нибудь финансовых операций будут персиститься и храниться N лет в сейфе, иначе аудит не пройдёшь и бизнес не сможешь вести.
НС>Это не имеет отношения к ELK.
Т.е. ELK позиционируется как и надёжное долговременное хранилище логов, golden source?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>·>Ты так говоришь, как будто нарушать ACID что-то плохое.
НС>>>Зависит от задач.
НС>·>Верно. Асидность перпендикулярна сиквельности.
НС>Де-факто — нет.
Де-факто есть nosql acid-compliant базы.

НС>Де-факто — есть хорошая корреляция между сиквельностью и нормальной поддержкой ACID.
Ты серьёзно?! [пираты_глобальноепотепление.жпг]

НС>·>Как будто рсубд тюнить не надо и "магия" не случается.
НС>Тюнинг запросов и собственная подсистема обеспечения изоляции по сложности и стоимости отличаются на несколько порядков.
И погода на марсе.... Ты правда решил оценивать степень носиквельности по сложности и стоимости?

Здравствуйте, ·, Вы писали:

НС>>Это не имеет отношения к ELK.
·>Т.е. ELK позиционируется как и надёжное долговременное хранилище логов, golden source?

Ты сказал.