Здравствуйте, Ops, Вы писали:
Ops>·>И что? А после продакшна что мешает выкинуть? Ops>Зачем выкинуть? Полезная фича, пусть на поверку и слабо востребованная
Про слабую востребованность ты сам сочинил.
Ops>·>Он настолько не хайлоад, что под него нужны были дополнительные линцензии для mssql либо ES. Ops>Так выходит, ES им нужен только из-за экономии денег на лицензиях mssql?
Не только. Саможе важное: "FTS убог".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Потому что nosql это терминология, часто мало что говорящая, помещать такое на главную страницу — какое-то хипстерство было бы. Но вот тебе сайт авторов: ·>https://www.elastic.co/blog/found-elasticsearch-as-nosql
Иногда полезно читать статьи, ссылки на которые сам же и приводишь:
To summarize the summary, it neither makes sense to precisely define NoSQL, nor to simply say that Elasticsearch is a "document store"-type NoSQL-database.
Что прямо говорит о том, что даже сами авторы не очень уверены, что эластик стоит причислять к NoSQL
Здравствуйте, IB, Вы писали:
IB>·>А какой они могли взять, но не взяли и почему не взяли? IB>Понятия не имею, я там свечку не держал. Зная как принимаются решения в энтерпрайзе, примерно могу себе представить, но это не имеет отношения к делу.
Ну т.е. насочинял. Фактов у тебя нет.
IB>·>Не слышал эту историю. Рассказывай. IB>Ну собственно рассказал уже. Долго возились с монгой, было быстро но бестолково. Взяли мускул, доточили хранилище на предмет лишних записей на диск, стало удобнее и в три раза быстрее.
Кто возился? Где возился?
IB>·>В том то и дело, что иногда сделает, а иногда не сделает. Ломы в ртути топил, например, facebook, когда насиловал mysql, но в конце концов у них таки случился сабж. IB>Что у них случилось, кэш прикрутили? Если я правильно помню, основное хранилище у них все еще на мускуле.
Я не слежу что там у них сейчас происходит, но одно время они работали над неким Apollo. https://opensourceforu.com/2017/10/facebook-replacing-mysql-database-something-dynamic/
Вроде ещё были Hive и Cassandra.
IB>·>И где его достаточно? Другими словами, назови пару известных проектов, которые на нём сидят. IB>Много где. Подозреваю, что проектов где его достаточно, сильно больше, чем где недостаточно, даже если известных проектов на нем вообще нет.
Назови пару известных проектов. Слово "Подозреваю" намекает на то, что ты опять сочиняешь.
IB>·>Верно. Вот и объясни зачем оно в mssql? IB>Что бы было что использовать в тех проектах, где его хватает. Как мы выяснили, софт для атомных реакторов пишут далеко не все, но им все равно нужен простой функционал поиска из коробки.
Ну так где его хватает?
IB>·>Видимо что-то не так в терминологии. Что по-твоему nosql-ная задача? Эластик, по-моему, обычная типичная nosql база данных. IB>Ну, по вашему, может быть, но даже сами авторы эластика не уверены считать ли его NoSQL. "it neither makes sense to precisely define NoSQL, nor to simply say that Elasticsearch is a "document store"-type NoSQL-database." (c) IB>По факту это поисковый полнотекстовый индекс в виде сервиса для различных источников данных, как реляционных, так и не очень.
Ага, терминология. Но вроде как многие его считают nosql. Если ты не согласен, что ты тогда считаешь nosql?
IB>>>Какие тут претензии к реляционкам я продолжаю не понимать. IB>·>Пытаюсь выяснить что скрывается за "на сегодня все взрослые РСУБД обзавелись полезными фичами NoSQL". Вот интересно что собственно это значит. IB>Добавили полезные для надежного хранения
А что, РСУБД до этого данные хранили ненадёжно?
IB>и работы с данными фичи, типа работы с JSON, поддержки питона и R для ML, и т. д.
Поддержка питона, R и ML — это фичи nosql???!! Ок. Больше вопросов нет.
IB>·>Что sql это не про хранение данных (данные вообще-то и в файлах замечательно хранятся или вообще на магнитных лентах), а про запросы к данным. IB>Конкретно язык sql — действительно для запросов, но вас не смущает, что большинство noSQL поддерживают SQL в полный рост? IB>Однако здесь мы вроде как разговариваем не о языке SQL, а под SQL понимали реляционные хранилища, если явно не сказано обратного, так что не надо на ходу переобуваться ))
Ну так реляционные хранилища это про реляционные операции, которые union, intersection, difference, product, projection и прочую реляционную алгебру. Хранение это немного сбоку. Почему ты на первое место ставишь хранение — мне непонятно.
IB>·>Но не важно что там говорили — надо смотреть на результат и что они делали потом: "TradElect had been completely replaced with Millennium Exchange". IB>Ага, 4 года спустя, когда туда пришел новый директор, которому надо было показать кто тут хозяин. Конечно — MSSQL виноват ))
IB>·>Не понял логику. Хранить json можно в текстовом блобе — и это было всегда. А втащили они именно индексацию и поиск по этим самым json-блобам. Почему поиск по тексту менее полезен поиска по json — мне непонятно. Или логика такова, что называем полезным только то, что втащили и что хоть как-то приемлимо работает? IB>Логика такова, что в JSON хранятся структурированные данные. И в некоторых сценариях удобно хранить их как есть, не разбивая по таблицам. Поэтому возможность индексировать их и строить по ним запросы выглядит логичным дополнением к функционалу хранилища. json с т.з. субд — неструктурированные данные, т.к. их структура никак не описывается и не проверяется (в отличие от реляционных данных, для которых есть схема).
IB>В случае же FTS, данные мало того что не структурированы, так еще и поиск зачастую нужен не только по тем данным, что хранятся в базе. Поэтому вполне разумно иметь в хранилище только базовый функционал, а если нужно взрослое решение, использовать внешний сервис индексирования.
А покаким ещё? И почему эти данные хранятся не в базе?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IB, Вы писали:
IB>·>Потому что nosql это терминология, часто мало что говорящая, помещать такое на главную страницу — какое-то хипстерство было бы. Но вот тебе сайт авторов: IB>·>https://www.elastic.co/blog/found-elasticsearch-as-nosql IB>Иногда полезно читать статьи, ссылки на которые сам же и приводишь: IB>
IB>To summarize the summary, it neither makes sense to precisely define NoSQL, nor to simply say that Elasticsearch is a "document store"-type NoSQL-database.
IB>Что прямо говорит о том, что даже сами авторы не очень уверены, что эластик стоит причислять к NoSQL
Ну да, я же говорю, что это терминология. Поэтому "nor to simply say".
nosql это всё о компромисах. rdbms и sql это круто в теории и вообще универсальный вмемогутер, но в нашем подлунном мире работает далеко не всегда. Поэтому надо идти на определённые компромисы, что приводит к nosql.
Собственно вся эта шумиха вокруг nosql и возникла когда натягивают sql и когда оно таки рвётся, идут на поиски чего-то другого. И, в итоге подбирают что-то подходящее для решения возникшей проблемы. Поэтому, ES можно смело включать в список http://nosql-database.org/ — как кандидат на рассмотрения альтернатив, когда sql-я не хватает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Про слабую востребованность ты сам сочинил.
Ну а кто писал про 3.14%?
·>Не только. Саможе важное: "FTS убог".
Может убог, хз. А что именно в нем убого, индексы медленные? Насколько, в сравнение с ES?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>·>Про слабую востребованность ты сам сочинил. Ops>Ну а кто писал про 3.14%?
Прошу прощения за неявный сарказм. Я думал такое число явно скажет что оно выдуманное и не имеет значения, и просто фигура речи.
Ops>·>Не только. Саможе важное: "FTS убог". Ops>Может убог, хз. А что именно в нем убого, индексы медленные? Насколько, в сравнение с ES?
Я деталей не знаю. Насколько слышал, что изначально в SO был именно он, они с ним постоянно имели проблемы с перформансом, не хватало фич, и в итоге ушли на ES.
Т.е. фантазии о том, что ES они прикрутили случайно, чтоб-было, это таки фантазии — ES был заменой FTS.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
НС>>С сайта авторов. ·>Ты ж говорил, что не хочешь обсуждать терминологию...
Не хочу. Но ты ж окончательно скатился к обсуждению терминов. По мне так цитата авторов позволяет вопрос терминологии закрыть.
Но если ты настаиваешь — тогда на этом и закончим, потому что аргументов по делу у тебя все равно не осталось.
НС>>·>Ты только что заявил, что ES не является nosql, потому что в нём нет визуализатора. НС>>Вранье. ·>Ты сказал что ELK это nosql, а ES — нет. А ELK это банально ES интегрированный с Logstash и Kibana. Я всё правильно понял?
Ты "забыл" кое чего
Ты не с той стороны смотришь. Дело не в том как устроено, а в том для чего используется.
Здравствуйте, ·, Вы писали:
НС>>>>И чего произойдет если изредка Амазончик сбойнет? Да ничего. Особенно если убрать самые неприятные варианты типа продаж несуществующего товара. Ну нажмет юзверь еще разок, все уже к глюкам современного веба привыкли. НС>>·>Миллионные потери от простоя. НС>>Какого простоя? Просто юзверь еще разок нажмет на кнопу и все сработает. ·>Не знаю про какую кнопку ты говоришь. Но временный обрыв связи это не сбой
Речь не про временный обрыв связи или черную пятницу, речь про нарушение ACID. Все что нам нужно в случае Амазона — при таком нарушении не делать непоправимых изменений и просто выдать ошибку. Что и делается комбинацией идемпотентности и асинхронности. А вот в банках такое уже не прокатит.
НС>>>>А что произойдет если сбойнет банк? ЖОПА. НС>>·>Они постоянно сбоят. Ничего не произойдёт. В худщем случае — извинятся перед клиентами. НС>>А, ну ну. ·>Так следи за новостями. Постоянно что-то сыпется в it банков.
Еще раз — речь не про масштабные сбои, что форс-мажор, а про периодически слуяающиеся ошибки в конкретных единичных транзакциях. Где то такие ошибки допустимы, если они случаются нечасто, а где то нет.
Здравствуйте, ·, Вы писали:
·>Ну да, я же говорю, что это терминология. Поэтому "nor to simply say".
Не, вы говорите, что это NoSql, но вот сами авторы что-то не очень в этом уверены.
·>Поэтому, ES можно смело включать в список http://nosql-database.org/ — как кандидат на рассмотрения альтернатив, когда sql-я не хватает.
Алтернатива — это когда заменяют. А когда ставят рядом для выполнения специфической задачи — это дополнение или расширение.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>С сайта авторов. НС>·>Ты ж говорил, что не хочешь обсуждать терминологию... НС>Не хочу. Но ты ж окончательно скатился к обсуждению терминов. По мне так цитата авторов позволяет вопрос терминологии закрыть. НС>Но если ты настаиваешь — тогда на этом и закончим, потому что аргументов по делу у тебя все равно не осталось.
Цитата не утверждает, что ES не nosql, а то что зависит от того что под этим понимать (терминология) и юзкейсов. SQL субд при желании тоже как nosql можно использовать.
Собственно, если вспомнить ситуацию в IT лет 20 назад, то rdbms были единственным выбором в вопросе хранения данных и запросов к ним. Всё крутилось вокруг них. А сейчас есть выбор.
Раньше если был нужен FTS, он либо лабался поверх sql табличек — табличка слов, табличка документов и т.п. Или, если денег хватало на "взрослую" субд, он был из коробки, уже слабанный производителем рсубд вокруг тех же табличек. Вот, например. Сейчас ситуация другая.
Интернет-магазины — Order/items таблички, главный сервер субд, лишь бы не упал. Сейчас вот Амазон.
Финансы, аналитика/риск — субд меняют на всякие хадупы-спарки.
Сабж.
НС>>>·>Ты только что заявил, что ES не является nosql, потому что в нём нет визуализатора. НС>>>Вранье. НС>·>Ты сказал что ELK это nosql, а ES — нет. А ELK это банально ES интегрированный с Logstash и Kibana. Я всё правильно понял? НС>Ты "забыл" кое чего НС>
НС>Ты не с той стороны смотришь. Дело не в том как устроено, а в том для чего используется.
И там, и там оно используется для индексации и запросов к неструктурированной текстовой информации. Не вижу разницы, поэтому и "забыл". И то, и то одинаково плохо ложится в реляционку. В чём разница-то?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Какого простоя? Просто юзверь еще разок нажмет на кнопу и все сработает. НС>·>Не знаю про какую кнопку ты говоришь. Но временный обрыв связи это не сбой НС>Речь не про временный обрыв связи или черную пятницу, речь про нарушение ACID. Все что нам нужно в случае Амазона — при таком нарушении не делать непоправимых изменений и просто выдать ошибку. Что и делается комбинацией идемпотентности и асинхронности.
Ты так говоришь, как будто нарушать ACID что-то плохое. Ведь ты слыхал об isolation levels. СУБД нарушают I и не только во всю.
НС>А вот в банках такое уже не прокатит.
А что прокатит? Сделать непоправимое изменение или не выдать ошибку?
Ты так говоришь, как будто в банках на всё ровно одна субд, работающая в serialised level. Нетушки, там так же "всё плохо". Поэтому всякие хитрые корректирующие операции по счетам, которые случаются когда что-то идёт не так в ACID.
НС>>>>>А что произойдет если сбойнет банк? ЖОПА. НС>>>·>Они постоянно сбоят. Ничего не произойдёт. В худщем случае — извинятся перед клиентами. НС>>>А, ну ну. НС>·>Так следи за новостями. Постоянно что-то сыпется в it банков. НС>Еще раз — речь не про масштабные сбои, что форс-мажор, а про периодически слуяающиеся ошибки в конкретных единичных транзакциях. Где то такие ошибки допустимы, если они случаются нечасто, а где то нет.
Да не случаются некие магические "ошибки" в nosql. Всё работает как надо и предусмотрено требованиями (если исключить баги, конечно).
Киберакс говорил, какой, например, у них инвариант на количество товара. Мол, продать больше чем есть — нельзя. И он соблюдается безошибочно. А "случайно не продать" — не является ошибкой, в т.ч. и с т.з. бизнеса. Ибо, даже оформленный заказ какое-то время покупатель может отменить сам. Или тупо сделать возврат через неделю. Но уж если покупатель купил по распродаже телевизор за $10, то он его купил, и никакой ошибки в его единичной транзакции случиться не может.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IB, Вы писали:
IB>·>Ну да, я же говорю, что это терминология. Поэтому "nor to simply say". IB>Не, вы говорите, что это NoSql, но вот сами авторы что-то не очень в этом уверены.
Не "не уверены", а "зависит от".
IB>·>Поэтому, ES можно смело включать в список http://nosql-database.org/ — как кандидат на рассмотрения альтернатив, когда sql-я не хватает. IB>Алтернатива — это когда заменяют. А когда ставят рядом для выполнения специфической задачи — это дополнение или расширение.
Ну вот SO в своё время заменили MS SQL FTS на ES. И об чём спор-то?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ну т.е. насочинял. Фактов у тебя нет.
Аккуратнее. Где вам показалось, что я что-то насочинял?
Я лишь доказал, что факт использования амазоном кастомного noSQL-я ничего не говорит о других альтернативах.
·>Кто возился? Где возился?
Оригинальный кейс с ходу не нашел, но вот парочка https://habr.com/post/231213/ https://felixit.blog/2018/03/03/tri-problemy-mongodb/
·>Вроде ещё были Hive и Cassandra.
Да для поиска и аналитики. Сами данные в реляционке, как и в случае с SO.
·>Назови пару известных проектов. Слово "Подозреваю" намекает на то, что ты опять сочиняешь.
Повторяю свою мысль еще раз, более развернуто. Отсутствие у меня знаний об известных проектах с MS FTS ничего не говорит о применимости этого решения. Наличие же у меня знаний о не известных проектах, позволяет мне судить о том, что он вполне применим в реальных сценариях.
·>Ну так где его хватает?
В простых гражданских решениях.
IB>>По факту это поисковый полнотекстовый индекс в виде сервиса для различных источников данных, как реляционных, так и не очень. ·>Ага, терминология.
Это не терминология. Это то как авторы позиционируют свое решение и то как его используют на практике в большинстве сулчаев.
IB>>Добавили полезные для надежного хранения ·>А что, РСУБД до этого данные хранили ненадёжно?
Ну так-то грубо зачем передергивать. Троллите, так хоть сделайте усилие, постарайтесь тоньше ))
IB>>Однако здесь мы вроде как разговариваем не о языке SQL, а под SQL понимали реляционные хранилища, если явно не сказано обратного, так что не надо на ходу переобуваться )) ·>Ну так реляционные хранилища это про реляционные операции, которые union, intersection, difference, product, projection и прочую реляционную алгебру. Хранение это немного сбоку. Почему ты на первое место ставишь хранение — мне непонятно.
Потому что вся эта история исключительно про храниение, а реляционная часть про удобство работы с этими сохраненными данными и механизм, который позволит формально обосновать сочетаемость ACID-ности с производительностью.
·>
Да, против фактов не попрешь )
·> json с т.з. субд — неструктурированные данные, т.к. их структура никак не описывается и не проверяется (в отличие от реляционных данных, для которых есть схема).
Ну и что? Она конечно формально не проверяется, но она есть, что позволяет строить запросы и извлекать данные.
·>А покаким ещё? И почему эти данные хранятся не в базе?
Это, очевидно, зависит от конкретного сценария. Текстовые документы, например, очень часто хранаят не в базе, а на внешнем хранилище. Очень часть так же бывает несколько legacy систем разных поколейний, по которым нужен сквозной поиск — это просто первое, что в голову пришло.
Здравствуйте, IB, Вы писали:
IB>·>Ну т.е. насочинял. Фактов у тебя нет. IB>Аккуратнее. Где вам показалось, что я что-то насочинял? IB>Я лишь доказал, что факт использования амазоном кастомного noSQL-я ничего не говорит о других альтернативах.
И что? Ты упорно игнорируешь тот факт, что они много раз пробовали альтернативы и они им не подошли. И это _явно_ говорит о других альтернативах, правда ты слышать этого не хочешь. Мало того, ты заявил что они могли использовать "все что угодно безотносительно структуры хранимых данных и используемого языка". Это, мягко говоря, неадекватное заявление. Конечно, если бы у них существовало бесконечное число ресурсов и времени, то они могли бы хранить всё на глиняных табличках и писать на brainfuck. Но это не согласуется с законами физики нашей Вселенной, нет столько глины на планете Земля. А законы бизнеса ещё строже. И они не могли потратить триллионы долларов на покупку всего Oracle и кинуть всех на допиливания RAC (если он в принципе допиливается, в чём я сомневаюсь) под их нужды.
IB>·>Кто возился? Где возился? IB>Оригинальный кейс с ходу не нашел, но вот парочка IB>https://habr.com/post/231213/ IB>https://felixit.blog/2018/03/03/tri-problemy-mongodb/
"просто довольно глупо выглядит выбор инструмента, который не подходит, а потом выставление этого инструмента виноватым в том, что он не подходит".
Короче, советы для молодёжи.
IB>·>Вроде ещё были Hive и Cassandra. IB>Да для поиска и аналитики. Сами данные в реляционке, как и в случае с SO.
Не в реляционке, а в mysql как kv-pair хранилище с ручными джойнами и прочими nosql фишками. Много урановых ломов в ртути утонуло.
IB>·>Ну так где его хватает? IB>В простых гражданских решениях.
Ок. Мне остаётся поверить на слово.
IB>>>По факту это поисковый полнотекстовый индекс в виде сервиса для различных источников данных, как реляционных, так и не очень. IB>·>Ага, терминология. IB>Это не терминология. Это то как авторы позиционируют свое решение и то как его используют на практике в большинстве сулчаев.
Они делают явным юзкейсы когда оно применимо. Советы для молодёжи.
IB>>>Добавили полезные для надежного хранения IB>·>А что, РСУБД до этого данные хранили ненадёжно? IB>Ну так-то грубо зачем передергивать. Троллите, так хоть сделайте усилие, постарайтесь тоньше ))
Я явно спросил "какие полезные фичи nosql", а ты мне отвечаешь "надёжное хранение" и "питон". Кто первый троллить начал?
IB>>>Однако здесь мы вроде как разговариваем не о языке SQL, а под SQL понимали реляционные хранилища, если явно не сказано обратного, так что не надо на ходу переобуваться )) IB>·>Ну так реляционные хранилища это про реляционные операции, которые union, intersection, difference, product, projection и прочую реляционную алгебру. Хранение это немного сбоку. Почему ты на первое место ставишь хранение — мне непонятно. IB>Потому что вся эта история исключительно про храниение, а реляционная часть про удобство работы с этими сохраненными данными и механизм, который позволит формально обосновать сочетаемость ACID-ности с производительностью.
Про хранение ты сам придумал историю. Чисто для хранения рсубд не нужны. Достаточно писать append-only файлы — ACID в полный рост, производительность заоблачная.
IB>·> json с т.з. субд — неструктурированные данные, т.к. их структура никак не описывается и не проверяется (в отличие от реляционных данных, для которых есть схема). IB>Ну и что? Она конечно формально не проверяется, но она есть, что позволяет строить запросы и извлекать данные.
В чём принципиальное отличие от текста-то? По нему запросы строить нельзя или данные не извлекаются?
IB>·>А покаким ещё? И почему эти данные хранятся не в базе? IB>Это, очевидно, зависит от конкретного сценария. Текстовые документы, например, очень часто хранаят не в базе, а на внешнем хранилище. Очень часть так же бывает несколько legacy систем разных поколейний, по которым нужен сквозной поиск — это просто первое, что в голову пришло. https://www.mssqltips.com/sqlservertip/2769/sql-server-semantic-search-to-find-text-in-external-files/
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Не "не уверены", а "зависит от".
Нужен перевод?
·>Ну вот SO в своё время заменили MS SQL FTS на ES. И об чём спор-то?
О том, что заменили одну внешнюю приблуду от сиквела, а не весь MSSQL на эластик.
Здравствуйте, ·, Вы писали:
IB>>Я лишь доказал, что факт использования амазоном кастомного noSQL-я ничего не говорит о других альтернативах. ·>И что?
Собственно и все. На этом можно заканчивать.
·>Ты упорно игнорируешь тот факт, что они много раз пробовали альтернативы и они им не подошли.
Конечно, потому что мы ничего не знаем о причинах, почему не подошли, а значит не можем принимать их во внимание.
·> Мало того, ты заявил что они могли использовать "все что угодно безотносительно структуры хранимых данных и используемого языка". Это, мягко говоря, неадекватное заявление.
Это более чем адекватное заявление, так как обратное не доказано. Вот если бы я заявил, что их текущее решение не рабочее, вот это было бы не адекватно.
·>Короче, советы для молодёжи.
Я понимаю, что вам не нравятся примеры, где NoSql мимо кассы, но что делать...
·>Не в реляционке, а в mysql как kv-pair хранилище с ручными джойнами и прочими nosql фишками.
Пруф есть?
·>Они делают явным юзкейсы когда оно применимо. Советы для молодёжи.
То есть, авторы эластика сами не знают что из себя представляет их продукт и для чего его использовать? Оооок.
·>Я явно спросил "какие полезные фичи nosql", а ты мне отвечаешь "надёжное хранение" и "питон". Кто первый троллить начал?
Я ответил JSON, и думаю не сложно было понтяь, что фраза про надежное хранение относилась к тому что РБД и так умеют.
·>Про хранение ты сам придумал историю. Чисто для хранения рсубд не нужны. Достаточно писать append-only файлы — ACID в полный рост, производительность заоблачная.
Опять какой-то троллинг не интересный и докапывание до терминологии на ровном месте... Но если хочется, можем вести дискуссию в этом ключе.
·>В чём принципиальное отличие от текста-то? По нему запросы строить нельзя или данные не извлекаются?
В том, что в тексте структуры нет, а в JSON структура есть, хоть и без схемы.
·>https://www.mssqltips.com/sqlservertip/2769/sql-server-semantic-search-to-find-text-in-external-files/
И? Да, функциональность сиквельного компонента FTS тоже расширяют, так как сценарий востребованый.
Здравствуйте, sergeya, Вы писали:
GIV>>Нормально там все с бигдатой, поверь на слово, проверено эксплуатацией у крупных провайдеров типа Билайна.
S>Прямо таки на системах класса OLTP проверено? Неужели Сomverse или Amdocs на nosql перенесли?
Эмм, раз там нет OLTP то не бигдата чтоли? Текущий проект да, OLTP что-то типа Сomverse если я правильно понял.
Здравствуйте, IB, Вы писали:
IB>>>Я лишь доказал, что факт использования амазоном кастомного noSQL-я ничего не говорит о других альтернативах. IB>·>И что? IB>Собственно и все. На этом можно заканчивать.
У — Логика
А ещё факт того, что солнце светит — тоже ничего не говорит о других альтернативах. Ничего не говорящие факты меня не интересуют.
IB>·>Ты упорно игнорируешь тот факт, что они много раз пробовали альтернативы и они им не подошли. IB>Конечно, потому что мы ничего не знаем о причинах, почему не подошли, а значит не можем принимать их во внимание.
Не говори за всех. Киберакс писал. Если ты хочешь знать, то просто прочитай.
IB>·> Мало того, ты заявил что они могли использовать "все что угодно безотносительно структуры хранимых данных и используемого языка". Это, мягко говоря, неадекватное заявление. IB>Это более чем адекватное заявление, так как обратное не доказано. Вот если бы я заявил, что их текущее решение не рабочее, вот это было бы не адекватно.
Нет, твоё заявление не учитывает законы физики и бизнеса. Это неадекватно.
IB>·>Короче, советы для молодёжи. IB>Я понимаю, что вам не нравятся примеры, где NoSql мимо кассы, но что делать...
Что значит не нравятся? Мне плевать, если кто-то закручивает гвозди отвёрткой. И считаю идиотами тех, которые из это делают вывод, что отвёртка негодный инструмент и предлагают забивать шурупы молотком.
IB>·>Не в реляционке, а в mysql как kv-pair хранилище с ручными джойнами и прочими nosql фишками. IB>Пруф есть?
Facebook uses MySQL, but primarily as a key-value persistent storage, moving joins and logic onto the web servers since optimizations are easier to perform there
https://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
IB>·>Они делают явным юзкейсы когда оно применимо. Советы для молодёжи. IB>То есть, авторы эластика сами не знают что из себя представляет их продукт и для чего его использовать? Оооок.
Наоборот. Знают очень хорошо.
IB>·>Я явно спросил "какие полезные фичи nosql", а ты мне отвечаешь "надёжное хранение" и "питон". Кто первый троллить начал? IB>Я ответил JSON, и думаю не сложно было понтяь, что фраза про надежное хранение относилась к тому что РБД и так умеют.
Я задал конкретный вопрос "какие полезные фичи nosql". Зачем ты вообще упомянул "надежное хранение", R, питон и ML? Что сказать-то хотел?
IB>·>В чём принципиальное отличие от текста-то? По нему запросы строить нельзя или данные не извлекаются? IB>В том, что в тексте структуры нет, а в JSON структура есть, хоть и без схемы.
Да такая же. Просто чуть парсер отличается. Не по кавычкам/скобкам делить на токены надо, а по пробелам/точкам.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IB, Вы писали:
IB>·>Не "не уверены", а "зависит от". IB>Нужен перевод?
Давай.
IB>·>Ну вот SO в своё время заменили MS SQL FTS на ES. И об чём спор-то? IB>О том, что заменили одну внешнюю приблуду от сиквела, а не весь MSSQL на эластик.
И что? И зачем бы заменять весь?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Мы уже победили, просто это еще не так заметно...
Не вижу разницы, поэтому и "забыл". И то, и то одинаково плохо ложится в реляционку. В чём разница-то?
