Здравствуйте, ·, Вы писали:
·>Я видимо твою эту цитату не понял. Что ты хочешь сказать?
Ровно то что написал. Учитывая, что проекты насквозь рукописные и решения из коробки там не используются, то довести до требуемых характиеристик производительности/надежности/доступности можно все что угодно безотносительно структуры хранимых данных и используемого языка.
·>Что тогда mysql рвал на тряпки? Я совсем перестал тебя понимать.
NoSql и рвал. Точно так же выкидывали NoSQL, докручивали напильником мускул и вперед.
·>И вообще, в некоторых успешных случаях насилования mysql от него никакого sql не остаётся, acid куда-то испаряется и прочее.
acid испаряется, а sql остается, в зависимости от того, что хочется получить.
·>Я с этим и не спорю. Я просто разбираю "совет" выше по треду "взять FTS из MSSQL". Согласен, это бред, а не совет.
Это от сценария зависит, например MSSQL из коробки не все языки нормально поддерживает. С другой стороны, для некоторых проектов его хватает за глаза, чегож его не использовать?
·>Может кто-то и использует, кто повёлся на маркетинг. SO, вот, не использует.
SO и не нужно, SO SQL-я достаточно.
·>Ну иногда среди этих подсистем никакого sql нет.
Равно как и согласованности с доступностью.
·>В смысле тот же самый Амазон — чудо?
С чего бы чудо? Как нам на пальцах объяснили, это изделие тонко балансирует между доступностью, скоростью и производительностью там где могут себе это позволить.
Решение из коробки так не умеет, так как ничего не знает о предметной области и не знает где и чем можно пожертвовать. поэтому либо все делается руками, либо априори жертвуешь согласованностью, либо скоростью...
При этом как почитаешь форум, так все атомные реакторы строят, а на поверку оказывается, что SQLLight за глаза.
·>Так тут это как сравнишь так и будет. Там даже было что-то вроде 36% рост nosql против 11% роста sql. Или что?
Там было ровно наоборот, рост монги меньше процента, а постгри за десяток, тут как не мерь.
Здравствуйте, IB, Вы писали:
IB>·>Я видимо твою эту цитату не понял. Что ты хочешь сказать? IB>Ровно то что написал. Учитывая, что проекты насквозь рукописные и решения из коробки там не используются, то довести до требуемых характиеристик производительности/надежности/доступности можно все что угодно безотносительно структуры хранимых данных и используемого языка.
Ну. Я и говорю, что это ложное заявление. Киберакс говорил, что Amazon пытался прикрутить Oracle RAC при активной поддержке самого Oracle. А так же он писал, что у них была целая команда, которая пыталась "довести до требуемых характиеристик" существующие на тот момент решения на рынке. Итог, вроде, известен.
IB>·>Что тогда mysql рвал на тряпки? Я совсем перестал тебя понимать. IB>NoSql и рвал. Точно так же выкидывали NoSQL, докручивали напильником мускул и вперед.
Рвал ещё несуществующий nosql? Верю.
IB>·>И вообще, в некоторых успешных случаях насилования mysql от него никакого sql не остаётся, acid куда-то испаряется и прочее. IB>acid испаряется, а sql остается, в зависимости от того, что хочется получить.
Остаётся kv-pair, а не sql. Если от sql используется только SELECT из только одной таблицы по первичному ключу, то это мягко говоря лукавство называть такое sql.
IB>·>Я с этим и не спорю. Я просто разбираю "совет" выше по треду "взять FTS из MSSQL". Согласен, это бред, а не совет. IB>Это от сценария зависит, например MSSQL из коробки не все языки нормально поддерживает. С другой стороны, для некоторых проектов его хватает за глаза, чегож его не использовать?
ну говорю же — маркетинг.
IB>·>Может кто-то и использует, кто повёлся на маркетинг. SO, вот, не использует. IB>SO и не нужно, SO SQL-я достаточно.
Почему тогда не используют sql для этого?
IB>·>Ну иногда среди этих подсистем никакого sql нет. IB>Равно как и согласованности с доступностью.
Очередное заблуждение. Вспомнить например приключеня LSE с mssql. А уж на LSE согласованность с доступностью просто обязательна.
IB>·>В смысле тот же самый Амазон — чудо? IB>С чего бы чудо? Как нам на пальцах объяснили, это изделие тонко балансирует между доступностью, скоростью и производительностью там где могут себе это позволить. IB>Решение из коробки так не умеет, так как ничего не знает о предметной области и не знает где и чем можно пожертвовать. поэтому либо все делается руками, либо априори жертвуешь согласованностью, либо скоростью...
Т.е. таки не всё втащили в mssql/oracle? А обещать так рады.
IB>При этом как почитаешь форум, так все атомные реакторы строят, а на поверку оказывается, что SQLLight за глаза.
Опять "Не видел в жизни задачи".
IB>·>Так тут это как сравнишь так и будет. Там даже было что-то вроде 36% рост nosql против 11% роста sql. Или что? IB>Там было ровно наоборот, рост монги меньше процента, а постгри за десяток, тут как не мерь.
Агрумент из того же ряда, как и то что php победил c++.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ну. Я и говорю, что это ложное заявление.
Чего в нем ложного?
·> Киберакс говорил, что Amazon пытался прикрутить Oracle RAC при активной поддержке самого Oracle. А так же он писал, что у них была целая команда, которая пыталась "довести до требуемых характиеристик" существующие на тот момент решения на рынке. Итог, вроде, известен.
Итог в том, что решилили сваять собственное. Тот факт, что собственное работает, говорит о том, что их вариант возможен, но ничего не говорит о том, какой вариант они не стали брать.
·>Рвал ещё несуществующий nosql? Верю.
Я же ясно написал несколько раз — существующую. Могу еще, мне не сложно.
·>Остаётся kv-pair, а не sql. Если от sql используется только SELECT из только одной таблицы по первичному ключу, то это мягко говоря лукавство называть такое sql.
по паре джойн не сделаешь и как ни называй — это SQL.
·>ну говорю же — маркетинг.
да говорите что угодно, фактов-то это не изменит.
·>Почему тогда не используют sql для этого?
Для хранения используют. А для чего вы хотите SQL использовать мне не ведомо.
·>Очередное заблуждение.
Это не заблуждение, это факт.
·>Вспомнить например приключеня LSE с mssql. А уж на LSE согласованность с доступностью просто обязательна.
Понятия не имею что такое LSE и при чем тут MSSQL, мы же здесь про NoSQL говорим.
IB>>Решение из коробки так не умеет, так как ничего не знает о предметной области и не знает где и чем можно пожертвовать. поэтому либо все делается руками, либо априори жертвуешь согласованностью, либо скоростью... ·>Т.е. таки не всё втащили в mssql/oracle? А обещать так рады.
Что должны были втащить? Поясняю, фраза "решение из коробки" относится как к noSql, так и к реляционкам.
·>Опять "Не видел в жизни задачи".
Ну, я-то не про себя писал, а вы про кого?
·>Агрумент из того же ряда, как и то что php победил c++.
Аргумент из разряда фактов, в отличии от всего остального что вы тут рассказываете.
Здравствуйте, ·, Вы писали:
·>Не в 4-5, а в любых сколько-нибудь больших (тот же упомянутый stackoverflow внезапно использует ES
Вот только использует он его не потому что сабж, а потому что FTS кривой, а lucene одно из лучших бесплатных решений на рынке. И сам МС долгое время именно ES для серверных проектов рекомендовал использовать.
Здравствуйте, ·, Вы писали:
·>Т.е. чистый маркетинг, другими словами. А как доходит до дела, получается что "Elastic is cheap and has far more features these days".
Ну вот написано же — far more features. FTS убог, и вовсе не потому что SQL. Я, к примеру, ни разу не сталкивался с ситуацией где бы все данные были внутри одной БД. А значит FTS пригоден только для каких то нишевых решений и все.
Здравствуйте, Cyberax, Вы писали:
S>>C фига ли? OLTP весь был и остаётся на RDBMS. C>Уже нет. Amazon — небольшая компания, которая продаёт в год товаров на сумму ВВП небольшой страны. RDBMS запрещены везде, где нужно OLTP. На использование RDBMS нужно получать разрешение на уровне VP.
И чего произойдет если изредка Амазончик сбойнет? Да ничего. Особенно если убрать самые неприятные варианты типа продаж несуществующего товара. Ну нажмет юзверь еще разок, все уже к глюкам современного веба привыкли.
А что произойдет если сбойнет банк? ЖОПА.
C>Гугл — примерно аналогично.
Здравствуйте, IB, Вы писали:
IB>·>Ну. Я и говорю, что это ложное заявление. IB>Чего в нем ложного?
В том что противоречит фактам.
IB>·> Киберакс говорил, что Amazon пытался прикрутить Oracle RAC при активной поддержке самого Oracle. А так же он писал, что у них была целая команда, которая пыталась "довести до требуемых характиеристик" существующие на тот момент решения на рынке. Итог, вроде, известен. IB>Итог в том, что решилили сваять собственное. Тот факт, что собственное работает, говорит о том, что их вариант возможен, но ничего не говорит о том, какой вариант они не стали брать.
Не понял я... кто чего не говорит? Явно же говорилось, какие варианты они не стали брать. Oracle RAC, например.
IB>·>Рвал ещё несуществующий nosql? Верю. IB>Я же ясно написал несколько раз — существующую. Могу еще, мне не сложно.
Какую? Название в студию.
IB>·>Остаётся kv-pair, а не sql. Если от sql используется только SELECT из только одной таблицы по первичному ключу, то это мягко говоря лукавство называть такое sql. IB>по паре джойн не сделаешь и как ни называй — это SQL.
Сделаешь, но не в sql.
IB>·>ну говорю же — маркетинг. IB>да говорите что угодно, фактов-то это не изменит.
Верно, факт в том, что FTS никто серьёзно и не использует, ибо сделан он чисто для галочки.
IB>·>Почему тогда не используют sql для этого? IB>Для хранения используют. А для чего вы хотите SQL использовать мне не ведомо. Тонкий намёк: Structured QUERY Language.
IB>·>Вспомнить например приключеня LSE с mssql. А уж на LSE согласованность с доступностью просто обязательна. IB>Понятия не имею что такое LSE и при чем тут MSSQL, мы же здесь про NoSQL говорим. http://lmgtfy.com/?q=lse+mssql — это про доступность в mssql.
IB>·>Т.е. таки не всё втащили в mssql/oracle? А обещать так рады. IB>Что должны были втащить? Поясняю, фраза "решение из коробки" относится как к noSql, так и к реляционкам.
Всё полезное должны были втащить. Вот цитата: "на сегодня все взрослые РСУБД обзавелись полезными фичами NoSQL".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>Т.е. чистый маркетинг, другими словами. А как доходит до дела, получается что "Elastic is cheap and has far more features these days". НС>Ну вот написано же — far more features. FTS убог, и вовсе не потому что SQL. Я, к примеру, ни разу не сталкивался с ситуацией где бы все данные были внутри одной БД. А значит FTS пригоден только для каких то нишевых решений и все.
Да я всё это прекрасно знаю. Ты это gandjustas расскажи, а то он тут
Здравствуйте, ·, Вы писали:
НС>>Ну вот написано же — far more features. FTS убог, и вовсе не потому что SQL. Я, к примеру, ни разу не сталкивался с ситуацией где бы все данные были внутри одной БД. А значит FTS пригоден только для каких то нишевых решений и все. ·>Да я всё это прекрасно знаю.
Тогда еще интереснее выглядят твои попытки выдать использование ES за сабж. ES вовсе не обязан хранить данные в NoSQL, кстати.
·> Ты это gandjustas расскажи, а то он тут
Здравствуйте, GarryIV, Вы писали:
GIV>>>Не ну понятно этот весь NoSQL бесплатен и открыт. НС>>Осталось подумать о том, почему так. GIV>Он моложе.
Неа. Все намношго проще — если NoSQL будет таким же платным, как SQL, возникнет много вопросов. В частности — а за что платить?
Вот с SQL картина вполне понятная — есть платная большая тройка, есть бесплатный постгри, который более менее полноценный, но с оптимизатором беда, и есть куча всякого бесплатного типа мускуля и sqlite, которое откровенно неполноценное. Так что совершенно понятно за что платишь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>Да я всё это прекрасно знаю. НС>Тогда еще интереснее выглядят твои попытки выдать использование ES за сабж.
Может быть вопрос терминологии... По мне ES вполне таки nosql, хранилище неструктурированных json документов, индексация, поиск и т.д. Разве нет?
НС>ES вовсе не обязан хранить данные в NoSQL, кстати.
Не знал. А подробнее?
НС>·> Ты это gandjustas расскажи, а то он тут
его советует, из добрых побуждений, наверное. НС>Человек просто никогда с FTS на реальном проекте не сталкивался. Но мы ведь не gandjustas обсуждаем.
Я обсуждаю не его, конечно, а его советы заменять nosql решения на то что есть в субд, тот же fts, системы аналитики и вообще внезапное "все взрослые РСУБД обзавелись полезными фичами NoSQL".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Неа. Все намношго проще — если NoSQL будет таким же платным, как SQL, возникнет много вопросов. В частности — а за что платить?
У меня ровно тот же вопрос про тройку эту. За что братцы платить?
Здравствуйте, ·, Вы писали:
·>Может быть вопрос терминологии... По мне ES вполне таки nosql, хранилище неструктурированных json документов, индексация, поиск и т.д. Разве нет?
Нет. ES в контексте SO вообще не хранилище, и используется по своему изначальному назначению, в качестве сервиса полнотекстового поиска. Вот ELK, тут да, можно, при желании, как rich storage трактовать.
НС>>ES вовсе не обязан хранить данные в NoSQL, кстати. ·>Не знал. А подробнее?
Здравствуйте, GarryIV, Вы писали:
НС>>Неа. Все намношго проще — если NoSQL будет таким же платным, как SQL, возникнет много вопросов. В частности — а за что платить? GIV>У меня ровно тот же вопрос про тройку эту. За что братцы платить?
За решение определенного класса проблем. Но сам этот вопрос говорит о том, что тебе крайне сложно будет объяснить о чем речь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>За решение определенного класса проблем. Но сам этот вопрос говорит о том, что тебе крайне сложно будет объяснить о чем речь.
Очень сложно, ты прав
Я продукт мигрировал Оракла на Постгре и не получил ничего кроме облегчения.
Сейчас я кстати с Оракла на Гугл Спаннер мигрирую один телеком продукт, но это другая история.
GIV>Очень сложно, ты прав GIV>Я продукт мигрировал Оракла на Постгре и не получил ничего кроме облегчения. GIV>Сейчас я кстати с Оракла на Гугл Спаннер мигрирую один телеком продукт, но это другая история.
в эпоху бигдаты весьма глупое у тебя занятие. чуть подрастет нагрузка и в первом случае у тебя встанет колом не умеющий масштабироваться из-за сборки мусора постгре, хранящий мусор прямо в датафайлах. убер это проходил. во втором случае гарантированно сдохнет бизнес от счетов.
Здравствуйте, Gt_, Вы писали:
GIV>>Очень сложно, ты прав GIV>>Я продукт мигрировал Оракла на Постгре и не получил ничего кроме облегчения. GIV>>Сейчас я кстати с Оракла на Гугл Спаннер мигрирую один телеком продукт, но это другая история.
Gt_>в эпоху бигдаты весьма глупое у тебя занятие. чуть подрастет нагрузка и в первом случае у тебя встанет колом не умеющий масштабироваться из-за сборки мусора постгре, хранящий мусор прямо в датафайлах. убер это проходил.
Нормально там все с бигдатой, поверь на слово, проверено эксплуатацией у крупных провайдеров типа Билайна.
Gt_>во втором случае гарантированно сдохнет бизнес от счетов.
Я не считал, надеюсь специально обученные люди провели все расчеты
Начальство делало доклад на гугл некст, народ был excited
Но вообще выбор, как я знаю, был из-за ограниченной маштабируемости Оракла.
Здравствуйте, ·, Вы писали:
·>В том что противоречит фактам.
Никаким фактам это не противоречит.
·>Не понял я... кто чего не говорит? Явно же говорилось, какие варианты они не стали брать. Oracle RAC, например.
Ну вот тот факт, что они не стали брать Оракл, ничего не говорит про Оракл. Их кейс говорит только про тот вариант который они взяли, а не про тот который не взяли.
·>Какую? Название в студию.
Могну, если мне память не изменяет.
·>Сделаешь, но не в sql.
Это в ручную что ли? Ну вот "сами топите урановые ломы в ртути" (с) Зачем связываться с кв, если мне нужны джойны и мускул это сделает быстрее и проще?
·>Верно, факт в том, что FTS никто серьёзно и не использует, ибо сделан он чисто для галочки.
Факт в том, что FTS используют в тех проектах где его достаточно, где не достаточно — не используют.
Второй факт, как уже неоднократно говорилось, FTS в принципе не сиквельная задача, равно как и не NoSQL-ная, и как правило решается отдельным индексом, коим обычно и является люцена или эластик в зависимости от задачи.
Какие тут претензии к реляционкам я продолжаю не понимать.
IB>>·>Почему тогда не используют sql для этого? IB>>Для хранения используют. А для чего вы хотите SQL использовать мне не ведомо. ·> Тонкий намёк: Structured QUERY Language.
На что намек? Выражайтесь яснее, а то я точно так же могу выделить слово structured с глубокомысленным видом.
IB>>Понятия не имею что такое LSE и при чем тут MSSQL, мы же здесь про NoSQL говорим. ·>http://lmgtfy.com/?q=lse+mssql — это про доступность в mssql.
Аргумент из серии "а у вас негов линчуют". К тому же мимо — "The London Stock Exchange claimed that the TradElect software was not to blame, instead blaming an unspecified fault with network software" (с)
Причем тут реляционка? Амазон неделю назад тоже лежал по причине "unspecified fault with network software", значит как уже неоднократно утверждалось, никакой надежды на ваш NoSQL нет ))
IB>>Что должны были втащить? Поясняю, фраза "решение из коробки" относится как к noSql, так и к реляционкам. ·>Всё полезное должны были втащить. Вот цитата: "на сегодня все взрослые РСУБД обзавелись полезными фичами NoSQL".
Не понимаю как это относится к этой части разговора, поскольку как я и писал, в NoSQL этого тоже нет, поэтому и втаскивать нечего.
Но тем не менее хочу обратить внимание в приведенной же вами цитате на слово "полезными". Полезными для хранения данных. Ни кэш уровня приложения, ни FTS к таким задачам не относятся. Вот работа с JSON относится, ее и втащили в полный рост.
Мы уже победили, просто это еще не так заметно...
Тонкий намёк: Structured QUERY Language.
