Здравствуйте, Sinclair, Вы писали:
S>Ваша ошибка — в попытке оценивать сложность в отрыве от задачи. Для описания операций с данными SQL значительно проще, чем любой GPPL, будь то си, паскаль, или жава. S>И чем сложнее эти операции, тем сильнее рулит SQL.
Кстати не всё так однозначно. Иначе бы, когда появились orm, на них не ломанулись бы толпы. А сейчас вообще на nosql посматривают...
О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html
Здравствуйте, alex_public, Вы писали:
_>Кстати не всё так однозначно. Иначе бы, когда появились orm, на них не ломанулись бы толпы. А сейчас вообще на nosql посматривают...
Толпы ломанулись на ОРМ оттого, что вопрос взаимодействия прикладного кода с SQL стоял очень остро. Ну и мода — тоже большое дело. Я лично занимался ORM тогда, когда Фаулер свои "паттерны ентерпрайза" ещё не придумал. Тогда казалось, что ООП — это то, чего всем не хватает, и щасте — в ORM, который наконец-то всех спасёт.
_>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html
В целом понятно всё, кроме одного: никто до сих пор так и не смог мне объяснить про отсутствие alter table. Вот оттуда же пример с добавлением commentsByRatings — откуда они волшебным образом появятся в старых постах? Да ниоткуда.
То есть мой код должен везде быть обложен доп проверками — а вдруг нужного индекса как раз тут и не оказалось.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html S>В целом понятно всё, кроме одного: никто до сих пор так и не смог мне объяснить про отсутствие alter table. Вот оттуда же пример с добавлением commentsByRatings — откуда они волшебным образом появятся в старых постах? Да ниоткуда. S>То есть мой код должен везде быть обложен доп проверками — а вдруг нужного индекса как раз тут и не оказалось.
Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее.
Здравствуйте, alex_public, Вы писали:
_>Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее.
Тогда непонятно, в чём собственно тут преимущество.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее. S>Тогда непонятно, в чём собственно тут преимущество.
Мы говорим всё ещё про преимущества для программиста или про преимущества nosql вообще?
Второй вопрос достаточно широко освещён в последнее время и я не думаю что стоит повторять сейчас здесь все эти возможности масштабирования, реплицирования и т.п.
Ну и естественно что при выборе технологии именно это учитывается в первую очередь, а не вкусы программистов.
Но если всё же продолжить рассуждать про них, то тут мне кажется всё неоднозначно. Т.е. уже на этом форуме видно что есть много народу, который любит полностью контролировать всё происходящее с кодом. И так же есть много народу придерживающихся противоположных вкусов. Соответственно одни должны быть ближе современные nosql методы, а остальным классические sql базы. Но как я уже сказал, естественно что в нормальных условиях выбор идёт не поэтому параметру, поэтому тут может только повезти в совпадение задач и вкусов... )))
Здравствуйте, alex_public, Вы писали:
_>Мы говорим всё ещё про преимущества для программиста или про преимущества nosql вообще?
Для программиста. Статья была вроде бы про это. Вот я и не понимаю таких аргументов. Это всё равно как говорить "а вот у меня в доме зато нет этого надоедливого лифта". Офигенное преимущество — каждый раз бегать на десятый этаж пешком.
_>Второй вопрос достаточно широко освещён в последнее время и я не думаю что стоит повторять сейчас здесь все эти возможности масштабирования, реплицирования и т.п.
Не, не стоит. Тем более, что SQL и масштабируется, и реплицируется.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Для программиста. Статья была вроде бы про это. Вот я и не понимаю таких аргументов. Это всё равно как говорить "а вот у меня в доме зато нет этого надоедливого лифта". Офигенное преимущество — каждый раз бегать на десятый этаж пешком.
Ну так я и говорю дело вкуса. Сколько тут было споров про RAII vs GC? ) Причём формально говоря RAII — это как "лишний код" казалось бы. В теории... А на практике ничего подобного, если писать код правильно и на правильном языке.
И аналогично выбирается инструмент для работы не по предпочтению во вкусах, а по запросам реальной задачи. Т.е. если берём например какую-нибудь реалтайм обработку видео, то понятно что лучше взять C++. И с ним скорее всего автоматом придёт RAII, что возможно будет по вкусу разработчику, а может и нет. )))
S>Не, не стоит. Тем более, что SQL и масштабируется, и реплицируется.
Ну да, ну да. И на php в теории можно писать для HPC...
Здравствуйте, alex_public, Вы писали:
_>Ну так я и говорю дело вкуса. Сколько тут было споров про RAII vs GC? ) Причём формально говоря RAII — это как "лишний код" казалось бы. В теории... А на практике ничего подобного, если писать код правильно и на правильном языке.
Не видел я таких споров. RAII никак не противоречит GC — это ортогональные штуки.
_>И аналогично выбирается инструмент для работы не по предпочтению во вкусах, а по запросам реальной задачи. Т.е. если берём например какую-нибудь реалтайм обработку видео, то понятно что лучше взять C++. И с ним скорее всего автоматом придёт RAII, что возможно будет по вкусу разработчику, а может и нет. )))
Я понимаю, когда выбирается инструмент. Не понимаю, когда выбирается отсутствие инструмента.
_>Ну да, ну да. И на php в теории можно писать для HPC...
При чём тут "в теории". Вон stackoverflow работает на MS SQL и не жужжит. Мало кому из современных веб-проектов грозит такая нагрузка. Я понимаю, что SQL годится не для всего — скажем, результаты экспериментов на коллайдере складывают, АФАИК, в нереляционную базу. Но там это реально оправдано. А в жизни мы наблюдаем такие аргументы от NoSQL, которые прямо-таки рекламируют SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не видел я таких споров. RAII никак не противоречит GC — это ортогональные штуки.
Ну да, формально споры GC против ручного управления памятью. Но последнее сделанное не через RAII — это уже мазохизм. ))) Хотя временами и такое бывает необходимо.
S>Я понимаю, когда выбирается инструмент. Не понимаю, когда выбирается отсутствие инструмента.
Ооо, вот как раз так и было в прошлом (во времена беркли дб). И тогда nosql выбирали только в очень специальных случаях. Но это давно изменилось. Сейчас то появились именно инструменты. Т.е. сейчас мы ставим какую-нибудь mongodb + MongoAlchemy и наслаждаемся результатом сразу.
S>При чём тут "в теории". Вон stackoverflow работает на MS SQL и не жужжит.
Ну так мы же не знаем чего это им стоило.
S>Мало кому из современных веб-проектов грозит такая нагрузка.
У всяких гуглов, фейсбуков, твитеров меньше что ли? )
S>Я понимаю, что SQL годится не для всего — скажем, результаты экспериментов на коллайдере складывают, АФАИК, в нереляционную базу. Но там это реально оправдано. А в жизни мы наблюдаем такие аргументы от NoSQL, которые прямо-таки рекламируют SQL.
Здравствуйте, alex_public, Вы писали:
_>Ооо, вот как раз так и было в прошлом (во времена беркли дб). И тогда nosql выбирали только в очень специальных случаях. Но это давно изменилось. Сейчас то появились именно инструменты. Т.е. сейчас мы ставим какую-нибудь mongodb + MongoAlchemy и наслаждаемся результатом сразу.
Я не против — только раскройте тему. Я читаю конкретный аргумент: "нету alter table". На вопрос "а как вы меняете структуру существующих данных" ответ простой "а никак". Я же говорю — вы решили проблему с лифтом, который надо было каждый раз вызывать и нажимать эти непонятные кнопки. А иногда он вообще застревал (ну, не у меня, но я знаю чувака, который читал про это на форуме). Теперь вы можете сразу бежать на десятый этаж пешком, детально контролируя весь процесс подъёма.
_>Ну так мы же не знаем чего это им стоило.
Отлично знаем. Инфа про них лежит в открытом доступе.
_>У всяких гуглов, фейсбуков, твитеров меньше что ли? )
И сколько гуглов, фейсбуков, и твиттеров вы пишете в год?
_>Нуу не знаю. Например если взглянуть сюда http://www.mongodb.org/display/DOCS/Production+Deployments то мы увидим явно не только коллайдер. А это всего лишь один из многих nosql движков.
Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.
А что тут непонятного. SQL достаточно сложный сам по себе, а в контексте БД это вообще капец (консистентность, локи, дедлоки и пр.). В результате SQL народ не знает. Некоторые считают, что это проблема народа, но по факту это проблема SQL. Как только цена мегабайта ОЗУ упала до определённой отметки и размер ОЗУ в Гб смог хранить весь working-set типичного приложения, так народ и показал фигу SQL. Фактически, как только позволила техническая БД, так сразу и сбылась мечта ООБД-истов.
А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом.
Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся.
Конечно, по мере, развития ситуации опять появится куча данных, которые не влазят в ОЗУ и по которым нужно делать интерактивные ad-hoc запросы (сейчас там hadoop, но он не интерактивный) и там будут RDBMS. Но SQL должны будут знать единицы по сравнению с текущей ситуацией. По факту человек знающий SQL будет как сантехник сейчас — их мало и никто их не любит.
S>>Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.
ANS>А что тут непонятного. SQL достаточно сложный сам по себе, а в контексте БД это вообще капец (консистентность, локи, дедлоки и пр.). В результате SQL народ не знает.
Локи к SQL не имеют отношения. Конкурентный доступ вообще сложная тема и БД она еще очень хорошо решается по сравнению например с мейнстримовыми ЯП.
ANS>Некоторые считают, что это проблема народа, но по факту это проблема SQL.
Тогда уж проблема реляционной модели.
ANS>Как только цена мегабайта ОЗУ упала до определённой отметки и размер ОЗУ в Гб смог хранить весь working-set типичного приложения, так народ и показал фигу SQL. Фактически, как только позволила техническая БД, так сразу и сбылась мечта ООБД-истов.
А причем тут память? Конкурентный доступ и требование durable транзакций остается.
ANS>А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом.
Для говносайтов такое вполне может быть, для серьезных приложений — никогда.
ANS>Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся.
Покачто применение noSQL не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет.
Здравствуйте, gandjustas, Вы писали:
G> она еще очень хорошо решается
Угу, просто мало людей, которые понимают, что с этим решение делать.
ANS>>Некоторые считают, что это проблема народа, но по факту это проблема SQL. G>Тогда уж проблема реляционной модели.
Хоть лбом, хоть по лбу.
G>А причем тут память? Конкурентный доступ
Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?
Да и, ты говоришь так, будто этим "Конкурентным доступ" просто бери и пользуйся. А фиг.
G>и требование durable транзакций остается.
Да-да. Помню помню, недавно обсуждалось. Всё закончилось, тем, что "durable" это не когда данные сохраняются, а когда сервер после сбоя быстро стартует.
ANS>>А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом. G>Для говносайтов такое вполне может быть, для серьезных приложений — никогда.
Бу-га-га. См. выше про дюрабилити. И вот такие вот 99.9% "серьезных приложений".
ANS>>Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся. G>Покачто применение noSQL не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет.
Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
G>>А причем тут память? Конкурентный доступ
ANS>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?
Ты о чем? 8-ка полагается на механизмы SQL Server.
ANS>Да и, ты говоришь так, будто этим "Конкурентным доступ" просто бери и пользуйся. А фиг.
По сравнению с другими способами разруливания — да, бери и пользуйся. Потому что в основе математика.
А что будет с nosql базой если одновременно два запроса за запись придут? А если они придут на разные шарды?
G>>и требование durable транзакций остается. ANS>Да-да. Помню помню, недавно обсуждалось. Всё закончилось, тем, что "durable" это не когда данные сохраняются, а когда сервер после сбоя быстро стартует.
Это ты такое утверждал. Все остальные говорят что durable это когда изменения остаются после commit пока целостность хранилища не нарушена.
SQL такое обеспечивает целостность данных, ссылочную целостность и целостность индексов, даже если сразу после commit все упадет. А nosql, кроме отдельных отдельных образцов, не обеспечивает и такого. Даже то что после записи данные будут доступны.
ANS>>>А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом. G>>Для говносайтов такое вполне может быть, для серьезных приложений — никогда.
ANS>Бу-га-га. См. выше про дюрабилити. И вот такие вот 99.9% "серьезных приложений".
Ты о чем вообще? Сколько раз сам наблюдал нарушение целостности БД какого нить SQL Server без поломок дисков?
А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно.
Может поправили, но это не было нештатных ситуаций.
ANS>>>Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся. G>>Покачто применение noSQL не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет. ANS>Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно.
А он тут причем?
Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.
Здравствуйте, Sinclair, Вы писали:
S>Я не против — только раскройте тему.
Я возможно изначально не очень чётко выразил свою точку зрения на всё это.
Все преимущества nosql заложены в них изначально по самому принципу строения. Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.
Т.е. допустим нам для решения задачи первоначально достаточно даже sqlite. Но благодаря тому, что современные nosql инструменты позволяют потратить на разработку времени не больше чем для sqlite варианта, мы можем сразу заложиться хоть на 1000 кратный рост нагрузки. Т.е. особо важным этот новый тренд является как раз для стартапов и т.п., т.к. всяческие монстры и так в большинстве своём используют nosql базы (часто собственной разработки).
Снова немного сумбурно вышло. Но нельзя подробно объяснить подобное не делая полноценную статью. Да и я почему то был уверен что здесь все уже давно обчитались подобных статей.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sinclair, Вы писали:
S>>Я не против — только раскройте тему.
_>Я возможно изначально не очень чётко выразил свою точку зрения на всё это.
_>Все преимущества nosql заложены в них изначально по самому принципу строения.
Это какие такие преимущества? Какой принцип строения?
_>Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.
За счет чего снята?
_>Т.е. допустим нам для решения задачи первоначально достаточно даже sqlite. Но благодаря тому, что современные nosql инструменты позволяют потратить на разработку времени не больше чем для sqlite варианта, мы можем сразу заложиться хоть на 1000 кратный рост нагрузки. Т.е. особо важным этот новый тренд является как раз для стартапов и т.п., т.к. всяческие монстры и так в большинстве своём используют nosql базы (часто собственной разработки).
Как раз "монстры" используют вполне промышленные субд, а вот nosql там в основном для кеширования и других, далеко не критичных, плюшек.
_>Снова немного сумбурно вышло. Но нельзя подробно объяснить подобное не делая полноценную статью. Да и я почему то был уверен что здесь все уже давно обчитались подобных статей.
Проблема одна — в статьях (и у тебя тоже) лозунги. Как доходит до дела
. Вообще интересная тема получилась, если бы не желание некоторых обсуждать личности. Там есть пара примеров когда MS SQL заруливает на тех задачах, которые вроде как приписываются NoSQL как основные.
Здравствуйте, gandjustas, Вы писали:
G>А вот тот же ravendb (очень крутой nosql движок)
Сколько смотрел разного про nosql, но ни разу не слышал про ravendb. Сейчас глянул в гугле (ссылок то как мало на него): http://ravendb.net/testimonials — что-то совсем не впечатляющее. Теперь понятно откуда такие воззрения... )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.
_>Ээээ, десяток сервисов гугла подойдёт? )))
Не подойдет. Гугл уже терял всю почту на многих ящиках gmail. Вот тебе и репликация. Кроме того они вполне могут под свои особенности адаптировать движок, что в обычных проектах разработчики позволить себе не могут.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>А вот тот же ravendb (очень крутой nosql движок)
_>Сколько смотрел разного про nosql, но ни разу не слышал про ravendb. Сейчас глянул в гугле (ссылок то как мало на него): http://ravendb.net/testimonials — что-то совсем не впечатляющее. Теперь понятно откуда такие воззрения... )))
По сравнению с другими NoSQL субд Raven умеет честный acid и автоматически строить индексы. В подавляющем большинстве других баз с этим крайне плохо.
Вообще-то никто так и не привел решения задаче
