SQL vs NOSQL
От: alex_public  
Дата: 14.04.12 16:05
Оценка: 29 (2) +2
Здравствуйте, Sinclair, Вы писали:

S>Ваша ошибка — в попытке оценивать сложность в отрыве от задачи. Для описания операций с данными SQL значительно проще, чем любой GPPL, будь то си, паскаль, или жава.

S>И чем сложнее эти операции, тем сильнее рулит SQL.

Кстати не всё так однозначно. Иначе бы, когда появились orm, на них не ломанулись бы толпы. А сейчас вообще на nosql посматривают...

О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html

20.04.12 13:45: Ветка выделена из темы Языки общего назначения не имеют смысла!
Автор: WolfHound
Дата: 07.04.12
— WolfHound
Re: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 15.04.12 17:05
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Кстати не всё так однозначно. Иначе бы, когда появились orm, на них не ломанулись бы толпы. А сейчас вообще на nosql посматривают...

Толпы ломанулись на ОРМ оттого, что вопрос взаимодействия прикладного кода с SQL стоял очень остро. Ну и мода — тоже большое дело. Я лично занимался ORM тогда, когда Фаулер свои "паттерны ентерпрайза" ещё не придумал. Тогда казалось, что ООП — это то, чего всем не хватает, и щасте — в ORM, который наконец-то всех спасёт.

_>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html

В целом понятно всё, кроме одного: никто до сих пор так и не смог мне объяснить про отсутствие alter table. Вот оттуда же пример с добавлением commentsByRatings — откуда они волшебным образом появятся в старых постах? Да ниоткуда.
То есть мой код должен везде быть обложен доп проверками — а вдруг нужного индекса как раз тут и не оказалось.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[2]: SQL vs NOSQL
От: alex_public  
Дата: 16.04.12 15:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

_>>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html

S>В целом понятно всё, кроме одного: никто до сих пор так и не смог мне объяснить про отсутствие alter table. Вот оттуда же пример с добавлением commentsByRatings — откуда они волшебным образом появятся в старых постах? Да ниоткуда.
S>То есть мой код должен везде быть обложен доп проверками — а вдруг нужного индекса как раз тут и не оказалось.

Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее.
Re[3]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.04.12 06:27
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее.

Тогда непонятно, в чём собственно тут преимущество.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: SQL vs NOSQL
От: alex_public  
Дата: 17.04.12 12:39
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

_>>Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее.

S>Тогда непонятно, в чём собственно тут преимущество.

Мы говорим всё ещё про преимущества для программиста или про преимущества nosql вообще?

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

Ну и естественно что при выборе технологии именно это учитывается в первую очередь, а не вкусы программистов.

Но если всё же продолжить рассуждать про них, то тут мне кажется всё неоднозначно. Т.е. уже на этом форуме видно что есть много народу, который любит полностью контролировать всё происходящее с кодом. И так же есть много народу придерживающихся противоположных вкусов. Соответственно одни должны быть ближе современные nosql методы, а остальным классические sql базы. Но как я уже сказал, естественно что в нормальных условиях выбор идёт не поэтому параметру, поэтому тут может только повезти в совпадение задач и вкусов... )))
Re[5]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.04.12 18:17
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Мы говорим всё ещё про преимущества для программиста или про преимущества nosql вообще?

Для программиста. Статья была вроде бы про это. Вот я и не понимаю таких аргументов. Это всё равно как говорить "а вот у меня в доме зато нет этого надоедливого лифта". Офигенное преимущество — каждый раз бегать на десятый этаж пешком.

_>Второй вопрос достаточно широко освещён в последнее время и я не думаю что стоит повторять сейчас здесь все эти возможности масштабирования, реплицирования и т.п.

Не, не стоит. Тем более, что SQL и масштабируется, и реплицируется.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[6]: SQL vs NOSQL
От: alex_public  
Дата: 18.04.12 02:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Для программиста. Статья была вроде бы про это. Вот я и не понимаю таких аргументов. Это всё равно как говорить "а вот у меня в доме зато нет этого надоедливого лифта". Офигенное преимущество — каждый раз бегать на десятый этаж пешком.


Ну так я и говорю дело вкуса. Сколько тут было споров про RAII vs GC? ) Причём формально говоря RAII — это как "лишний код" казалось бы. В теории... А на практике ничего подобного, если писать код правильно и на правильном языке.

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

S>Не, не стоит. Тем более, что SQL и масштабируется, и реплицируется.


Ну да, ну да. И на php в теории можно писать для HPC...
Re[7]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 18.04.12 03:41
Оценка: +2
Здравствуйте, alex_public, Вы писали:

_>Ну так я и говорю дело вкуса. Сколько тут было споров про RAII vs GC? ) Причём формально говоря RAII — это как "лишний код" казалось бы. В теории... А на практике ничего подобного, если писать код правильно и на правильном языке.

Не видел я таких споров. RAII никак не противоречит GC — это ортогональные штуки.

_>И аналогично выбирается инструмент для работы не по предпочтению во вкусах, а по запросам реальной задачи. Т.е. если берём например какую-нибудь реалтайм обработку видео, то понятно что лучше взять C++. И с ним скорее всего автоматом придёт RAII, что возможно будет по вкусу разработчику, а может и нет. )))

Я понимаю, когда выбирается инструмент. Не понимаю, когда выбирается отсутствие инструмента.

_>Ну да, ну да. И на php в теории можно писать для HPC...

При чём тут "в теории". Вон stackoverflow работает на MS SQL и не жужжит. Мало кому из современных веб-проектов грозит такая нагрузка. Я понимаю, что SQL годится не для всего — скажем, результаты экспериментов на коллайдере складывают, АФАИК, в нереляционную базу. Но там это реально оправдано. А в жизни мы наблюдаем такие аргументы от NoSQL, которые прямо-таки рекламируют SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[8]: SQL vs NOSQL
От: alex_public  
Дата: 18.04.12 09:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Не видел я таких споров. RAII никак не противоречит GC — это ортогональные штуки.


Ну да, формально споры GC против ручного управления памятью. Но последнее сделанное не через RAII — это уже мазохизм. ))) Хотя временами и такое бывает необходимо.

S>Я понимаю, когда выбирается инструмент. Не понимаю, когда выбирается отсутствие инструмента.


Ооо, вот как раз так и было в прошлом (во времена беркли дб). И тогда nosql выбирали только в очень специальных случаях. Но это давно изменилось. Сейчас то появились именно инструменты. Т.е. сейчас мы ставим какую-нибудь mongodb + MongoAlchemy и наслаждаемся результатом сразу.

S>При чём тут "в теории". Вон stackoverflow работает на MS SQL и не жужжит.


Ну так мы же не знаем чего это им стоило.

S>Мало кому из современных веб-проектов грозит такая нагрузка.


У всяких гуглов, фейсбуков, твитеров меньше что ли? )

S>Я понимаю, что SQL годится не для всего — скажем, результаты экспериментов на коллайдере складывают, АФАИК, в нереляционную базу. Но там это реально оправдано. А в жизни мы наблюдаем такие аргументы от NoSQL, которые прямо-таки рекламируют SQL.


Нуу не знаю. Например если взглянуть сюда http://www.mongodb.org/display/DOCS/Production+Deployments то мы увидим явно не только коллайдер. А это всего лишь один из многих nosql движков.
Re[9]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 18.04.12 11:17
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ооо, вот как раз так и было в прошлом (во времена беркли дб). И тогда nosql выбирали только в очень специальных случаях. Но это давно изменилось. Сейчас то появились именно инструменты. Т.е. сейчас мы ставим какую-нибудь mongodb + MongoAlchemy и наслаждаемся результатом сразу.

Я не против — только раскройте тему. Я читаю конкретный аргумент: "нету alter table". На вопрос "а как вы меняете структуру существующих данных" ответ простой "а никак". Я же говорю — вы решили проблему с лифтом, который надо было каждый раз вызывать и нажимать эти непонятные кнопки. А иногда он вообще застревал (ну, не у меня, но я знаю чувака, который читал про это на форуме). Теперь вы можете сразу бежать на десятый этаж пешком, детально контролируя весь процесс подъёма.

_>Ну так мы же не знаем чего это им стоило.

Отлично знаем. Инфа про них лежит в открытом доступе.

_>У всяких гуглов, фейсбуков, твитеров меньше что ли? )

И сколько гуглов, фейсбуков, и твиттеров вы пишете в год?

_>Нуу не знаю. Например если взглянуть сюда http://www.mongodb.org/display/DOCS/Production+Deployments то мы увидим явно не только коллайдер. А это всего лишь один из многих nosql движков.

Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.04.12 13:59
Оценка: -1 :))) :))) :))
S>Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.

А что тут непонятного. SQL достаточно сложный сам по себе, а в контексте БД это вообще капец (консистентность, локи, дедлоки и пр.). В результате SQL народ не знает. Некоторые считают, что это проблема народа, но по факту это проблема SQL. Как только цена мегабайта ОЗУ упала до определённой отметки и размер ОЗУ в Гб смог хранить весь working-set типичного приложения, так народ и показал фигу SQL. Фактически, как только позволила техническая БД, так сразу и сбылась мечта ООБД-истов.
А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом.
Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся.
Конечно, по мере, развития ситуации опять появится куча данных, которые не влазят в ОЗУ и по которым нужно делать интерактивные ad-hoc запросы (сейчас там hadoop, но он не интерактивный) и там будут RDBMS. Но SQL должны будут знать единицы по сравнению с текущей ситуацией. По факту человек знающий SQL будет как сантехник сейчас — их мало и никто их не любит.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.04.12 15:05
Оценка: :)
Здравствуйте, Andrei N.Sobchuck, Вы писали:


S>>Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.


ANS>А что тут непонятного. SQL достаточно сложный сам по себе, а в контексте БД это вообще капец (консистентность, локи, дедлоки и пр.). В результате SQL народ не знает.

Локи к SQL не имеют отношения. Конкурентный доступ вообще сложная тема и БД она еще очень хорошо решается по сравнению например с мейнстримовыми ЯП.


ANS>Некоторые считают, что это проблема народа, но по факту это проблема SQL.

Тогда уж проблема реляционной модели.

ANS>Как только цена мегабайта ОЗУ упала до определённой отметки и размер ОЗУ в Гб смог хранить весь working-set типичного приложения, так народ и показал фигу SQL. Фактически, как только позволила техническая БД, так сразу и сбылась мечта ООБД-истов.

А причем тут память? Конкурентный доступ и требование durable транзакций остается.

ANS>А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом.

Для говносайтов такое вполне может быть, для серьезных приложений — никогда.

ANS>Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся.

Покачто применение noSQL не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[12]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.04.12 16:14
Оценка:
Здравствуйте, 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 не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет.

Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.04.12 18:46
Оценка:
Здравствуйте, 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, я тебе поверю.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[10]: SQL vs NOSQL
От: alex_public  
Дата: 18.04.12 21:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я не против — только раскройте тему.


Я возможно изначально не очень чётко выразил свою точку зрения на всё это.

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

Т.е. допустим нам для решения задачи первоначально достаточно даже sqlite. Но благодаря тому, что современные nosql инструменты позволяют потратить на разработку времени не больше чем для sqlite варианта, мы можем сразу заложиться хоть на 1000 кратный рост нагрузки. Т.е. особо важным этот новый тренд является как раз для стартапов и т.п., т.к. всяческие монстры и так в большинстве своём используют nosql базы (часто собственной разработки).

Снова немного сумбурно вышло. Но нельзя подробно объяснить подобное не делая полноценную статью. Да и я почему то был уверен что здесь все уже давно обчитались подобных статей.
Re[14]: SQL vs NOSQL
От: alex_public  
Дата: 18.04.12 21:22
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.


Ээээ, десяток сервисов гугла подойдёт? )))
Re[11]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.04.12 21:33
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>>Я не против — только раскройте тему.


_>Я возможно изначально не очень чётко выразил свою точку зрения на всё это.


_>Все преимущества nosql заложены в них изначально по самому принципу строения.

Это какие такие преимущества? Какой принцип строения?

_>Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.

За счет чего снята?

_>Т.е. допустим нам для решения задачи первоначально достаточно даже sqlite. Но благодаря тому, что современные nosql инструменты позволяют потратить на разработку времени не больше чем для sqlite варианта, мы можем сразу заложиться хоть на 1000 кратный рост нагрузки. Т.е. особо важным этот новый тренд является как раз для стартапов и т.п., т.к. всяческие монстры и так в большинстве своём используют nosql базы (часто собственной разработки).

Как раз "монстры" используют вполне промышленные субд, а вот nosql там в основном для кеширования и других, далеко не критичных, плюшек.

_>Снова немного сумбурно вышло. Но нельзя подробно объяснить подобное не делая полноценную статью. Да и я почему то был уверен что здесь все уже давно обчитались подобных статей.

Проблема одна — в статьях (и у тебя тоже) лозунги. Как доходит до дела
Автор: gandjustas
Дата: 29.09.10
сразу в кусты
Автор: Философ
Дата: 04.02.12
. Вообще интересная тема получилась, если бы не желание некоторых обсуждать личности. Там есть пара примеров когда MS SQL заруливает на тех задачах, которые вроде как приписываются NoSQL как основные.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[14]: SQL vs NOSQL
От: alex_public  
Дата: 18.04.12 21:34
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А вот тот же ravendb (очень крутой nosql движок)


Сколько смотрел разного про nosql, но ни разу не слышал про ravendb. Сейчас глянул в гугле (ссылок то как мало на него): http://ravendb.net/testimonials — что-то совсем не впечатляющее. Теперь понятно откуда такие воззрения... )))
Re[15]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.04.12 21:35
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.


_>Ээээ, десяток сервисов гугла подойдёт? )))


Не подойдет. Гугл уже терял всю почту на многих ящиках gmail. Вот тебе и репликация. Кроме того они вполне могут под свои особенности адаптировать движок, что в обычных проектах разработчики позволить себе не могут.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[15]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.04.12 21:40
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>А вот тот же ravendb (очень крутой nosql движок)


_>Сколько смотрел разного про nosql, но ни разу не слышал про ravendb. Сейчас глянул в гугле (ссылок то как мало на него): http://ravendb.net/testimonials — что-то совсем не впечатляющее. Теперь понятно откуда такие воззрения... )))


По сравнению с другими NoSQL субд Raven умеет честный acid и автоматически строить индексы. В подавляющем большинстве других баз с этим крайне плохо.
Вообще-то никто так и не привел решения задаче
Автор: gandjustas
Дата: 29.09.10
. Дерзай, базу можешь брать любую.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[11]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.04.12 06:53
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Все преимущества nosql заложены в них изначально по самому принципу строения. Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.

Я продолжаю непонимать, что это за преимущества. Все почему-то делают вид, что они очевидны, но когда начинаешь копать, все преимущества начинаются со слова no. Типа "у нас нет языка запросов, нет поддержки индексов, нет гарантий целостности". Отлично. Преимущество-то в чём?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[14]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.04.12 08:00
Оценка:
Здравствуйте, gandjustas, Вы писали:

ANS>>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?

G>Ты о чем? 8-ка полагается на механизмы SQL Server.

Ну, вот привели там пример гигантской обработки на C# под Парус. Допустим в её середине вылетело исключение "SQLState 40001". Его обрабатывает сама платформа, или проталкивает наверх к прикладному программисту (что ему делать)? Или платформа что-то делает, чтобы такие ошибки в принципе не вылетали?

ANS>>Да и, ты говоришь так, будто этим "Конкурентным доступ" просто бери и пользуйся. А фиг.

G>По сравнению с другими способами разруливания — да, бери и пользуйся. Потому что в основе математика.
G>А что будет с nosql базой если одновременно два запроса за запись придут? А если они придут на разные шарды?

Хе-хе. Понятия "одновременно" в распределённой системе нету. Нет понятия — нет проблемы

G>>>и требование durable транзакций остается.

ANS>>Да-да. Помню помню, недавно обсуждалось. Всё закончилось, тем, что "durable" это не когда данные сохраняются, а когда сервер после сбоя быстро стартует.
G>Это ты такое утверждал.

Избирательная память
Автор: Andrei N.Sobchuck
Дата: 06.02.11
? Бывает.

G>Все остальные говорят что durable это когда изменения остаются после commit пока целостность хранилища не нарушена.

G>SQL такое обеспечивает целостность данных, ссылочную целостность и целостность индексов, даже если сразу после commit все упадет. А nosql, кроме отдельных отдельных образцов, не обеспечивает и такого. Даже то что после записи данные будут доступны.

Всё так. Но сама по себе RDBM сейчас никому не нужна. Нужна система с которой пользователь взаимодействует. И тут возникает парадокс, система построена на RDBM, у RDBM гарантии ACID есть, а у системы в целом — нет.

ANS>>Бу-га-га. См. выше про дюрабилити. И вот такие вот 99.9% "серьезных приложений".

G>Ты о чем вообще? Сколько раз сам наблюдал нарушение целостности БД какого нить SQL Server без поломок дисков?

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

G>А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно.

G>Может поправили, но это не было нештатных ситуаций.

Никогда ни про какой ravendb не слышал. Но в любом случае, это проблема незрелости. Со временем это пройдёт. Сейчас время NoSql систем построенных поверх зрелого SQL
Автор: Andrei N.Sobchuck
Дата: 07.02.11
.

ANS>>Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно.

G>А он тут причем?

Выучишь кошерный JavaScript

G>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.


А смысл? Ну буду я что-то называть
Автор: Andrei N.Sobchuck
Дата: 07.02.11
, так сразу начнётся, то не все для атомных станций софт пишут, то не все фейсбуки пишут, то не все просто пишут.
Ты просто осознай, что вот есть какой-то там MySql (ACID не смотря на технологические огрехи). Прикрутили люди поперед него memcached — почти 100% стала nosql система. Притом сразу с багами. Организовали шарды — nosql.
Работает это всё случайно. Может и не работает, но разработчики не замечают то.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[12]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 08:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


Эмм, ну основное то преимущество "by design" известно всем вроде. Что вместо такого http://www.hi-lo.ru/news/clustrix-helps-scaling-without-sharding или http://habrahabr.ru/post/72122/ мы делаем просто так http://gliffer.ru/articles/nosql--sharding-mongodb-na-paltsah/ и всё. У нас же задачи всё же определяет бизнес, а не кто-то ещё. А если взглянуть на цены первых двух ссылок, то всё становится очевидно.

Но вообще частенько (это уже зависит от конкретной задачи) преимущества проявляются и в случае одной машины. Например в комментах к этой статье http://habrahabr.ru/post/74144/ интересный пример человек приводит. Кстати, и сама статья любопытная в контексте нашего обсуждения.

Что касается языка запросов, то тут не всё так однозначно. ))) Например здесь http://www.unqlspec.org/display/UnQL/Example+Queries+and+Usage можно взглянуть на пример такого языка для nosql, продвигаемого авторами одного из движков. Естественно совсем не обязательно что это станет каким-то стандартом. Но что бы "оценить суть" он вполне показателен.
Re[15]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 08:38
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


ANS>>>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?

G>>Ты о чем? 8-ка полагается на механизмы SQL Server.

ANS>Ну, вот привели там пример гигантской обработки на C# под Парус. Допустим в её середине вылетело исключение "SQLState 40001". Его обрабатывает сама платформа, или проталкивает наверх к прикладному программисту (что ему делать)? Или платформа что-то делает, чтобы такие ошибки в принципе не вылетали?


Абстрактная ошибка в абстрактном коде будет также абстрактно обрабатываться.
Ты чего сказать то хотел?

ANS>>>Да и, ты говоришь так, будто этим "Конкурентным доступ" просто бери и пользуйся. А фиг.

G>>По сравнению с другими способами разруливания — да, бери и пользуйся. Потому что в основе математика.
G>>А что будет с nosql базой если одновременно два запроса за запись придут? А если они придут на разные шарды?
ANS>Хе-хе. Понятия "одновременно" в распределённой системе нету. Нет понятия — нет проблемы
Как нету? Ты хочешь сказать что операции записи успеваю проходить между запросами пользоваелей? Или как?
На практике не успевают. Вот у mongodb вообще глобальный лок при записи. Так что на одном серваке вообще никакого перформанса не будет. Даже хуже чем serializable в РСУБД поставить.

G>>>>и требование durable транзакций остается.

ANS>>>Да-да. Помню помню, недавно обсуждалось. Всё закончилось, тем, что "durable" это не когда данные сохраняются, а когда сервер после сбоя быстро стартует.
G>>Это ты такое утверждал.
ANS>Избирательная память
Автор: Andrei N.Sobchuck
Дата: 06.02.11
? Бывает.

Так это и не я утверждал.

G>>Все остальные говорят что durable это когда изменения остаются после commit пока целостность хранилища не нарушена.

G>>SQL такое обеспечивает целостность данных, ссылочную целостность и целостность индексов, даже если сразу после commit все упадет. А nosql, кроме отдельных отдельных образцов, не обеспечивает и такого. Даже то что после записи данные будут доступны.

ANS>Всё так. Но сама по себе RDBM сейчас никому не нужна. Нужна система с которой пользователь взаимодействует. И тут возникает парадокс, система построена на RDBM, у RDBM гарантии ACID есть, а у системы в целом — нет.

Если система в целом ниче криминального с базой не делает, а честно туда пишет изменения, то как это acid нету?
Ты покажи пример чтоли того о чем ты говоришь. Только не абстрактный, а конкретный.

ANS>>>Бу-га-га. См. выше про дюрабилити. И вот такие вот 99.9% "серьезных приложений".

G>>Ты о чем вообще? Сколько раз сам наблюдал нарушение целостности БД какого нить SQL Server без поломок дисков?
ANS>См. выше. Толку с этих гарантий если в куче случаев разработчик опираясь на них на выходе пшик получает.
Так это проблема разработчика. Ты предлагаешь сразу все гарантии отбросить чтобы разработчикам проще было? Это говнософт получается.


G>>А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно.

G>>Может поправили, но это не было нештатных ситуаций.

ANS>Никогда ни про какой ravendb не слышал. Но в любом случае, это проблема незрелости. Со временем это пройдёт. Сейчас время NoSql систем построенных поверх зрелого SQL
Автор: Andrei N.Sobchuck
Дата: 07.02.11
.

Тогда возвращаемся к вопросу что такое NoSQL. Очевидны проблемы с позиционированием таких систем.

ANS>>>Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно.

G>>А он тут причем?
ANS>Выучишь кошерный JavaScript
Я его и так знаю, это тут при чем?

G>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.


ANS>А смысл? Ну буду я что-то называть
Автор: Andrei N.Sobchuck
Дата: 07.02.11
, так сразу начнётся, то не все для атомных станций софт пишут, то не все фейсбуки пишут, то не все просто пишут.

ANS>Ты просто осознай, что вот есть какой-то там MySql (ACID не смотря на технологические огрехи). Прикрутили люди поперед него memcached — почти 100% стала nosql система. Притом сразу с багами. Организовали шарды — nosql.
ANS>Работает это всё случайно. Может и не работает, но разработчики не замечают то.
MySQL + кеш это NoSQL?
Тогда вообще о чем разговор? Если в основе все равно лежит SQL БД, с которой надо работать.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[12]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 08:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это какие такие преимущества? Какой принцип строения?


Ответил в сообщение для Sinclair)

_>>Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.

G>За счет чего снята?

За счёт появления массы уже разработаных решений. Как "подарков от монстров", которые они выкладывают на допиливание, так и собственно небольших разработок. Для большинства задач уже можно найти практически готовое решение. Более того, всякие фреймворки уже начинают включать nosql базы в набор поддерживаемых.

G>Как раз "монстры" используют вполне промышленные субд, а вот nosql там в основном для кеширования и других, далеко не критичных, плюшек.


Эмм, гугл, яндекс, амазон — они хранят данные в sql? )))

G>Проблема одна — в статьях (и у тебя тоже) лозунги. Как доходит до дела
Автор: gandjustas
Дата: 29.09.10
сразу в кусты
Автор: Философ
Дата: 04.02.12
. Вообще интересная тема получилась, если бы не желание некоторых обсуждать личности. Там есть пара примеров когда MS SQL заруливает на тех задачах, которые вроде как приписываются NoSQL как основные.


Не видел раньше этой темки. Наверное уже не буду её сейчас всю читать. Но первое сообщение прочитал. Если бы я делал проект с нуля, то взял бы nosql решение. Т.к. разработка не была бы сложнее, а при этом я был бы абсолютно спокоен за будущее, а не думал бы постоянно "укладываемся ли мы ещё одну машину или уже нет" (тут же не только объём базы важен, но и количество запросов).
Re[16]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 08:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.

_>>Ээээ, десяток сервисов гугла подойдёт? )))
G>Не подойдет. Гугл уже терял всю почту на многих ящиках gmail. Вот тебе и репликация.

От этого оно перестало быть "серьёзным приложением"? ))) Тогда интересует определение "серьёзного приложения".

G>Кроме того они вполне могут под свои особенности адаптировать движок, что в обычных проектах разработчики позволить себе не могут.


Так я про это и писал. Более того, большинство "монстров" не адаптировали что-то, а разработали с нуля под себя. А уже потом многие выложили свои разработки на допиливание сообществом — тут и пошло развитие этой тематики в массы...
Re[13]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 09:04
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>Это какие такие преимущества? Какой принцип строения?


_>Ответил в сообщение для Sinclair)


Прочитал, ответа не увидел. Давай по продяку, назови что умеет NoSQL (любая база на выбор) и не умеет MS SQL например.

_>>>Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.

G>>За счет чего снята?

_>За счёт появления массы уже разработаных решений. Как "подарков от монстров", которые они выкладывают на допиливание, так и собственно небольших разработок. Для большинства задач уже можно найти практически готовое решение. Более того, всякие фреймворки уже начинают включать nosql базы в набор поддерживаемых.

Тогда любой ORM с Linq на C# снимает вообще все проблемы разработки на SQL БД.

G>>Как раз "монстры" используют вполне промышленные субд, а вот nosql там в основном для кеширования и других, далеко не критичных, плюшек.

_>Эмм, гугл, яндекс, амазон — они хранят данные в sql? )))
У яндекса вроде как MySQL. Mail.ru пользуется MS SQL, хотя хз для чего. У гугла свой движок, непонятно что там внутри. Гугл кстати хорошо умеет терять данные, за нескоолько лет прецеденты уже возникали. Facebook — MySQL, Твиттер — MySQL (сейчас только как бекап хранилище), Stackoverflow — MS SQL.

Посчитай суммарный объем данных\количество запросов по всему stackexchange — охренеешь сколько там всего.

G>>Проблема одна — в статьях (и у тебя тоже) лозунги. Как доходит до дела
Автор: gandjustas
Дата: 29.09.10
сразу в кусты
Автор: Философ
Дата: 04.02.12
. Вообще интересная тема получилась, если бы не желание некоторых обсуждать личности. Там есть пара примеров когда MS SQL заруливает на тех задачах, которые вроде как приписываются NoSQL как основные.


_>Не видел раньше этой темки. Наверное уже не буду её сейчас всю читать. Но первое сообщение прочитал. Если бы я делал проект с нуля, то взял бы nosql решение. Т.к. разработка не была бы сложнее, а при этом я был бы абсолютно спокоен за будущее, а не думал бы постоянно "укладываемся ли мы ещё одну машину или уже нет" (тут же не только объём базы важен, но и количество запросов).


Там есть хорошая задача и её решение
Автор: gandjustas
Дата: 25.01.12
. Сделай его на nosql, покажи результаты.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[13]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.04.12 09:07
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Эмм, ну основное то преимущество "by design" известно всем вроде. Что вместо такого http://www.hi-lo.ru/news/clustrix-helps-scaling-without-sharding или http://habrahabr.ru/post/72122/ мы делаем просто так http://gliffer.ru/articles/nosql--sharding-mongodb-na-paltsah/ и всё. У нас же задачи всё же определяет бизнес, а не кто-то ещё. А если взглянуть на цены первых двух ссылок, то всё становится очевидно.

Ок, понятно. Не всё, правда, но понятно. Я просто в 2001 году занимался проектом, где юзеров было под 1 миллион. Бегало всё на старом и тупом Interbase 5.6 с тогдашним железом. Поэтому рассказы о том, что одиночный сервер в 2012 году внезапно перестаёт справляться при "росте до 4х миллионов подписчиков" я принимаю скептически.
Вот типичные рассуждения дилетанта: http://highload.com.ua/index.php/2009/05/06/%D1%88%D0%B0%D1%80%D0%B4%D0%B8%D0%BD%D0%B3-%D0%BF%D0%B0%D1%80%D1%82%D0%B8%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86/

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

Чисто для справки: мировой рекорд по TPC-C поставлен на системе полной стоимостью в 30 миллионов долларов. Обрабатывает 30 миллионов транзакций в минуту. Безо всяких компромиссов типа "возможны потери данных".

_>Но вообще частенько (это уже зависит от конкретной задачи) преимущества проявляются и в случае одной машины. Например в комментах к этой статье http://habrahabr.ru/post/74144/ интересный пример человек приводит. Кстати, и сама статья любопытная в контексте нашего обсуждения.

Не, ну если выбирать между MySQL и чем-то ещё, то практически всё что угодно будет лучше. Тут я спорить не собираюсь.
А у настоящих RDBMS всё гораздо лучше, чем там пишут.

_>Что касается языка запросов, то тут не всё так однозначно. ))) Например здесь http://www.unqlspec.org/display/UnQL/Example+Queries+and+Usage можно взглянуть на пример такого языка для nosql, продвигаемого авторами одного из движков. Естественно совсем не обязательно что это станет каким-то стандартом. Но что бы "оценить суть" он вполне показателен.

Ну, то есть мы имеем SQL, построенный по бесструктурным данным. Это не будет работать — нет преимуществ ни k-v баз, ни реляционных баз. Воспользоваться шардингом по ключу не удастся, т.к. нет гарантии, что запрос идёт по ключу. Воспользоваться индексами не удастся, т.к. нет структуры. В общем, имхо — это мертворождённая штука.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[16]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.04.12 09:12
Оценка:
Здравствуйте, gandjustas, Вы писали:

ANS>>>>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?

G>>>Ты о чем? 8-ка полагается на механизмы SQL Server.

ANS>>Ну, вот привели там пример гигантской обработки на C# под Парус. Допустим в её середине вылетело исключение "SQLState 40001". Его обрабатывает сама платформа, или проталкивает наверх к прикладному программисту (что ему делать)? Или платформа что-то делает, чтобы такие ошибки в принципе не вылетали?


G>Абстрактная ошибка в абстрактном коде будет также абстрактно обрабатываться.

G>Ты чего сказать то хотел?

Код конкретный
Автор: AndrewVK
Дата: 14.04.12
, ошибка тоже — конкретней не бывает.

G>Как нету?

Так нету. По сути тебе ничего не отвечу, потому что сути вопроса не понимаю.

G>Так это и не я утверждал.

Я тебе это и не пенял.

ANS>>Всё так. Но сама по себе RDBM сейчас никому не нужна. Нужна система с которой пользователь взаимодействует. И тут возникает парадокс, система построена на RDBM, у RDBM гарантии ACID есть, а у системы в целом — нет.

G>Если система в целом ниче криминального с базой не делает, а честно туда пишет изменения, то как это acid нету?
G>Ты покажи пример чтоли того о чем ты говоришь. Только не абстрактный, а конкретный.

Я ж написал. Почти любая система с memcached. Проблема в том, что эти самые данные записать это последний шаг. До этого их нужно вычитать и обработать.

G>Так это проблема разработчика.


Ошибаешься. Раньше людей делали для БД. Сейчас появляется техническая возможность БД делать для людей.

G>Ты предлагаешь сразу все гарантии отбросить чтобы разработчикам проще было? Это говнософт получается.


Нет. Я предлагаю явно определить каких гарантий нет, какие есть, чего это стоит.

G>>>А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно.

G>>>Может поправили, но это не было нештатных ситуаций.

ANS>>Никогда ни про какой ravendb не слышал. Но в любом случае, это проблема незрелости. Со временем это пройдёт. Сейчас время NoSql систем построенных поверх зрелого SQL
Автор: Andrei N.Sobchuck
Дата: 07.02.11
.

G>Тогда возвращаемся к вопросу что такое NoSQL. Очевидны проблемы с позиционированием таких систем.

Я своё мнение
Автор: Andrei N.Sobchuck
Дата: 25.01.12
пока не поменял. И, да, проблемы с позиционированием есть.

G>>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.


G>MySQL + кеш это NoSQL?

G>Тогда вообще о чем разговор? Если в основе все равно лежит SQL БД, с которой надо работать.
Нет, работать нужно с другим уровнем и другими гарантиями.
Автор: Andrei N.Sobchuck
Дата: 07.02.11
. Просто сейчас люди делают это неявно и ожидают ACID гарантий. Я предлагаю делать явно, по четко определённому протоколу, с четким определением существующих гарантий.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 09:40
Оценка: 2 (1)
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


ANS>>>>>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?

G>>>>Ты о чем? 8-ка полагается на механизмы SQL Server.

ANS>>>Ну, вот привели там пример гигантской обработки на C# под Парус. Допустим в её середине вылетело исключение "SQLState 40001". Его обрабатывает сама платформа, или проталкивает наверх к прикладному программисту (что ему делать)? Или платформа что-то делает, чтобы такие ошибки в принципе не вылетали?


G>>Абстрактная ошибка в абстрактном коде будет также абстрактно обрабатываться.

G>>Ты чего сказать то хотел?

ANS>Код конкретный
Автор: AndrewVK
Дата: 14.04.12
, ошибка тоже — конкретней не бывает.

С чего там ошибка? В каком месте?

G>>Как нету?

ANS>Так нету. По сути тебе ничего не отвечу, потому что сути вопроса не понимаю.
Вот именно не понимаешь. Запись в базу занимает время t1, интервал между запросами пользователей t2, если t2 < t1, то каждый запрос идет конкурентно с другим.
В SQL это разруливается низкгранулярными блокировками, в итоге два запроса могут читать-писать одновременно части одной сущности.
В NoSQL, например mongodb — writelock на сервер. При большой нагрузке и чтении\записи хотябы 10 к 1 mongo ляжет.
А на самом деле ляжет еще раньше, так как запросы выборки множества документов будут отнимать относительно много времени. И запросы записи будут курить, а пока выполняется запись — курят все остальные.

ANS>>>Всё так. Но сама по себе RDBM сейчас никому не нужна. Нужна система с которой пользователь взаимодействует. И тут возникает парадокс, система построена на RDBM, у RDBM гарантии ACID есть, а у системы в целом — нет.

G>>Если система в целом ниче криминального с базой не делает, а честно туда пишет изменения, то как это acid нету?
G>>Ты покажи пример чтоли того о чем ты говоришь. Только не абстрактный, а конкретный.

ANS>Я ж написал. Почти любая система с memcached. Проблема в том, что эти самые данные записать это последний шаг. До этого их нужно вычитать и обработать.


Да хоть 10 memcached, в memcached хранятся данные, которые отдаются клиенту, записи сразу проваливаются в БД со сбросом кеша. Следующее чтение обновляет кеш. Возможно обновление кеша сразу после записи, чтобы не ждать пока кто-нить обратится.
Такая схема дает и скорость, и acid, и является практически стандартом для нагруженных веб-приложений.

Внимание вопрос, где тут NoSQL или что оно тут может улучшить?

G>>Так это проблема разработчика.

ANS>Ошибаешься. Раньше людей делали для БД. Сейчас появляется техническая возможность БД делать для людей.
Ну правильно. Оптимизаторы БД становлятся все круче, сами оптимизируют планы, сами предлагают индексы и другие оптимизации. настройка HA и DR делается парой кликов мышки.
Над этим всем понастроены мощные фреймворки и платформы, позволяющие работать в терминах предметной области, а не таблиц и связей.

Внимание вопрос, где тут NoSQL или что оно тут может улучшить?


G>>Ты предлагаешь сразу все гарантии отбросить чтобы разработчикам проще было? Это говнософт получается.

ANS>Нет. Я предлагаю явно определить каких гарантий нет, какие есть, чего это стоит.
Так acid более чем явно гарантии дает. Если не считать багов реализации.
Вот только не всегда программист способен своим кодом гарантии не нарушать.
даже есл ты от части гарантий окажешься, то это не поможет программисту не нарушать остальные.

G>>>>А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно.

G>>>>Может поправили, но это не было нештатных ситуаций.

ANS>>>Никогда ни про какой ravendb не слышал. Но в любом случае, это проблема незрелости. Со временем это пройдёт. Сейчас время NoSql систем построенных поверх зрелого SQL
Автор: Andrei N.Sobchuck
Дата: 07.02.11
.

G>>Тогда возвращаемся к вопросу что такое NoSQL. Очевидны проблемы с позиционированием таких систем.

ANS>Я своё мнение
Автор: Andrei N.Sobchuck
Дата: 25.01.12
пока не поменял. И, да, проблемы с позиционированием есть.

Твое определение неконструктивно, не позволяет разделить системы на SQL и NoSQL.


G>>>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.


G>>MySQL + кеш это NoSQL?

G>>Тогда вообще о чем разговор? Если в основе все равно лежит SQL БД, с которой надо работать.
ANS>Нет, работать нужно с другим уровнем и другими гарантиями.
Автор: Andrei N.Sobchuck
Дата: 07.02.11
. Просто сейчас люди делают это неявно и ожидают ACID гарантий. Я предлагаю делать явно, по четко определённому протоколу, с четким определением существующих гарантий.


Тем не менее гарантии не могут быть сильнее, чем гарантии хранилища и перформанс в среднем — тоже.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[14]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 10:29
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Прочитал, ответа не увидел. Давай по продяку, назови что умеет NoSQL (любая база на выбор) и не умеет MS SQL например.


Ну например как перейти с MS SQL на работу поверх 100 машин?

G>Тогда любой ORM с Linq на C# снимает вообще все проблемы разработки на SQL БД.


Эм, похоже меня так до сих пор и не поняли. Я нигде и не говорил что у разработки на sql были проблемы. Они на оборот были у nosql. И только в последнее время практически снялись.

А вот в использование у нас как раз изначально противоположная картинка...

G>У яндекса вроде как MySQL. Mail.ru пользуется MS SQL, хотя хз для чего. У гугла свой движок, непонятно что там внутри. Гугл кстати хорошо умеет терять данные, за нескоолько лет прецеденты уже возникали. Facebook — MySQL, Твиттер — MySQL (сейчас только как бекап хранилище), Stackoverflow — MS SQL.


Яндекс на mysql? ))) Это серьёзно, про поиск? )))
И про гугл всё известно. Т.е. даже если исходников нет, то реализация всё равно известна. И кстати всякие Cassandra и HBase — идеологические похожее, только открытое. Да, и за одно если посмотреть кто их создавал и кто использует, то...

G>Там есть хорошая задача и её решение
Автор: gandjustas
Дата: 25.01.12
. Сделай его на nosql, покажи результаты.


Ну во-первых я не вижу задачки, а вижу только решение уже, в стиле sql. А ведь если использовать nosql базы, то частенько более эффективное решение может выглядеть совсем по другому (не в табличном виде).
А во-вторых зачем мне это? )
Re[14]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 10:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ок, понятно. Не всё, правда, но понятно. Я просто в 2001 году занимался проектом, где юзеров было под 1 миллион. Бегало всё на старом и тупом Interbase 5.6 с тогдашним железом. Поэтому рассказы о том, что одиночный сервер в 2012 году внезапно перестаёт справляться при "росте до 4х миллионов подписчиков" я принимаю скептически.


Да, согласен. Вообще "количество регистраций" — сомнительная оценка. Гораздо важнее это "количество запросов к бд/сек". А то многие современные движки (типа cms) такого ужаса на базы данных наводят...

S>Не, ну если выбирать между MySQL и чем-то ещё, то практически всё что угодно будет лучше. Тут я спорить не собираюсь.

S>А у настоящих RDBMS всё гораздо лучше, чем там пишут.

Хгм, я лично не сравнивал, так что не отвечаю за эти слова. Но где-то слышал что mysql по скорости (особенно чтения) частенько обходит всякие oracle и т.п.

S>Ну, то есть мы имеем SQL, построенный по бесструктурным данным. Это не будет работать — нет преимуществ ни k-v баз, ни реляционных баз. Воспользоваться шардингом по ключу не удастся, т.к. нет гарантии, что запрос идёт по ключу. Воспользоваться индексами не удастся, т.к. нет структуры. В общем, имхо — это мертворождённая штука.


Собственно я не говорю что мне это нравится — так, интересно почитать в контексте обсуждения dsl. Сам я предпочитаю совсем другие решения. Но кстати я бы не стал так резко заявлять без детального рассмотрения. Там автор языка, тот же что и автор sqlite и при этом язык вроде уже работает в CouchDB (вполне реальная субд). Так что думаю там всё же продуманы такие проблемы. Вот http://www.unqlspec.org/display/UnQL/Syntax+Summary в формальном описание видны индексы, коммиты и т.п. Сам детали не смотрел. )
Re[15]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 11:00
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>Прочитал, ответа не увидел. Давай по продяку, назови что умеет NoSQL (любая база на выбор) и не умеет MS SQL например.


_>Ну например как перейти с MS SQL на работу поверх 100 машин?


А зачем? Сами 100 машин не нужны, нужны конкретные характеристики. Вот и приведи их.

http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=110083001
Для примера = 1,8 миллионов транзакций в минуту на одном серваке. Причем не то чтобы крутой сервер, я вживую и покруче видал.
и это все полный acid. А для NoSQL сколько нужно чтобы миллион транзакций в минуту выдержать? Бери любую базу.

http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=110120201
А тут вообще 30млн. в минуту, но там кластер из хз сколько машин, минимум 3 походу.

_>Эм, похоже меня так до сих пор и не поняли. Я нигде и не говорил что у разработки на sql были проблемы. Они на оборот были у nosql. И только в последнее время практически снялись.

За счет чего? я слежу за mongo последние 2 года. Там да, появилась нормальная отказоустойчивость. Но для программиста ничего не изменилось. Все те же проблемы с согласованностью данных из-за асинхронной репликации.

_>А вот в использование у нас как раз изначально противоположная картинка...

Это ты о чем?

G>>У яндекса вроде как MySQL. Mail.ru пользуется MS SQL, хотя хз для чего. У гугла свой движок, непонятно что там внутри. Гугл кстати хорошо умеет терять данные, за нескоолько лет прецеденты уже возникали. Facebook — MySQL, Твиттер — MySQL (сейчас только как бекап хранилище), Stackoverflow — MS SQL.


_>Яндекс на mysql? ))) Это серьёзно, про поиск? )))

Для поиска свой индекс всегда используется. Есть опимизированные структуры данных для полнотекстовых индексов. И у них профиль использования не такой как у бд.
Но яндекс это далеко не только поиск.

_>И про гугл всё известно. Т.е. даже если исходников нет, то реализация всё равно известна. И кстати всякие Cassandra и HBase — идеологические похожее, только открытое. Да, и за одно если посмотреть кто их создавал и кто использует, то...

Идеология — ничто. Важна реализация. Особенно вопросов хранения и отказоустойчивости. В SQL это все давно изучено и подкреплено сильной теорией, поэтому работает устойчиво и очень похоже во всех БД. В NoSQL разброд и шатание. Для некоторых NoSQL БД даже если сервер ответил что данные записаны это еще не факт что они на самом деле записаны. Это конечно капец полнейший, любой сбой — типа сеть отвалилась, зависла машина, питание вырубили и судьба данных остается неизвестной. Дай бог еще не посыпется все.

G>>Там есть хорошая задача и её решение
Автор: gandjustas
Дата: 25.01.12
. Сделай его на nosql, покажи результаты.


_>Ну во-первых я не вижу задачки, а вижу только решение уже, в стиле sql. А ведь если использовать nosql базы, то частенько более эффективное решение может выглядеть совсем по другому (не в табличном виде).


Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.
Полнотекстовый поиск не использовать.

_>А во-вторых зачем мне это? )

Это часть исходной задачи про stackoverflow. Некоторые утвреждали что SQL сосет на таких задачах. MS SQL отлично сработал, теперь интересно посмотреть на результаты хоть для одной NoSQL бд.

Кстати одни результат есть
Автор: rm822
Дата: 31.01.12
, но там субд далеко не промышленного качества.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[18]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.04.12 11:20
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

G>С чего там ошибка? В каком месте?


Я ж написал "SQLState 40001". Дедлок или что там. С чего он вылетает и в каком месте? Вот я и спрашиваю, как платформа себя с ним ведёт.

G>В NoSQL, например mongodb — writelock на сервер. При большой нагрузке и чтении\записи хотябы 10 к 1 mongo ляжет.


А ты про это. А мне плевать Мне монго ни к чему. Я уже написал, что всё это слишком immature, что бы в реальности этим пользоваться. Но концепция мне нравится.


G>Да хоть 10 memcached, в memcached хранятся данные, которые отдаются клиенту, записи сразу проваливаются в БД со сбросом кеша. Следующее чтение обновляет кеш. Возможно обновление кеша сразу после записи, чтобы не ждать пока кто-нить обратится.

G>Такая схема дает и скорость, и acid, и является практически стандартом для нагруженных веб-приложений.

Ну вот. Прекрасный пример. Скорость даёт, acid херит , но является практически стандартом для нагруженных веб-приложений.

G>Внимание вопрос, где тут NoSQL или что оно тут может улучшить?


G>Ну правильно. Оптимизаторы БД становлятся все круче, сами оптимизируют планы, сами предлагают индексы и другие оптимизации. настройка HA и DR делается парой кликов мышки.


Ты маркетолог? А то если спустится на землю (заглянуть в соседний форум), то вдруг найдутся менее радостные картины
Автор: MasterZiv
Дата: 19.04.12
.

G>Над этим всем понастроены мощные фреймворки и платформы, позволяющие работать в терминах предметной области, а не таблиц и связей.


Этот вопрос в начале топика поднимался. Ничего хорошего из того, что ты перечислил не нашлось.

G>>>Ты предлагаешь сразу все гарантии отбросить чтобы разработчикам проще было? Это говнософт получается.

ANS>>Нет. Я предлагаю явно определить каких гарантий нет, какие есть, чего это стоит.
G>Так acid более чем явно гарантии дает. Если не считать багов реализации.
G>Вот только не всегда программист способен своим кодом гарантии не нарушать.
G>даже есл ты от части гарантий окажешься, то это не поможет программисту не нарушать остальные.

если всё это это вынести в отдельный сервер, программист туда только запросы посылал, а не писал сам эту логику,
то ошибится программист не сможет. Останутся только баги реализации, которые ты приемлишь.


G>Твое определение неконструктивно, не позволяет разделить системы на SQL и NoSQL.


А мне кажется, что оно вполне фальсифицируемо, а значит конструктивно. Я даже скажу, что оно в тысчу раз конструктивнее любых определений DSL в этом топике.

G>Тем не менее гарантии не могут быть сильнее, чем гарантии хранилища и перформанс в среднем — тоже.


Оно, как бы могут, но, это мы проходили
Автор: Andrei N.Sobchuck
Дата: 03.12.10
, — в данном случае главный плюс не в усилении гарантий, а в управляемом ослаблении оных.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[19]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 12:14
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


G>>С чего там ошибка? В каком месте?


ANS>Я ж написал "SQLState 40001". Дедлок или что там. С чего он вылетает и в каком месте? Вот я и спрашиваю, как платформа себя с ним ведёт.

Как напишешь — так и ведет. Вот ты выдел как на rsdn это обрабатывается. Страшно? Ни разу.

G>>В NoSQL, например mongodb — writelock на сервер. При большой нагрузке и чтении\записи хотябы 10 к 1 mongo ляжет.

ANS>А ты про это. А мне плевать Мне монго ни к чему. Я уже написал, что всё это слишком immature, что бы в реальности этим пользоваться. Но концепция мне нравится.
То есть ты признаешь что NoSQL сейчас — то чем нельзя пользоваться. А можно реально пользоваться только тем что поверх SQL работает?
Так это было и 10 лет назад, и будет также еще через 10.
Я тогда вообще термина NoSQL понять не могу. Ведь даже уровни изоляции в БД тоже NoSQL, они торгуют гарантиями в обмен на производительность. Если приложение само гарантирует отсуствие проблем из-за неповторяемого чтения, то незачем требовать его от базы.




G>>Да хоть 10 memcached, в memcached хранятся данные, которые отдаются клиенту, записи сразу проваливаются в БД со сбросом кеша. Следующее чтение обновляет кеш. Возможно обновление кеша сразу после записи, чтобы не ждать пока кто-нить обратится.

G>>Такая схема дает и скорость, и acid, и является практически стандартом для нагруженных веб-приложений.

ANS>Ну вот. Прекрасный пример. Скорость даёт, acid херит , но является практически стандартом для нагруженных веб-приложений.


Скорость не из-за acid падает, а из-за join и агрегаций. Оптимизация join — до сих пор сложная задача для БД, которая часто выливается в считывание большого объема данных и много операций. Поэтому результаты джоинов лучше кешировать.

G>>Внимание вопрос, где тут NoSQL или что оно тут может улучшить?

G>>Ну правильно. Оптимизаторы БД становлятся все круче, сами оптимизируют планы, сами предлагают индексы и другие оптимизации. настройка HA и DR делается парой кликов мышки.
ANS>Ты маркетолог? А то если спустится на землю (заглянуть в соседний форум), то вдруг найдутся менее радостные картины
Автор: MasterZiv
Дата: 19.04.12
.

В чем они менее радостные? У чувака база внезапно стала работать быстрее чем он ожидал. Он только не понял почему.
Я в технологиях сторонник подхода — "не чини пока не сломано".

G>>Над этим всем понастроены мощные фреймворки и платформы, позволяющие работать в терминах предметной области, а не таблиц и связей.

ANS>Этот вопрос в начале топика поднимался. Ничего хорошего из того, что ты перечислил не нашлось.
Да ну? я вот CRM пользуюсь иногда, там вполне успешно все мапится на БД.
Также пользуюсь иногда orchardcms, там тоже с работой в предметной области все хорошо.

G>>>>Ты предлагаешь сразу все гарантии отбросить чтобы разработчикам проще было? Это говнософт получается.

ANS>>>Нет. Я предлагаю явно определить каких гарантий нет, какие есть, чего это стоит.
G>>Так acid более чем явно гарантии дает. Если не считать багов реализации.
G>>Вот только не всегда программист способен своим кодом гарантии не нарушать.
G>>даже есл ты от части гарантий окажешься, то это не поможет программисту не нарушать остальные.

ANS>если всё это это вынести в отдельный сервер, программист туда только запросы посылал, а не писал сам эту логику,

ANS>то ошибится программист не сможет. Останутся только баги реализации, которые ты приемлишь.
Ограничения в запросах приведут к тому что сервер перестанет эффективно отвечать. Сейчас NoSQL показывают такую картину: для них единственный эффективный метод работы — выборка по ключу. ни запись, ни предикаты, и уж точно никаких соединений и агрегаций, а только по ключу. Есть конечно map\reduce индексы, но они считаются асинхронно. Поэтому толку мало если данные меняются часто.

Я полез в древний код сайта и выяснил что по ключу выбирается не более 30%. Конечно усложнив приложние я могу добиться того чтобы по ключу вытягивалось 80%.
То есть чтобы пользоваться более простым инструментом, позволяя программисту меньше ошибаться надо усложнять приложение?
Я уж лучше в обучение программистов вложусь.


G>>Твое определение неконструктивно, не позволяет разделить системы на SQL и NoSQL.

ANS>А мне кажется, что оно вполне фальсифицируемо, а значит конструктивно. Я даже скажу, что оно в тысчу раз конструктивнее любых определений DSL в этом топике.
Ни разу не конструктивно, потому что ты в обычной SQL базе можешь от части свойств отказываться. Причем можешь рулить этим в такой гранулярности как тебе удобно. NoSQL предлагает раз и навсегда отказаться. Получается NoSQL — подмножество SQL.
А хочется получит определение которое даст непустую симметрическую разность.

G>>Тем не менее гарантии не могут быть сильнее, чем гарантии хранилища и перформанс в среднем — тоже.


ANS>Оно, как бы могут, но, это мы проходили
Автор: Andrei N.Sobchuck
Дата: 03.12.10
, — в данном случае главный плюс не в усилении гарантий, а в управляемом ослаблении оных.

Ссылаться на свои же невернуе утверждения — верх демагогии.
В чем плюс таки заключается? Ослабление гарантий дает недостатки, это очевидно. Какие преимущества оно дает?
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[20]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.04.12 12:44
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

G>Как напишешь — так и ведет. Вот ты выдел как на rsdn это обрабатывается. Страшно? Ни разу.


Я не так часто тут зависаю — не видел. Но похоже, что страшно.
Вот люди париться над такой ерундой и не хотят.

ANS>>А ты про это. А мне плевать Мне монго ни к чему. Я уже написал, что всё это слишком immature, что бы в реальности этим пользоваться. Но концепция мне нравится.

G>То есть ты признаешь что NoSQL сейчас — то чем нельзя пользоваться.

Х.з. Люди как-то пользуются. Но, как я понимаю, это таки для сильных духом.

G>А можно реально пользоваться только тем что поверх SQL работает?


Ох-ох. Так Flockdb это SQL или нет.

G>Ведь даже уровни изоляции в БД тоже NoSQL, они торгуют гарантиями в обмен на производительность. Если приложение само гарантирует отсуствие проблем из-за неповторяемого чтения, то незачем требовать его от базы.


И это кстати тоже минус ACID. Ибо по факту не приложение само гарантирует, а разработчик. А разработчик думает "у меня же ACID, значит мне думать ничего не нужно".


G>>>Такая схема дает и скорость, и acid, и является практически стандартом для нагруженных веб-приложений.

ANS>>Ну вот. Прекрасный пример. Скорость даёт, acid херит , но является практически стандартом для нагруженных веб-приложений.
G>Скорость не из-за acid падает, а из-за join и агрегаций. Оптимизация join — до сих пор сложная задача для БД, которая часто выливается в считывание большого объема данных и много операций. Поэтому результаты джоинов лучше кешировать.

Не-не-не. Везде рекламируется один и тот же патерн работы. А именно три шага: 1) читаем из memcached 2) если там нету, то читаем из БД 3) ложим в memcached. Эти 3 шага неатомарны, и вполне м.произойти так, что в кеш ляжет вычитанное значение, а оно уже изменено в БД. То, что это не происходит по сто раз в минуту — это не гарантия. Только всем плевать. И тебе в том числе. Хотя я помню, что ты тверждал, что ACID не гарантирует того, что ты прочитаешь те же данные, как и записал. Так что для тебя каша в данных наверное норма.

G>>>Ну правильно. Оптимизаторы БД становлятся все круче, сами оптимизируют планы, сами предлагают индексы и другие оптимизации. настройка HA и DR делается парой кликов мышки.

ANS>>Ты маркетолог? А то если спустится на землю (заглянуть в соседний форум), то вдруг найдутся менее радостные картины
Автор: MasterZiv
Дата: 19.04.12
.

G>В чем они менее радостные? У чувака база внезапно стала работать быстрее чем он ожидал. Он только не понял почему.

А, так всё хорошо? Ну раз мне одному кажется, что это плохо, то пусть так и будет.

G>Я в технологиях сторонник подхода — "не чини пока не сломано".



G>>>Тем не менее гарантии не могут быть сильнее, чем гарантии хранилища и перформанс в среднем — тоже.

ANS>>Оно, как бы могут, но, это мы проходили
Автор: Andrei N.Sobchuck
Дата: 03.12.10
, — в данном случае главный плюс не в усилении гарантий, а в управляемом ослаблении оных.

G>Ссылаться на свои же невернуе утверждения — верх демагогии.
G>В чем плюс таки заключается? Ослабление гарантий дает недостатки, это очевидно. Какие преимущества оно дает?

Я сослался не только на своё утверждение, а и на всё последующее обсуждение. Там было и про преимущества. Повторно обсасывать смысла же нет?

Еще я хочу заметить, что всё это напоминает логические обоснования, почему JavaScript в браузере умрёт из-за SIlverlight или еще чего. Только в конце концов Silverlight врезал дуба, а JS полез на сервера.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 13:23
Оценка: +1 -1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


G>>Как напишешь — так и ведет. Вот ты выдел как на rsdn это обрабатывается. Страшно? Ни разу.


ANS>Я не так часто тут зависаю — не видел. Но похоже, что страшно.

ANS>Вот люди париться над такой ерундой и не хотят.
Ну да, обновить страницу страшнее не куда. А потерять данные — ниче.
Вот представь, ты полчаса пишешь на форуме сообщение, жмешь отправить, он говорит все ОК, но сообщение не появляется.
На РСДН я такого не видел, а на всяких NoSQL базах такое бывает относительно часто, сам пару раз натыкался.
Причина совершенно непонятна, толи индекс просто не обносился, толи запись внутри по какому-то тайм-ауту отвалилась.


G>>А можно реально пользоваться только тем что поверх SQL работает?

ANS>Ох-ох. Так Flockdb это SQL или нет.
Нафига мне исходники смотреть. Приведи описание того что умеет, посмотрим.

G>>Ведь даже уровни изоляции в БД тоже NoSQL, они торгуют гарантиями в обмен на производительность. Если приложение само гарантирует отсуствие проблем из-за неповторяемого чтения, то незачем требовать его от базы.

ANS>И это кстати тоже минус ACID. Ибо по факту не приложение само гарантирует, а разработчик. А разработчик думает "у меня же ACID, значит мне думать ничего не нужно".
Это крайне глупый разработчик, он не будет думать даже если у него acid не будет.
Таких надо учить, а не пытаться защитить от сурового мира.

G>>>>Такая схема дает и скорость, и acid, и является практически стандартом для нагруженных веб-приложений.

ANS>>>Ну вот. Прекрасный пример. Скорость даёт, acid херит , но является практически стандартом для нагруженных веб-приложений.
G>>Скорость не из-за acid падает, а из-за join и агрегаций. Оптимизация join — до сих пор сложная задача для БД, которая часто выливается в считывание большого объема данных и много операций. Поэтому результаты джоинов лучше кешировать.

ANS>Не-не-не. Везде рекламируется один и тот же патерн работы. А именно три шага: 1) читаем из memcached 2) если там нету, то читаем из БД 3) ложим в memcached. Эти 3 шага неатомарны, и вполне м.произойти так, что в кеш ляжет вычитанное значение, а оно уже изменено в БД. То, что это не происходит по сто раз в минуту — это не гарантия. Только всем плевать. И тебе в том числе.


Убери memcached, ситуация изменится? Ни разу. Это общий вопрос распределенных систем — как только ты получил данные из внешней системы, они перестали быть актуальные.


ANS>Хотя я помню, что ты тверждал, что ACID не гарантирует того, что ты прочитаешь те же данные, как и записал. Так что для тебя каша в данных наверное норма.

В одной транзакции — гарантирует. Межу транзакциями может произойти что угодно, надеюсь это все понимают. Если мне нужно прочитать ровно тоже что я записал, я просто транзакцию не закрою. И пока открыта транзакция гарантия есть.
NoSQL же зачастую говорит что нет возможности гарантировать что ты прочитаешь то что записал. Какие бы ужимки ты не принимал.
Вот собственно и разница. А из этой разницы следует очень много. Например любые данные любого учета (бухгалтерия, банк, склад) нельзя складывать в NoSQL системы, нет гарантии что они там вообще окажутся. Даже в банальном форуме я не могу выполнить асинхронную отправку и на клиенте показать результат, потому что нету у меня гарантии что он вообще добавился.
Если до следующего рефреша его кто-то обновил, то ниче страшного не случится.

ANS>Еще я хочу заметить, что всё это напоминает логические обоснования, почему JavaScript в браузере умрёт из-за SIlverlight или еще чего. Только в конце концов Silverlight врезал дуба, а JS полез на сервера.

Ты сильно путаешь. Javascript живее всех живых из-за поддержки браузерами, а не из-за своих качеств. Как язык js — говно полнейшее.
А вот NoSQL — говно полнейшее, которое никем из больших игроков не поддержвается. Кроме того обычные SQL БД умеют не меньше любой NoSQL базы.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[22]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.04.12 14:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну да, обновить страницу страшнее не куда. А потерять данные — ниче.


Ага. Т.е. когда в форумах говорят, что по правильному нужно рестартовать транзакцию
Автор: MasterZiv
Дата: 11.04.12
, то это дурят, rsdn криво написан и никто об этом не знает или rsdn криво написан и об этом все знают, но правильно сделать сложно и проще забить ?

G>>>А можно реально пользоваться только тем что поверх SQL работает?

ANS>>Ох-ох. Так Flockdb это SQL или нет.
G>Нафига мне исходники смотреть. Приведи описание того что умеет, посмотрим.

Крути вниз — там README с описанием. Но, можеш посмотреть на википедии.

G>Таких надо учить, а не пытаться защитить от сурового мира.


результат, тем не менее, предопределён.

G>

G>Убери memcached, ситуация изменится? Ни разу. Это общий вопрос распределенных систем — как только ты получил данные из внешней системы, они перестали быть актуальные.
изменится. пропадёт распределённость. вот так вот и все — пытаются прикрутить кеширование, а прикручивают распределённость и неопределённость. а продолжают со всем этим работать, как буд-то по прежнему есть только одна система.


ANS>>Хотя я помню, что ты тверждал, что ACID не гарантирует того, что ты прочитаешь те же данные, как и записал. Так что для тебя каша в данных наверное норма.

G>В одной транзакции — гарантирует. Межу транзакциями может произойти что угодно, надеюсь это все понимают. Если мне нужно прочитать ровно тоже что я записал, я просто транзакцию не закрою. И пока открыта транзакция гарантия есть.

Не юли
Автор: Andrei N.Sobchuck
Дата: 06.12.10


G>NoSQL же зачастую говорит что нет возможности гарантировать что ты прочитаешь то что записал. Какие бы ужимки ты не принимал.

G>Вот собственно и разница. А из этой разницы следует очень много. Например любые данные любого учета (бухгалтерия, банк, склад) нельзя складывать в NoSQL системы, нет гарантии что они там вообще окажутся. Даже в банальном форуме я не могу выполнить асинхронную отправку и на клиенте показать результат, потому что нету у меня гарантии что он вообще добавился.

Однако по факту, например в Facebook, nosql используют для мыла и месенджера.

G>А вот NoSQL — говно полнейшее, которое никем из больших игроков не поддержвается.

Oracle, MS, IBM.

Еещ пример: Google Tenzing: пускает запросы поверх MapReduce и позволило Google уйти с той СУБД, которая была до (мне почему-то кажется, что была Terradata, но название они в pdf специально не указывают).
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 15:18
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=110083001

G>Для примера = 1,8 миллионов транзакций в минуту на одном серваке. Причем не то чтобы крутой сервер, я вживую и покруче видал.
G>и это все полный acid. А для NoSQL сколько нужно чтобы миллион транзакций в минуту выдержать? Бери любую базу.
G>http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=110120201
G>А тут вообще 30млн. в минуту, но там кластер из хз сколько машин, минимум 3 походу.


Вот спасибо! Прямо идеальное дополнение к моим аргументам. Смотрю на цены по этим ссылкам и ситуация с преимуществом nosql становится просто очевидной. )


G>За счет чего? я слежу за mongo последние 2 года. Там да, появилась нормальная отказоустойчивость. Но для программиста ничего не изменилось. Все те же проблемы с согласованностью данных из-за асинхронной репликации.


Я имел в виду что само появление mongodb и ей подобных и является этим изменением.

G>Для поиска свой индекс всегда используется. Есть опимизированные структуры данных для полнотекстовых индексов. И у них профиль использования не такой как у бд.

G>Но яндекс это далеко не только поиск.

Кстати, вот http://www.insight-it.ru/highload/ интересная ссылка есть на эту тему.

G>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.

G>Полнотекстовый поиск не использовать.

С таким объяснением задачка уже не выглядит времязатратно, так что я решил всё же потратить на неё чуть времени. И так вот такой код:
import random, time, pymongo
articles = pymongo.Connection().mydb.articles

#Заполняем базу
#for i in range(100000): articles.save({'title': "a%d" % i, 'tags': ["t%d" % random.randint(1, 100) for t in range(10)]})
#articles.ensure_index('tags')

start=time.time()

ids=lambda x: frozenset([i['_id'] for i in articles.find({'tags': x}, {})])
res=[articles.find_one({'_id': a}) for a in ids("t9")&ids("t69")&ids("t99")]

finish = time.time()

for r in res: print 'Article "%(title)s"' % r
print "Time:", finish - start

на тормознутом Питоне выдаёт на компьютере с процессором C2D 0,302 секунды.

Как мы видим получается что значительно более короткий и простой код работает даже слегка быстрее. И при этом я могу масштабировать это решение на много компьютеров парой движений (причём даже не в исходном коде).

Ещё вопросы есть? )))
Re[23]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 15:37
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


G>>Ну да, обновить страницу страшнее не куда. А потерять данные — ниче.


ANS>Ага. Т.е. когда в форумах говорят, что по правильному нужно рестартовать транзакцию
Автор: MasterZiv
Дата: 11.04.12
, то это дурят, rsdn криво написан и никто об этом не знает или rsdn криво написан и об этом все знают, но правильно сделать сложно и проще забить ?

Я не знаю как rsdn написан. Но при появлении такого сообщения на форуме абсолютно нестрашно сделать f5.

G>>>>А можно реально пользоваться только тем что поверх SQL работает?

ANS>>>Ох-ох. Так Flockdb это SQL или нет.
G>>Нафига мне исходники смотреть. Приведи описание того что умеет, посмотрим.

ANS>Крути вниз — там README с описанием. Но, можеш посмотреть на википедии.

Мда, в википедии один абзац. Ты сам быстрее напишешь про фичи.


G>>

G>>Убери memcached, ситуация изменится? Ни разу. Это общий вопрос распределенных систем — как только ты получил данные из внешней системы, они перестали быть актуальные.
ANS>изменится. пропадёт распределённость. вот так вот и все — пытаются прикрутить кеширование, а прикручивают распределённость и неопределённость. а продолжают со всем этим работать, как
буд-то по прежнему есть только одна система.

С чего это она пропадет? Сервак все равно на другой машине. А клиент на третьей. Ведь кто-то может поменять данные к тот момент пока до клиента идет результат запроса.
Ниче, никто не умер. Просто все видят немного старые данные. Вот только они видят эти данные, взамен этого NoSQL говорят что клиент их может и не увидеть. Это уже плохо.

ANS>>>Хотя я помню, что ты тверждал, что ACID не гарантирует того, что ты прочитаешь те же данные, как и записал. Так что для тебя каша в данных наверное норма.

G>>В одной транзакции — гарантирует. Межу транзакциями может произойти что угодно, надеюсь это все понимают. Если мне нужно прочитать ровно тоже что я записал, я просто транзакцию не закрою. И пока открыта транзакция гарантия есть.

ANS>Не юли
Автор: Andrei N.Sobchuck
Дата: 06.12.10

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

G>>NoSQL же зачастую говорит что нет возможности гарантировать что ты прочитаешь то что записал. Какие бы ужимки ты не принимал.

G>>Вот собственно и разница. А из этой разницы следует очень много. Например любые данные любого учета (бухгалтерия, банк, склад) нельзя складывать в NoSQL системы, нет гарантии что они там вообще окажутся. Даже в банальном форуме я не могу выполнить асинхронную отправку и на клиенте показать результат, потому что нету у меня гарантии что он вообще добавился.

ANS>Однако по факту, например в Facebook, nosql используют для мыла и месенджера.

Ага, вот только данные хранятся в MySQL, а nosql как кеш с полнотекстовым индексом.

G>>А вот NoSQL — говно полнейшее, которое никем из больших игроков не поддержвается.

ANS>Oracle, MS, IBM.
Хадуп ты зря привел, это не OLPT база, у нее задачи совсем другие. По сути для анализа данные из обычных MS SQL\Oracle\MySQL\Postgres будут переливаться в hadoop.
Так что все равно не ушли от SQL как основного инструмента.

ANS>Еещ пример: Google Tenzing: пускает запросы поверх MapReduce и позволило Google уйти с той СУБД, которая была до (мне почему-то кажется, что была Terradata, но название они в pdf специально не указывают).

Тебя не в ту сторону понесло. MapReduce может и поверх обычной РСУБД работать. Также как и Fulltext Search.
Ты пытаешься рассматривать алгоритмы, которые как раз одинаковы будут. А меня интересуют механизмы, которые это все поддерживают.
С этой точки зрения NoSQL сливает.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[17]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 15:44
Оценка:
import time, pymongo
articles = pymongo.Connection().mydb.articles
start=time.time()

ids=lambda t: frozenset([а['_id'] for а in articles.find({'tags': t}, {})])
res=map(articles.find_one, ids("t9")&ids("t69")&ids("t99"))

print "Articles: ", len(res), "Time:", time.time() - start


Так чуть красивее в итоге. ))) Время не изменилось естественно. )))
Re[17]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 16:34
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=110083001

G>>Для примера = 1,8 миллионов транзакций в минуту на одном серваке. Причем не то чтобы крутой сервер, я вживую и покруче видал.
G>>и это все полный acid. А для NoSQL сколько нужно чтобы миллион транзакций в минуту выдержать? Бери любую базу.
G>>http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=110120201
G>>А тут вообще 30млн. в минуту, но там кластер из хз сколько машин, минимум 3 походу.

_>

_>Вот спасибо! Прямо идеальное дополнение к моим аргументам. Смотрю на цены по этим ссылкам и ситуация с преимуществом nosql становится просто очевидной. )

так подними 30 млн. транзакций в минуту на NoSQL, в чем вопрос? Возьми первое место в TPC-C



G>>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.

G>>Полнотекстовый поиск не использовать.

_>С таким объяснением задачка уже не выглядит времязатратно, так что я решил всё же потратить на неё чуть времени. И так вот такой код:

_>
import random, time, pymongo
_>articles = pymongo.Connection().mydb.articles

_>#Заполняем базу
_>#for i in range(100000): articles.save({'title': "a%d" % i, 'tags': ["t%d" % random.randint(1, 100) for t in range(10)]})
_>#articles.ensure_index('tags')

_>start=time.time()

_>ids=lambda x: frozenset([i['_id'] for i in articles.find({'tags': x}, {})])
_>res=[articles.find_one({'_id': a}) for a in ids("t9")&ids("t69")&ids("t99")]

_>finish = time.time()

_>for r in res: print 'Article "%(title)s"' % r
_>print "Time:", finish - start

_>на тормознутом Питоне выдаёт на компьютере с процессором C2D 0,302 секунды.

_>Как мы видим получается что значительно более короткий и простой код работает даже слегка быстрее. И при этом я могу масштабировать это решение на много компьютеров парой движений (причём даже не в исходном коде).

_>Ещё вопросы есть? )))
Есть, индекс я так понимаю после каждой правки надо пересчитывать, это мягко говоря дофига времени займет.

Кстати есть код, который можно в интерпретатор mongo загнать? А то питон не хочется ставить.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[18]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 17:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>так подними 30 млн. транзакций в минуту на NoSQL, в чем вопрос? Возьми первое место в TPC-C


А там вообще результаты от сетей компьютеров (не кластеров) принимают? )

G>Есть, индекс я так понимаю после каждой правки надо пересчитывать, это мягко говоря дофига времени займет.


А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? )

G>Кстати есть код, который можно в интерпретатор mongo загнать? А то питон не хочется ставить.


Я даже не смотрел какой там язык в mongodb shell и не открывал ни разу. Зачем? Всё равно реальный код пишется на каком-то нормальном языке. И скрипты любые намного удобнее на Питоне. А в чём проблема с Питоном? На винде это значит пару msi запустить и всё. ) Могу подсказать какие.)
Re[19]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.12 19:40
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>так подними 30 млн. транзакций в минуту на NoSQL, в чем вопрос? Возьми первое место в TPC-C


_>А там вообще результаты от сетей компьютеров (не кластеров) принимают? )

Я думаю принимают.

G>>Есть, индекс я так понимаю после каждой правки надо пересчитывать, это мягко говоря дофига времени займет.

_>А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? )
Может и так, но это происходит само и гораздо быстрее.

G>>Кстати есть код, который можно в интерпретатор mongo загнать? А то питон не хочется ставить.


_>Я даже не смотрел какой там язык в mongodb shell и не открывал ни разу. Зачем? Всё равно реальный код пишется на каком-то нормальном языке. И скрипты любые намного удобнее на Питоне. А в чём проблема с Питоном? На винде это значит пару msi запустить и всё. ) Могу подсказать какие.)


Я просто обратил внимание что самую интересную операцию, пересечение множеств, ты сделал на питоне.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[20]: SQL vs NOSQL
От: alex_public  
Дата: 19.04.12 21:33
Оценка:
Здравствуйте, gandjustas, Вы писали:

_>>А там вообще результаты от сетей компьютеров (не кластеров) принимают? )

G>Я думаю принимают.

А где там гугл тогда? )

_>>А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? )

G>Может и так, но это происходит само и гораздо быстрее.

Тут тоже всё само. Там в коде именно операция создания индекса (навсегда), а не какого-то обновления.

И откуда интересно данные что "гораздо быстрее"?

G>Я просто обратил внимание что самую интересную операцию, пересечение множеств, ты сделал на питоне.


Ну так это и есть стиль nosql. ))) То самое, что Sinclair критиковал.

Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...
Re[21]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 05:28
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>А там вообще результаты от сетей компьютеров (не кластеров) принимают? )

G>>Я думаю принимают.

_>А где там гугл тогда? )


Я думаю у гугла на 30 млн транзакций в минуту приходится гораздо больше железа. Там ведь не запросы чтения данных считают.

_>>>А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? )

G>>Может и так, но это происходит само и гораздо быстрее.

_>Тут тоже всё само. Там в коде именно операция создания индекса (навсегда), а не какого-то обновления.

_>И откуда интересно данные что "гораздо быстрее"?
В SQL создание индексов заняло около 10 секунд. Сделал drop и create

G>>Я просто обратил внимание что самую интересную операцию, пересечение множеств, ты сделал на питоне.


_>Ну так это и есть стиль nosql. ))) То самое, что Sinclair критиковал.

Это чревато перекачкой большого объема данных из базы в приложение.

_>Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...

Не думаю что разница превысила бы 10%
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[24]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.04.12 09:24
Оценка: -2 :)
Здравствуйте, gandjustas, Вы писали:

Я сдаюсь

но напоследок замечу, что картинка, как в анекдоте получается: там где семья потенциальных миллионеров, а по факту одни проститутки.
так и тут, потенциально миллиарды транзакций на сервере слабее zx-spectrum, идеальное разруливание конкурентного доступа, оптимизаторы умнее человека, полная изоляция, полное durability,
а в реальности, нужно обвесить костылями a-la memcached, запросы хинтами обтыкать, в полях json хранить, для дюрабельности асинхронную master-master репликацию сделать (sic!) и себя еще и убеждать, что там да, страничка иногда не работает, но пользователь F5 потыкает (чай корона не упадёт), там он данные будет старые видёть, но ничё — через 15 мин кеш проэкспайрится и ок. А когда говоришь, что система получилось гуано, отвечают ничего не гуано, у нас acid и математика, а про кашу в данных врёшь ты всё, потому что смотри п.первый про асид, и лучше быть ничего не может потому что смотри п.первый про асид и второй про математику. Сюр.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[25]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 09:53
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


ANS>Я сдаюсь


ANS>но напоследок замечу, что картинка, как в анекдоте получается: там где семья потенциальных миллионеров, а по факту одни проститутки.

ANS>так и тут, потенциально миллиарды транзакций на сервере слабее zx-spectrum, идеальное разруливание конкурентного доступа, оптимизаторы умнее человека, полная изоляция, полное durability,
ANS>а в реальности, нужно обвесить костылями a-la memcached, запросы хинтами обтыкать, в полях json хранить, для дюрабельности асинхронную master-master репликацию сделать (sic!) и себя еще и убеждать, что там да, страничка иногда не работает, но пользователь F5 потыкает (чай корона не упадёт), там он данные будет старые видёть, но ничё — через 15 мин кеш проэкспайрится и ок. А когда говоришь, что система получилось гуано, отвечают ничего не гуано, у нас acid и математика, а про кашу в данных врёшь ты всё, потому что смотри п.первый про асид, и лучше быть ничего не может потому что смотри п.первый про асид и второй про математику. Сюр.

Ты мешаешь много факторов в одну кучу, не понимая как каждый и них в отдельности влияет на полную картину.
1) Для надежности master-master репликация не нужна, она может понадобится для LB и\или локальности.
2) Без memcached отлично работает. Вот stackoverflow долгое время без кешей работал. Только через год они начали кеши использовать.
3) Lazy кеш надо использовать очень осторожно, он людям не нравится. Те кто используют его везде — неправильно делают.
4) Если есть распределенный кеш, то поддерживать его когерентность совсем несложно.

Если программист неспособен осознать то что написано выше, то его нельзя подпускать к работе с данными и hiload.
Пусть дальше лепит говносайты на nosql каком нить и надеется (а что ему еще остается) что все будет нормально.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[21]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 20.04.12 10:29
Оценка:
Здравствуйте, alex_public, Вы писали:

_>А где там гугл тогда? )

А гугл и не подавал никогда.
И я так думаю, что в TPC-C у гугла не больше шансов, чем у прочих. Их технология разработана не совсем для этого случая.

_>Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...


Тогда бы мы получили полную противоположность декларируемым преимуществам NoSQL — высокий порог вхождения и массовые забеги с напильником для получения приемлемого быстродействия, вместо того, чтобы за 20 минут накидать базу на SQL Express, а масштабировать — потом, когда у проекта будут деньги на это.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[16]: SQL vs NOSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.04.12 10:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.

G>Полнотекстовый поиск не использовать.

У нас похожая задача, только база 10 000 000 статей, тегов произвольное количество, всего тегов 100 000, связей тегов со статьями 500 000 000, разные критерии сортировки, которые надо гибко настраивать и менять, которые зависят от введенных тегов, значений в таблице связей, авторов статей, ... При выдаче обязательно необходимо выдавать общее количество статей, которые удовлетворяют условиям поиска. Также сходные результаты не должны следовать один за другим. Поиск не менее секунды, а лучше 0.1. И еще ряд условий... MySQL и Postge не справились в наших руках, ни у кого не хватило квалификации.
Re[17]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 20.04.12 10:33
Оценка:
Здравствуйте, alex_public, Вы писали:


_>

_>Вот спасибо! Прямо идеальное дополнение к моим аргументам. Смотрю на цены по этим ссылкам и ситуация с преимуществом nosql становится просто очевидной. )
Правда что ли?
А вы уверены, что всё честно посчитали на стороне NoSQL? У TPC-C — очень жёсткие критерии подсчёта стоимости. Например, туда входит стоимость клиентских машин. Ваше NoSQL решение, надо полагать, их тоже учитывает? Учитывается ли стоимость поддержки на срок 3 года?
Посмотрите спецификации на TPC-C, попробуйте рассчитать стоимость NoSQL варианта с аналогичной производительностью. Необязательно брать сразу два миллиона TpMc, возьмите что-нибудь маленькое, тысяч на двадцать, и посмотрите в прайс. Там очень подробно расписано — сколько стоит железо, сколько диски, сколько сеть, сколько лицензии — и так далее. Попробуйте найти способ сэкономить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[25]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 20.04.12 10:37
Оценка: 4 (1) +2
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>так и тут, потенциально миллиарды транзакций на сервере слабее zx-spectrum, идеальное разруливание конкурентного доступа, оптимизаторы умнее человека, полная изоляция, полное durability,
ANS>а в реальности, нужно обвесить костылями a-la memcached, запросы хинтами обтыкать, в полях json хранить, для дюрабельности асинхронную master-master репликацию сделать (sic!) и себя еще и убеждать, что там да, страничка иногда не работает, но пользователь F5 потыкает (чай корона не упадёт), там он данные будет старые видёть, но ничё — через 15 мин кеш проэкспайрится и ок. А когда говоришь, что система получилось гуано, отвечают ничего не гуано, у нас acid и математика, а про кашу в данных врёшь ты всё, потому что смотри п.первый про асид, и лучше быть ничего не может потому что смотри п.первый про асид и второй про математику. Сюр.
Коллега, вы бы вместо того, чтобы позориться, почитали отчёты с TPC-С. Там очень подробно написано, какие ухищрения и для чего делаются, и какие результаты получаются. Прикол в том, что результаты там засчитываются только "кинетические", а не "потенциальные". Т.е. недостаточно просто написать туда "я думаю, что можно вот так всё настроить". Нужно реально построить кластер и провести измерения.
Так что насчёт гуанности систем — я, пожалуй, подожду, пока NoSQL сумеет в TPC-C занять хоть какое-то место. Тогда можно будет сравнивать перформанс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[17]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 10:46
Оценка:
Здравствуйте, Mystic, Вы писали:

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


G>>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.

G>>Полнотекстовый поиск не использовать.

M>У нас похожая задача, только база 10 000 000 статей, тегов произвольное количество, всего тегов 100 000, связей тегов со статьями 500 000 000, разные критерии сортировки, которые надо гибко настраивать и менять, которые зависят от введенных тегов, значений в таблице связей, авторов статей, ... При выдаче обязательно необходимо выдавать общее количество статей, которые удовлетворяют условиям поиска. Также сходные результаты не должны следовать один за другим. Поиск не менее секунды, а лучше 0.1. И еще ряд условий... MySQL и Postge не справились в наших руках, ни у кого не хватило квалификации.


Реально такие задачи решаются полнотекстовым поиском.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[18]: SQL vs NOSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.04.12 10:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Реально такие задачи решаются полнотекстовым поиском.


Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.
Re[19]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 12:28
Оценка:
Здравствуйте, Mystic, Вы писали:

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


G>>Реально такие задачи решаются полнотекстовым поиском.


M>Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.


Что ты имеешь ввиду "проще самому пошагово рассказать"?
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[19]: SQL vs NOSQL
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.04.12 12:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


G>>С чего там ошибка? В каком месте?


ANS>Я ж написал "SQLState 40001". Дедлок или что там. С чего он вылетает и в каком месте? Вот я и спрашиваю, как платформа себя с ним ведёт.


в 8 ке блокировки проталкивает на верх которые могут быть например при установлении блокировок на записи или при интенсивных изменениях индекса.
и солнце б утром не вставало, когда бы не было меня
Re[20]: SQL vs NOSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.04.12 13:03
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.


G>Что ты имеешь ввиду "проще самому пошагово рассказать"?


На моем компе дома шахматный движок считает 7 000 000 позиций в секунду на одном ядре. Мне проще написать на C++ алгоритм поиска по SHM, чем мучится настраивая полнотекстовые индексы, полнотекстовый поиск и т. п. чтобы считалось так, как я хочу, и быстро.
Re[26]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.04.12 13:09
Оценка:
Здравствуйте, gandjustas, Вы писали:

эх, не сдержался.

G>Ты мешаешь много факторов в одну кучу, не понимая как каждый и них в отдельности влияет на полную картину.


а что тут не понятного, люди во всю ищут альтернативу.

G>1) Для надежности master-master репликация не нужна, она может понадобится для LB и\или локальности.


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

G>2) Без memcached отлично работает. Вот stackoverflow долгое время без кешей работал. Только через год они начали кеши использовать.


я так и думал, что всё настолько хорошо работает на голом SQL, что SO прикрутил кеши для той же причины, что и колонны в греческих храмах — для красоты

G>3) Lazy кеш надо использовать очень осторожно, он людям не нравится. Те кто используют его везде — неправильно делают.


G>4) Если есть распределенный кеш, то поддерживать его когерентность совсем несложно.


Это один из ключевых моментов. ты считаешь, что это легко и нет проблем, а на самом деле, во многих случаях многие ослабления гарантий растут именно из этого "беспроблемного" места.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[20]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.04.12 13:15
Оценка:
Здравствуйте, Serginio1, Вы писали:


G>>>С чего там ошибка? В каком месте?

ANS>>Я ж написал "SQLState 40001". Дедлок или что там. С чего он вылетает и в каком месте? Вот я и спрашиваю, как платформа себя с ним ведёт.
S>в 8 ке блокировки проталкивает на верх которые могут быть например при установлении блокировок на записи или при интенсивных изменениях индекса.

"на верх" это в прикладной уровень и разруливать там вручную нужно? и какая общая практика, чтобы у бухов крышу не сносило? "забить" или что-то более интеллектуальное?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: SQL vs NOSQL
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.04.12 13:34
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:



ANS>"на верх" это в прикладной уровень и разруливать там вручную нужно? и какая общая практика, чтобы у бухов крышу не сносило? "забить" или что-то более интеллектуальное?


Вот такого плана


Ошибка при вызове метода контекста (Заблокировать): Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки из-за ожидания сессии 16972

Народ понимает плохо
и солнце б утром не вставало, когда бы не было меня
Re[21]: SQL vs NOSQL
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.04.12 13:35
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

Или такого плана


Ошибка выполнения запроса: Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Превышено время ожидания запроса на блокировку.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=33, Severity=10, native=1222, line=1

и солнце б утром не вставало, когда бы не было меня
Re[22]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.04.12 13:44
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S> Народ понимает плохо


Т.е. "забить". я об этом и говорил, что пишут, что "проблем нет, рестартонул и всё", а по факту пользователь сидит и репу чешет.

А мне потом еще рассказывают, что они мол о пользователях заботятся, а я их гноблю.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[23]: SQL vs NOSQL
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.04.12 13:53
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


S>> Народ понимает плохо


ANS>Т.е. "забить". я об этом и говорил, что пишут, что "проблем нет, рестартонул и всё", а по факту пользователь сидит и репу чешет.


ANS>А мне потом еще рассказывают, что они мол о пользователях заботятся, а я их гноблю.

Вообще при таких ошибках можно былобы предусмотреть перезапуск транзакции. Либо приходится самому делать цикл, обрабатывая текст ошибки.
и солнце б утром не вставало, когда бы не было меня
Re[27]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 13:56
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


ANS>эх, не сдержался.


G>>Ты мешаешь много факторов в одну кучу, не понимая как каждый и них в отдельности влияет на полную картину.

ANS>а что тут не понятного, люди во всю ищут альтернативу.
Ага, те кто не понимают как работает SQL ищут, а те кто понимают — понимают проблемы, которые несут эти альтернативы.



G>>1) Для надежности master-master репликация не нужна, она может понадобится для LB и\или локальности.

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

G>>2) Без memcached отлично работает. Вот stackoverflow долгое время без кешей работал. Только через год они начали кеши использовать.

ANS>я так и думал, что всё настолько хорошо работает на голом SQL, что SO прикрутил кеши для той же причины, что и колонны в греческих храмах — для красоты
Прирутили кеши, потому что join_ы медленно работают.

G>>3) Lazy кеш надо использовать очень осторожно, он людям не нравится. Те кто используют его везде — неправильно делают.

G>>4) Если есть распределенный кеш, то поддерживать его когерентность совсем несложно.
ANS>Это один из ключевых моментов. ты считаешь, что это легко и нет проблем, а на самом деле, во многих случаях многие ослабления гарантий растут именно из этого "беспроблемного" места.

Я тебе уже писал как это разруливается. Запись идет сразу в базу, кеш сбрасывается и обновляется при первом обращении или прямо после записи.
В случае распределенного кеша ничего не нарушается.
Обращение к кешу идет только когда надо вывести данные. На основе данных из кеша логика, изменяющая данные не работат.

Где тут ослабление гарантий?
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[21]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 13:58
Оценка:
Здравствуйте, Mystic, Вы писали:

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


M>>>Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.


G>>Что ты имеешь ввиду "проще самому пошагово рассказать"?


M>На моем компе дома шахматный движок считает 7 000 000 позиций в секунду на одном ядре. Мне проще написать на C++ алгоритм поиска по SHM, чем мучится настраивая полнотекстовые индексы, полнотекстовый поиск и т. п. чтобы считалось так, как я хочу, и быстро.


Причем тут твои шахматы? Мы про поиск статей по тегам\авторам\другим_атрибутам говорили. Что значит "проще самому пошагово рассказать"
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[22]: SQL vs NOSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.04.12 14:05
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Причем тут твои шахматы? Мы про поиск статей по тегам\авторам\другим_атрибутам говорили. Что значит "проще самому пошагово рассказать"


При том, что даже тупой перебор миллиона вариантов (записей) не должен быть проблемой для современных компов. Но, часто, это проблема для SQL
Re[28]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.04.12 14:14
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>Я тебе уже писал как это разруливается. Запись идет сразу в базу, кеш сбрасывается и обновляется при первом обращении или прямо после записи.

G>В случае распределенного кеша ничего не нарушается.

Оно и в случае локального кеша нарушается, а при распределённом тем более. Я тебе указывал на ошибку (ссылку не даю, потому что тебя это беспокоит) — ты рассматриваешь последовательности "запись — сброс" и "вычитка — обновление", как атомарные и строго упорядоченные. По факту они не только не атомарные, но и могут "переупорядочиваться".

G>Обращение к кешу идет только когда надо вывести данные. На основе данных из кеша логика, изменяющая данные не работат.


Достаточно того, что пользователь левые данные 15 минут видит.

G>Где тут ослабление гарантий?


предыдущая беседа на эту тему началась с того, что никому распределённые системы не нужны, а значит CAP-теорема не актуальна.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[23]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 14:21
Оценка:
Здравствуйте, Mystic, Вы писали:

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


G>>Причем тут твои шахматы? Мы про поиск статей по тегам\авторам\другим_атрибутам говорили. Что значит "проще самому пошагово рассказать"


M>При том, что даже тупой перебор миллиона вариантов (записей) не должен быть проблемой для современных компов. Но, часто, это проблема для SQL


Перебор не проблема. Считывание с диска — проблема. Именно это и оптимизируют базы.
Ведь 1,000,000 статей, каждая хотябы по 1 кб размером — гиг данных. База умудряется искать статьи по автору за доли секунды. Напиши перебор, который так же быстро сработает.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[29]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 14:36
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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



G>>Я тебе уже писал как это разруливается. Запись идет сразу в базу, кеш сбрасывается и обновляется при первом обращении или прямо после записи.

G>>В случае распределенного кеша ничего не нарушается.

ANS>Оно и в случае локального кеша нарушается, а при распределённом тем более. Я тебе указывал на ошибку (ссылку не даю, потому что тебя это беспокоит) — ты рассматриваешь последовательности "запись — сброс" и "вычитка — обновление", как атомарные и строго упорядоченные. По факту они не только не атомарные, но и могут "переупорядочиваться".


И что? Оно на логику не повлияет. Кеш это только оптимизация, за счет того что пользователь может увидеть слегка старые результаты, но так как результаты запроса сразу устаревают после считывания из базы, то клиент ниче не теряет.
А если нужны гарантии, то кеш идет лесом и используются транзакции.
До сих пор не понял? В SQL такое всегда можно сделать. А вот в NoSQL системах внутри всякие кеши используются, асинхронные обновления индексов и другие ненадежные вещи, которые слабо контролируются снаружи.

G>>Обращение к кешу идет только когда надо вывести данные. На основе данных из кеша логика, изменяющая данные не работат.

ANS>Достаточно того, что пользователь левые данные 15 минут видит.
15 минут? Этож как такой брен написать надо.
Ты вот на форуме видишь старые данные? А кеши скорее всего используются.

G>>Где тут ослабление гарантий?

ANS>предыдущая беседа на эту тему началась с того, что никому распределённые системы не нужны, а значит CAP-теорема не актуальна.
CAP ни о чем, оно рассматривает внешнюю систему как черный ящик. Если отказаться от идеи "черного ящика", то все гораздо проще.
Ты ведь тоже самое говоришь про NoSQL.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[22]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 14:43
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Я думаю у гугла на 30 млн транзакций в минуту приходится гораздо больше железа. Там ведь не запросы чтения данных считают.


Да, безусловно железа больше. И что?

G>В SQL создание индексов заняло около 10 секунд. Сделал drop и create


Протестировал. Получилось 4,9 секунды создание индекса.

_>>Ну так это и есть стиль nosql. ))) То самое, что Sinclair критиковал.

G>Это чревато перекачкой большого объема данных из базы в приложение.

Согласен. Тут уже всё зависит от квалификации разработчика...

_>>Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...

G>Не думаю что разница превысила бы 10%

Не факт. Я же не про алгоритмы говорю и даже не про то что у C++ лучший оптимизирующий компилятор. Я про представление данных... Скажем представление id в виде строки, в виде 12 байтного числа и в виде указателя на объект будут очень сильно различаться на операции сравнения, которая в данном случае чаще всего и вызывается. Так что не исключено очень существенное увеличение быстродействия, но это надо конкретно детали смотреть уже — естественно я это не буду делать.

Но собственно говоря это всё и не нужно, т.к. и на медленном Питоне оно быстрее sql варианта — куда там ещё оптимизироваться то...
Re[23]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 14:46
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


S>> Народ понимает плохо


ANS>Т.е. "забить". я об этом и говорил, что пишут, что "проблем нет, рестартонул и всё", а по факту пользователь сидит и репу чешет.


Отлови ошибку по коду, и покажи пользователю сообщение "повторите еще раз". А если внутри кода можешь ошибку разрулить, то сам повтори вызов.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[22]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 14:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А гугл и не подавал никогда.

S>И я так думаю, что в TPC-C у гугла не больше шансов, чем у прочих. Их технология разработана не совсем для этого случая.

Ну я может не особо разобрался что там за рейтингм, так посмотрел только цифры по ссылкам. Но в любом случае мне кажется что как раз технология гугла перспективнее в любых применениях. Так что может рейтинг отражает уже не актуальные параметры? )

S>Тогда бы мы получили полную противоположность декларируемым преимуществам NoSQL — высокий порог вхождения и массовые забеги с напильником для получения приемлемого быстродействия, вместо того, чтобы за 20 минут накидать базу на SQL Express, а масштабировать — потом, когда у проекта будут деньги на это.


Ох,у меня такое впечателение что я постоянно говорю одно, а все вокруг слышат другое. Я же вроде несколько раз в этой теме говорил что как раз у nosql всегда был высокий порог вхождения. В отличие от sql, где мы придумали запросец и всё — дальше "база там как-то сама оптимально всё выполнит". А только в последние годы порог nosql стал снижаться до уровня удобной и простой работы. И соответственно сразу туда повалил народ.

Ну и кстати по моему примеру вроде как видно насколько продвинулись в этом. Он просто несравнимо короче и проще диких и страшных запросов с кучей join. Про xml схему базы я вообще молчу.
Re[23]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.12 15:03
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>Я думаю у гугла на 30 млн транзакций в минуту приходится гораздо больше железа. Там ведь не запросы чтения данных считают.


_>Да, безусловно железа больше. И что?


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

G>>В SQL создание индексов заняло около 10 секунд. Сделал drop и create

_>Протестировал. Получилось 4,9 секунды создание индекса.
У меня 60 секунд создавался на 100,000 статей по 10 тегов в каждой.

_>>>Ну так это и есть стиль nosql. ))) То самое, что Sinclair критиковал.

G>>Это чревато перекачкой большого объема данных из базы в приложение.

_>Согласен. Тут уже всё зависит от квалификации разработчика...

Квалификация не при чем. Два предиката могут давать очень большие множества, но пересечение их будет пусто. СУБД используют статистику по индексам чтобы в первую очередь получать записи по тем предикатам, которые возвращают меньше всего.

_>>>Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...

G>>Не думаю что разница превысила бы 10%

_>Не факт. Я же не про алгоритмы говорю и даже не про то что у C++ лучший оптимизирующий компилятор. Я про представление данных... Скажем представление id в виде строки, в виде 12 байтного числа и в виде указателя на объект будут очень сильно различаться на операции сравнения, которая в данном случае чаще всего и вызывается. Так что не исключено очень существенное увеличение быстродействия, но это надо конкретно детали смотреть уже — естественно я это не буду делать.

Основные затраты в этом случае — на перекачку данных от диска до клиента.

_>Но собственно говоря это всё и не нужно, т.к. и на медленном Питоне оно быстрее sql варианта — куда там ещё оптимизироваться то...

Я питон так и не поставил, поэтому сравнить не могу.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[18]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 15:04
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А вы уверены, что всё честно посчитали на стороне NoSQL? У TPC-C — очень жёсткие критерии подсчёта стоимости. Например, туда входит стоимость клиентских машин. Ваше NoSQL решение, надо полагать, их тоже учитывает? Учитывается ли стоимость поддержки на срок 3 года?

S>Посмотрите спецификации на TPC-C, попробуйте рассчитать стоимость NoSQL варианта с аналогичной производительностью. Необязательно брать сразу два миллиона TpMc, возьмите что-нибудь маленькое, тысяч на двадцать, и посмотрите в прайс. Там очень подробно расписано — сколько стоит железо, сколько диски, сколько сеть, сколько лицензии — и так далее. Попробуйте найти способ сэкономить.

Что-то у вас какие-то странные представления о бизнесе, как будто бы там деньги девать некуда. Если у меня вдруг проект упрётся в базу данных (такого ещё не было кстати, но это просто потому что у нас другой профиль деятельности), то я просто арендую в том же датацентре ещё пару соседних серверов и раскидаю базу по ним. А тех денег с вашего "маленького решения" хватит лет на 10 аренды. Про первые две ссылки я вообще молчу — там просто цифры уникальные. )))
Re[24]: SQL vs NOSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.04.12 15:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Перебор не проблема. Считывание с диска — проблема. Именно это и оптимизируют базы.

G>Ведь 1,000,000 статей, каждая хотябы по 1 кб размером — гиг данных. База умудряется искать статьи по автору за доли секунды. Напиши перебор, который так же быстро сработает.

Считывание в диска не проблема, все помещается в RAM, всего около 5 гиг.

На миллионе статей простой поиск по одному фильтру без индексов по памяти как раз за доли секунды выполняется в один поток.

$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX_SIZE 1000000

struct article
{
  int author_n;
};

int main(int argc, char* argv[])
{
  struct article* articles = malloc(MAX_SIZE * sizeof(struct article));
  memset(articles, 0, MAX_SIZE * sizeof(struct article));
  const struct article* end = articles + MAX_SIZE;
  const struct article* ptr = articles;

  int count = 0;
  while (ptr != end)
  {  
    if (ptr->author_n == 0)
      ++count;
    ++ptr;
  }    

  printf("count = %d\n", count);    
  free(articles);

  return 0;
}
$ gcc -std=c99 -O2 test.c
$ time ./a.out
count = 1000000

real    0m0.005s
user    0m0.004s
sys     0m0.000s
Re[24]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 15:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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

G>>>В SQL создание индексов заняло около 10 секунд. Сделал drop и create

_>>Протестировал. Получилось 4,9 секунды создание индекса.
G>У меня 60 секунд создавался на 100,000 статей по 10 тегов в каждой.

Ммм, не понял, это в какой базе?

G>Квалификация не при чем. Два предиката могут давать очень большие множества, но пересечение их будет пусто. СУБД используют статистику по индексам чтобы в первую очередь получать записи по тем предикатам, которые возвращают меньше всего.


Так мы же работаем под конкретную задачу — разработчик должен знать все нюансы и подбирать решение под неё. В отличие от универсальных алгоритмов sql субд, которые хороши в среднем везде.

G>Я питон так и не поставил, поэтому сравнить не могу.


Могу накидать краткую инструкцию со ссылками. Там делов на минуту)
Re[19]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 20.04.12 15:32
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Что-то у вас какие-то странные представления о бизнесе, как будто бы там деньги девать некуда. Если у меня вдруг проект упрётся в базу данных (такого ещё не было кстати, но это просто потому что у нас другой профиль деятельности), то я просто арендую в том же датацентре ещё пару соседних серверов и раскидаю базу по ним. А тех денег с вашего "маленького решения" хватит лет на 10 аренды. Про первые две ссылки я вообще молчу — там просто цифры уникальные. )))

Ну так то же самое касается и SQL решения. Или вы думаете, что арендовать можно только для NoSQL?
Насчёт 10 лет — что-то я сомневаюсь. Я не знаток рынка аренды серверов, но мне как-то странно. Зачем бы хостеру покупать сервер за $XXXXX баксов, а потом сдавать его в аренду по цене 1/120 от покупной цены? Ведь у него срок службы — от силы лет пять, а в аренду входит помимо самой железки ещё и электричество и охлаждение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[25]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 20.04.12 15:46
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Вообще если брать простенькие сервера из мейнстрима, то несколько штук их будет стоить дешевле чем аналогичная их сети одна машина.

1. Что вы называете "простеньким сервером из мейнстрима"?
2. Можно пруф на соотношение цен одной коробки и эквивалентной пачки коробок?

_>Так мы же работаем под конкретную задачу — разработчик должен знать все нюансы и подбирать решение под неё. В отличие от универсальных алгоритмов sql субд, которые хороши в среднем везде.

Дупа в том, что разработчик должен не только быть суперквалифицированным, но ещё и невероятно прозорливым. Заранее придумать нужные структуры данных и угадать, где именно будет узкое место. Т.к. "планы запросов" намертво вшиты в код приложения, лёгким манием руки поменять их "на лету" не выйдет.
Вот тут ссылочка пробегала в текущую темку в базах данных, где у парня внезапно сменился план запроса и index scan превратился в index seek. Это как раз типичный пример late optimization. Если бы задачу решал программист и вручную, то был бы велик риск того, что он бы заложился на index scan, который оказывался оптимальнее на тестовых данных. А потом было бы поздно пить боржоми, т.к. смена плана запроса — это переделка приложения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[23]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 20.04.12 15:53
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну я может не особо разобрался что там за рейтингм, так посмотрел только цифры по ссылкам. Но в любом случае мне кажется что как раз технология гугла перспективнее в любых применениях. Так что может рейтинг отражает уже не актуальные параметры? )

Этот рейтинг — он как рейтинг на RSDN. В начале легко попасть в top-10, но все дальнейшие победы требуют всё больших вложений.
Поэтому мне, к примеру, понятна неготовность условно-бесплатных решений к инвестициям в эксперимент, который поставит их на 2400 строчку в табели о рангах (хотя, если у них всё так здорово, можно было бы посоревноваться не в tpmC, а в tpmc/$)ю
А вот с ресурсами гугла поставить эксперимент стоимостью в полсотни миллионов — вполне реально. Тем более у них железа дохрена, так что покупать не обязательно — можно на пару дней занять из собственных запасов.

_>Ох,у меня такое впечателение что я постоянно говорю одно, а все вокруг слышат другое. Я же вроде несколько раз в этой теме говорил что как раз у nosql всегда был высокий порог вхождения. В отличие от sql, где мы придумали запросец и всё — дальше "база там как-то сама оптимально всё выполнит". А только в последние годы порог nosql стал снижаться до уровня удобной и простой работы. И соответственно сразу туда повалил народ.

Ну, это просто радикально расходится с тем, что говорят все остальные апологеты NoSQL. Вот, тут же в топике давали ссылку на статьи на хабре и не только, где основная идея — "мне не надо думать над структурой базы, и не надо бояться, что при росте нагрузки я упрусь в ограничения".

_>Ну и кстати по моему примеру вроде как видно насколько продвинулись в этом. Он просто несравнимо короче и проще диких и страшных запросов с кучей join. Про xml схему базы я вообще молчу.

Ну, это ещё как посмотреть. Запросы с join я хотя бы прочесть могу. Хотя с точки зрения компактности претензий нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[20]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 16:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну так то же самое касается и SQL решения. Или вы думаете, что арендовать можно только для NoSQL?


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

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

S>Насчёт 10 лет — что-то я сомневаюсь. Я не знаток рынка аренды серверов, но мне как-то странно. Зачем бы хостеру покупать сервер за $XXXXX баксов, а потом сдавать его в аренду по цене 1/120 от покупной цены? Ведь у него срок службы — от силы лет пять, а в аренду входит помимо самой железки ещё и электричество и охлаждение.


Имелось в виду что сервера разные (как раз то, про что писали в след. сообщение).
Re[26]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 17:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>1. Что вы называете "простеньким сервером из мейнстрима"?


То что в данный момент предлагают хостеры по основным тарифам. Они как раз не дураки и обычно используют самые экономичные решения.

S>2. Можно пруф на соотношение цен одной коробки и эквивалентной пачки коробок?


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

S>Дупа в том, что разработчик должен не только быть суперквалифицированным, но ещё и невероятно прозорливым. Заранее придумать нужные структуры данных и угадать, где именно будет узкое место. Т.к. "планы запросов" намертво вшиты в код приложения, лёгким манием руки поменять их "на лету" не выйдет.

S>Вот тут ссылочка пробегала в текущую темку в базах данных, где у парня внезапно сменился план запроса и index scan превратился в index seek. Это как раз типичный пример late optimization. Если бы задачу решал программист и вручную, то был бы велик риск того, что он бы заложился на index scan, который оказывался оптимальнее на тестовых данных. А потом было бы поздно пить боржоми, т.к. смена плана запроса — это переделка приложения.

Ага, всё так и есть. Никто и не говорит что всё идеально. Но лично меня подобное не пугает. Доработка проекта всё равно обычно происходит.
Re[24]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 17:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

_>>Ох,у меня такое впечателение что я постоянно говорю одно, а все вокруг слышат другое. Я же вроде несколько раз в этой теме говорил что как раз у nosql всегда был высокий порог вхождения. В отличие от sql, где мы придумали запросец и всё — дальше "база там как-то сама оптимально всё выполнит". А только в последние годы порог nosql стал снижаться до уровня удобной и простой работы. И соответственно сразу туда повалил народ.

S>Ну, это просто радикально расходится с тем, что говорят все остальные апологеты NoSQL. Вот, тут же в топике давали ссылку на статьи на хабре и не только, где основная идея — "мне не надо думать над структурой базы, и не надо бояться, что при росте нагрузки я упрусь в ограничения".

Так то что "мне не надо думать что я потом куда-то упрусь" — это я отношу к преимуществу эксплуатации, а не разработки. Т.е. разрабатывать nosql сложнее (ну точнее раньше было, сейчас уже не факт и даже на оборот бывает), но потом при эксплуатации уже больше ни о чём голова не болит.
Re: SQL vs NOSQL
От: a_g_99 США http://www.hooli.xyz/
Дата: 20.04.12 17:17
Оценка:
Здравствуйте, alex_public, Вы писали:

_>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html


Потратил 2 мин., прочитал. Автор этой статьи должен мне две минуты своей жизни, потому как это очередной бред, не имеющий никого отношения к процессу разработки с применением БД. noSQL имеют определенные преимущества перед rdbms, но конечно они выражены не в том что цитирую автора "совершенно обычные, привычные каждому программисту списки в реляционных БД искажены до неузнаваемости и хранятся в неявном виде, где-то в индексах." (что это вообще за бред ).
Re[2]: SQL vs NOSQL
От: Ромашка Украина  
Дата: 20.04.12 17:51
Оценка:
Здравствуйте, a_g_99, Вы писали:
__>noSQL имеют определенные преимущества перед rdbms, но конечно они выражены не в том что...


О... А в чем он вообще имеет преимущества, кроме [полу]объектной модели?

Нет, я серьезно. Насколько я понимаю, индексы noSQL это какая-то реализация материализированных вьюх. И чё? Я вьюху в SQL не могу создать? Какие там вообще преимущества в нагрузке и производительности могут быть? Ну, хотя-бы, в теории?
http://brunets.name/ua_developer.gif

Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[27]: SQL vs NOSQL
От: _ABC_  
Дата: 20.04.12 18:46
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>>1. Что вы называете "простеньким сервером из мейнстрима"?


_>То что в данный момент предлагают хостеры по основным тарифам. Они как раз не дураки и обычно используют самые экономичные решения.


Давайте без общих слов и на конкретных примерах. Что вылезло из гугла по запросу dedicated hosting:
http://www.server4you.com/root-server/

Что из этого простенькое из мейнстрима, а что сложненькое. Сколько простеньких заменяют одного сложненького?
Re[21]: SQL vs NOSQL
От: _ABC_  
Дата: 20.04.12 18:48
Оценка:
Здравствуйте, alex_public, Вы писали:

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


А что мешает с РСУБД сделать так же?
Re[3]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 19:35
Оценка:
Здравствуйте, Ромашка, Вы писали:

Р>Нет, я серьезно. Насколько я понимаю, индексы noSQL это какая-то реализация материализированных вьюх. И чё? Я вьюху в SQL не могу создать?




Р>Какие там вообще преимущества в нагрузке и производительности могут быть? Ну, хотя-бы, в теории?


Может стоит почитать тему, перед тем, как писать? )
Re[4]: SQL vs NOSQL
От: Ромашка Украина  
Дата: 20.04.12 19:48
Оценка:
Здравствуйте, alex_public, Вы писали:
_>Может стоит почитать тему, перед тем, как писать? )

Я тред прочитал от ушей и до хвоста. По теме замечания будут?

ЗЫ. То, что ты не понял вопроса говорит только о твоей квалификации.
http://brunets.name/ua_developer.gif

Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[28]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 19:58
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>Давайте без общих слов и на конкретных примерах. Что вылезло из гугла по запросу dedicated hosting:

_AB>http://www.server4you.com/root-server/

Отличный примерчик. Я когда писал, то имел в виду даже чуть более дорогие решения (ну по своему опыту). А эти я смотрю не сильно хуже (хотя raid софтверный, память не ecc, opteron, а не xeon), а при этом ещё в 2 раза дешевле.

_AB>Что из этого простенькое из мейнстрима, а что сложненькое. Сколько простеньких заменяют одного сложненького?


Всё Pro Server по ссылке выглядят подходящими предложениями. А вот сколько их надо для замены одной из мегамашинок обсуждаемых выше — трудно сказать, т.к. это существенно зависит от софта. Т.е. при сравнение разных баз данных будут разные цифры. Надо смотреть конкретно. Но если взглянуть на цены (70 баксов/месяц!), то там их стооооооолько можно набрать...
Re[22]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 20:05
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>А что мешает с РСУБД сделать так же?


Шардинг sql баз? ) Вы сторонник садо-мазо? )))
Re[5]: SQL vs NOSQL
От: alex_public  
Дата: 20.04.12 20:12
Оценка:
Здравствуйте, Ромашка, Вы писали:

Р>Я тред прочитал от ушей и до хвоста. По теме замечания будут?


В этой теме уже были прямые ответы именно на вопрос о "преимуществах в нагрузке и производительности ". Собственно только это и обсуждали, поскольку первоначальное сообщение про "естественность для программиста" было скорее ради забавы в теме про DSL, а здесь уже обсуждение пошло про вообще nosql и по серьёзному. Так что какое-то странное прочтение было. Да, и никто специально повторять по второму кругу это не будет.
Re: SQL vs NOSQL
От: Mamut Швеция http://dmitriid.com
Дата: 20.04.12 21:53
Оценка: 2 (1) -1
_>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html

И это все фигня

NoSQL хорош только до тех пор, пока они остаются, по сути, key-value хранилищами. Потому что тогда они могут обеспечить и быстроту, и расширямость и "евентуальную персистентность" и вообще быть 100% buzzword-compliant.

Но как только кто-то попытается хоть на шаг отойти от этой модели, начинаются приседания и пляски с бубном.

Извините, но хранить два списка — один отсортированный, а один не отсортированный только потому, что нам понадобятся оба? А если нам понадобится сортировка в обратную сторону? А по нескольким критериям? На каждую комбинацию заводить по списку?

А что делать с реляционными данными, которые нам все равно понадобятся? Скажем все спасибо Гуглу за его работу по map-reduce. Но это выливается в "Если вы хотите объединять данные, запустите map/reduce и дождитесь завершения запроса, пока мы будем прогоняться по абсолютнро всем данным, что у нас естьв базе данных/таблице".

В итоге практичски любая NoSQL-система — это не web server + server-side programming language + RDBMS, как это должно быть, а web server + server-side programming language + штук пять кэшей разного уровня + язык, на котором прогарммируется map/reduce в этой базе и/или какой-нибудь Hadoop, причем на уровне нагрузки, на которой для RDBMS только-только начинаешь думать "а может, нам начать кэшировать запросы?" Утрирую, конечно.

Единственное, с чем соглашуь — что да, хочется чтобы твоя база данных понимала что-нить типа
Person p = db.get("person").where({age > 21}).filter(какая-нить лямда) и т.п.


Но, замечу, и NoSQL такого не предоставляет и предоставить не может.


dmitriid.comGitHubLinkedIn
Re[23]: SQL vs NOSQL
От: _ABC_  
Дата: 21.04.12 05:26
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_AB>>А что мешает с РСУБД сделать так же?


_>Шардинг sql баз? ) Вы сторонник садо-мазо? )))


Зачем шардинг обязательно? Если я вопрусь в ограничения по железу, то у меня есть много вариантов разнесения нагрузки. Только я и вопрусь позже, чем nosqlщики и времени на подумать у меня будет намного больше.
Re[25]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.12 10:26
Оценка:
Здравствуйте, Mystic, Вы писали:

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


G>>Перебор не проблема. Считывание с диска — проблема. Именно это и оптимизируют базы.

G>>Ведь 1,000,000 статей, каждая хотябы по 1 кб размером — гиг данных. База умудряется искать статьи по автору за доли секунды. Напиши перебор, который так же быстро сработает.

M>Считывание в диска не проблема, все помещается в RAM, всего около 5 гиг.


M>На миллионе статей простой поиск по одному фильтру без индексов по памяти как раз за доли секунды выполняется в один поток.


Как раз считывание — проблема. Потому что оно идет долго. Ты от даже не пытался померить сколько оно займет. Любая серьезная база будет иметь объем больше ОП сервера и то что ты написал не подойдет.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[25]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.12 10:34
Оценка:
Здравствуйте, alex_public, Вы писали:

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


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


Что-то слабо верится. Расчеты какиенить приведи со ссылкой на вендора.
Кроме того не забывай что распределенность небесплатная. Например для mongo надо репликацию поднимать, репликация вызывает запись, которая лочит весь инстанс.

_>Вообще если брать простенькие сервера из мейнстрима, то несколько штук их будет стоить дешевле чем аналогичная их сети одна машина.


G>>>>В SQL создание индексов заняло около 10 секунд. Сделал drop и create

_>>>Протестировал. Получилось 4,9 секунды создание индекса.
G>>У меня 60 секунд создавался на 100,000 статей по 10 тегов в каждой.

_>Ммм, не понял, это в какой базе?

mongo

G>>Квалификация не при чем. Два предиката могут давать очень большие множества, но пересечение их будет пусто. СУБД используют статистику по индексам чтобы в первую очередь получать записи по тем предикатам, которые возвращают меньше всего.

_>Так мы же работаем под конкретную задачу — разработчик должен знать все нюансы и подбирать решение под неё. В отличие от универсальных алгоритмов sql субд, которые хороши в среднем везде.
Ну то есть нужно на более низком уровне работать, руками выполняя то что делает РСУБД автоматом. Тут некоторые пытаются сказать что NoSQL как раз более высокий уровень абстракции дает.

G>>Я питон так и не поставил, поэтому сравнить не могу.

_>Могу накидать краткую инструкцию со ссылками. Там делов на минуту)
Лучше скрипт сразу. Встроенный язык shell — javascript. Там нету множеств и пересечений.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[16]: SQL vs NOSQL
От: Enomay  
Дата: 21.04.12 10:57
Оценка:
G>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.
G>Полнотекстовый поиск не использовать.

250-300 мс. 8 гигов памяти. проц 5ти летней давности E6850.
Re[16]: SQL vs NOSQL
От: Enomay  
Дата: 21.04.12 11:00
Оценка:
а если верить консоли, то там результат еще лучше

Query: (Tags:"Tag 2" OR Tags:"Tag 20") OR Tags:"Tag 55"
Time: 39 ms
Index: Temp/Posts/ByTags
Results: 128 returned out of 10 320 total.
Re[6]: SQL vs NOSQL
От: Ромашка Украина  
Дата: 21.04.12 11:53
Оценка: 1 (1) -1
Здравствуйте, alex_public, Вы писали:
_>В этой теме уже были прямые ответы именно на вопрос о "преимуществах в нагрузке и производительности ".

Не было тут ответов по производительности и нагрузке. Тут было подтасовывание фактов -- выборка происходит быстрее. Черт с ним, я могу насоздавать материализованных вьюх, которые будут обеспечивать точно такую же скорость выборки: O(log n). Скорость инсертов капитально просядет. Я понимаю почему. Я одного не понимаю, откуда в noSQL вдруг возьмется большая производительность, если в noSQL придется перестраивать как минимум столько же вьюх/индексов?
http://brunets.name/ua_developer.gif

Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[17]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.12 12:00
Оценка:
Здравствуйте, Enomay, Вы писали:

E>а если верить консоли, то там результат еще лучше


E>Query: (Tags:"Tag 2" OR Tags:"Tag 20") OR Tags:"Tag 55"

E>Time: 39 ms
E>Index: Temp/Posts/ByTags
E>Results: 128 returned out of 10 320 total.

Что за консоль? Запрос в оригинале был с AND
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[17]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.12 12:00
Оценка:
Здравствуйте, Enomay, Вы писали:

G>>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.

G>>Полнотекстовый поиск не использовать.

E>250-300 мс. 8 гигов памяти. проц 5ти летней давности E6850.


Скрипт для воспроизведения покажи
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[7]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.12 12:10
Оценка:
Здравствуйте, Ромашка, Вы писали:

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

_>>В этой теме уже были прямые ответы именно на вопрос о "преимуществах в нагрузке и производительности ".

Р>Не было тут ответов по производительности и нагрузке. Тут было подтасовывание фактов -- выборка происходит быстрее. Черт с ним, я могу насоздавать материализованных вьюх, которые будут обеспечивать точно такую же скорость выборки: O(log n). Скорость инсертов капитально просядет. Я понимаю почему. Я одного не понимаю, откуда в noSQL вдруг возьмется большая производительность, если в noSQL придется перестраивать как минимум столько же вьюх/индексов?


В среднем SQL + кеш + полнотекстовый индекс (внешний) будет выигрывать у NoSQL. NoSQL рулит только в получении по ключу при небольшом количестве записей.
С современных веб-проектах, особенно где не требуются гарантии сохранности данных, можно около 80% сценариев свести к получению по ключу. Остальное делать через map-reduce индексы. Вот только это требует гораздо больших усилий со стороны разработчика и гораздо проще сделать все неправильно. Хоть при этом и не надо понимать нормальные формы и реляционную алгебру, все равно для NoSQL требуется больше умений.

Так что я вообще не вижу где можно использовать NoSQL кроме самых простых проектов. Ну и обсуждения в интернетах показываю что основная аудитория nosql — те кто sql ниасилил и теперь их проекты хоть как-то работают на nosql.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[23]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.12 12:26
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_AB>>А что мешает с РСУБД сделать так же?


_>Шардинг sql баз? ) Вы сторонник садо-мазо? )))


А в чем проблема то?

1) Берем несколько серверов
2) Делаем часть таблиц sharded, в каждой указываем
3) Другие таблицы делаем replicated (справочники), настраивая репликацию, можно через master data services
4) В приложении пишем distribution function, которая по по partition key выбирает нужную строку соединения
5) Для fan-out queries пишем также функцию слияния (чтобы множество сортированных результатов сливались вместе, давая сортированный результат)
Если знать и уметь, то все это делается за пару часов.

6) Как вариант сделать distributed view внутри SQL Server с триггерами, которые отправляют запрос записи нужному серваку.

А можно тупо LB сделать с pont-to-point синхронной репликацией. Говорят что такое дает 1,7 коэффициент масштабирования (типа два сервера работают как 1,7).

Вообще-то SQL Server горизонтально масштабируется очень хорошо, если с умом подходить к процессу. Проблему представляют лицензии в данном случае.
Вертикальное масштабирование для взрослых СУБД банально выгоднее.

А для Azure (где горизонтальное масштабироваие по-умолчанию) уже придумали federations.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[2]: SQL vs NOSQL
От: alex_public  
Дата: 21.04.12 14:35
Оценка:
Здравствуйте, Mamut, Вы писали:

M>И это все фигня


В целом да, статья "ненаучная" и люди выбирают nosql естественно не за какую-то "приятность для программиста". Но всё же ней что-то есть... Например при попытке засунуть в sql базу иерархию произвольной вложенности с возможностью обхода по дереву, мысль о неестественности таких баз возникает сама собой. )))

M>NoSQL хорош только до тех пор, пока они остаются, по сути, key-value хранилищами. Потому что тогда они могут обеспечить и быстроту, и расширямость и "евентуальную персистентность" и вообще быть 100% buzzword-compliant.

M>Но как только кто-то попытается хоть на шаг отойти от этой модели, начинаются приседания и пляски с бубном.

Нуу это смотря как отойти. Например индексы — это уже у нас тоже по сути key-value. Если мы посмотрим на работу например с mongodb, то никаких приседаний (для пользователя базы) не видно.

M>Извините, но хранить два списка — один отсортированный, а один не отсортированный только потому, что нам понадобятся оба? А если нам понадобится сортировка в обратную сторону? А по нескольким критериям? На каждую комбинацию заводить по списку?


Угу, не удобно это всё делать вручную. Поэтому пока не появились удобные автоматические инструменты, nosql и использовался в основном монстрами для особых целей (типа гугла).

M>Единственное, с чем соглашуь — что да, хочется чтобы твоя база данных понимала что-нить типа

M>
M>Person p = db.get("person").where({age > 21}).filter(какая-нить лямда) и т.п.
M>


Сделать такое в любой базе sql/nosql вообще не проблема. Весь вопрос в том, какая скорость у этого будет.
Re[24]: SQL vs NOSQL
От: alex_public  
Дата: 21.04.12 14:38
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>Зачем шардинг обязательно? Если я вопрусь в ограничения по железу, то у меня есть много вариантов разнесения нагрузки.


OK. Какие ещё варианты разнесения на десяток машин базы данных? Можно пример как это делается с sql базами? С nosql я пример уже привёл в этой темке.

_AB> Только я и вопрусь позже, чем nosqlщики и времени на подумать у меня будет намного больше.


Почему позже? На чём основан этот вывод?
Re[26]: SQL vs NOSQL
От: alex_public  
Дата: 21.04.12 14:53
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Что-то слабо верится. Расчеты какиенить приведи со ссылкой на вендора.


Да вроде все ссылки по ценам уже были здесь. Осталось только научиться вычислять сети из скольких простеньких машин равносилен один суперсервер. Я сразу говорю что не представляю как оценить — только провести эксперимент... ) Но судя по ценам там ТАКОЙ запас возникает, что... )))

G>Ну то есть нужно на более низком уровне работать, руками выполняя то что делает РСУБД автоматом. Тут некоторые пытаются сказать что NoSQL как раз более высокий уровень абстракции дает.


Согласен. Не знаю с чего тут некоторые говорят такое. По алгоритмам нет вопросов — более низкий уровень. А вот смысле организации данных... В nosql возможен более объектный подход, который автоматом кое-какие мелочи включает (ну вот как в примере нашем: там тэги и статья — по сути единая сущность). Но в целом согласен.

G>Лучше скрипт сразу. Встроенный язык shell — javascript. Там нету множеств и пересечений.


Брррр, если можно писать на красивом языке, то зачем делать это на ужасном? )
Re[18]: SQL vs NOSQL
От: Enomay  
Дата: 21.04.12 14:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


E>>а если верить консоли, то там результат еще лучше


E>>Query: (Tags:"Tag 2" OR Tags:"Tag 20") OR Tags:"Tag 55"

E>>Time: 39 ms
E>>Index: Temp/Posts/ByTags
E>>Results: 128 returned out of 10 320 total.

G>Что за консоль? Запрос в оригинале был с AND


поставил AND. стало еще быстрее. приложение говорит на 20 ms быстрее. если верить консоли рейвена, то отрабатывает 5 ms, вместо 35-40 с or.
консоль от сервера.

E>>Скрипт для воспроизведения покажи


какой скрипт? в коде

var timer = new Stopwatch();

timer.Start();

var result = session.Query<Post>().Where(p => p.Tags.Any(t => t == "Tag 51") && p.Tags.Any(t => t == "Tag 79") && p.Tags.Any(t => t == "Tag 69")).ToArray();

timer.Stop();


в базе динамический индекс:
from doc in docs.Posts
select new { Tags = doc.Tags }

запрос из студии по индексу :
Tags:"Tag 2" AND Tags:"Tag 20" AND Tags:"Tag 1"

если брать чистый сервер, то 3-5ms, если приложение на C#, то 230ms. подозреваю что накладка в десериализации объектов.
Re[7]: SQL vs NOSQL
От: alex_public  
Дата: 21.04.12 15:04
Оценка:
Здравствуйте, Ромашка, Вы писали:

Р>Не было тут ответов по производительности и нагрузке. Тут было подтасовывание фактов -- выборка происходит быстрее. Черт с ним, я могу насоздавать материализованных вьюх, которые будут обеспечивать точно такую же скорость выборки: O(log n). Скорость инсертов капитально просядет. Я понимаю почему. Я одного не понимаю, откуда в noSQL вдруг возьмется большая производительность, если в noSQL придется перестраивать как минимум столько же вьюх/индексов?


Вроде бы же ясно сказали, что преимущество возникает когда мы упираемся в рамки одной машины. У sql баз тут сразу дикие ужасы. А у nosql всё автоматом из коробки работает. Когда-то раньше разработка под nosql была заметно сложнее, соответственно для большинства проектов было глупо использовать nosql на ранних стадиях — ещё не известно понадобится ли масштабирование в принципе или нет. Но в последнее время с современными инструментами разработка под nosql стала не особо сложнее slq решений. И соответственно уже появляется смысл заложить автоматическое масштабирование на будущее, т.к. это практически бесплатно становится.

Что касается сравнения скорости работы в рамках одной машины, то тут уже совсем другая картина и всё зависит от конкретной задачи. Т.е. частенькой (особенно в веб-проектах) nosql ускоряет и тут, но только из-за особенности задачи, а не то что такое преимущество заложено (как в ситуации, когда мы переходим на несколько машин) в сами основы.

Теперь понятно? И между прочим всё это уже было высказано в теме.
Re[24]: SQL vs NOSQL
От: alex_public  
Дата: 21.04.12 15:20
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А в чем проблема то?

G>1) Берем несколько серверов
G>2) Делаем часть таблиц sharded, в каждой указываем
G>3) Другие таблицы делаем replicated (справочники), настраивая репликацию, можно через master data services
G>4) В приложении пишем distribution function, которая по по partition key выбирает нужную строку соединения
G>5) Для fan-out queries пишем также функцию слияния (чтобы множество сортированных результатов сливались вместе, давая сортированный результат)
G>Если знать и уметь, то все это делается за пару часов.
G>6) Как вариант сделать distributed view внутри SQL Server с триггерами, которые отправляют запрос записи нужному серваку.
G>А можно тупо LB сделать с pont-to-point синхронной репликацией. Говорят что такое дает 1,7 коэффициент масштабирования (типа два сервера работают как 1,7).

Ужасы какие. Это же переделка всего. В то время как в случае nosql мы вообще ничего не трогаем проекте. Только запускаем новые сервера, правим конфиг и всё.

G>Вообще-то SQL Server горизонтально масштабируется очень хорошо, если с умом подходить к процессу. Проблему представляют лицензии в данном случае.


Если бы это было так, то все эти современные проекты даже не родились бы. А все монстры спокойно сидели на sql.

G>Вертикальное масштабирование для взрослых СУБД банально выгоднее.


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

G>А для Azure (где горизонтальное масштабироваие по-умолчанию) уже придумали federations.


1. В целом оно даже приятнее чем nosql масштабируется (т.е. согласен типа)
2. Это масштабирования только до определённых пределов. Не помню какие там сейчас цифры. Т.е. в целом это решение подходит только до определённой нагрузки, а дальше вообще никак.
3. Система оплаты с облаком (если оно не своё) частенько бывает менее выгодной, чем свой сервер.
Re[26]: SQL vs NOSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 21.04.12 18:48
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Как раз считывание — проблема. Потому что оно идет долго. Ты от даже не пытался померить сколько оно займет. Любая серьезная база будет иметь объем больше ОП сервера и то что ты написал не подойдет.


Информация, которая нужна для хитрого поиска, у нас помещается в ОЗУ с большим запасом: 5G / 64G ~= 8%. А другие теоретические задачи меня не интересуют. Там где нужна транзакционность, там используется как раз SQL.
Re[3]: SQL vs NOSQL
От: Mamut Швеция http://dmitriid.com
Дата: 22.04.12 00:07
Оценка:
M>>И это все фигня

_>В целом да, статья "ненаучная" и люди выбирают nosql естественно не за какую-то "приятность для программиста". Но всё же ней что-то есть... Например при попытке засунуть в sql базу иерархию произвольной вложенности с возможностью обхода по дереву, мысль о неестественности таких баз возникает сама собой. )))



О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается


dmitriid.comGitHubLinkedIn
Re[25]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.04.12 08:23
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>А в чем проблема то?

G>>1) Берем несколько серверов
G>>2) Делаем часть таблиц sharded, в каждой указываем
G>>3) Другие таблицы делаем replicated (справочники), настраивая репликацию, можно через master data services
G>>4) В приложении пишем distribution function, которая по по partition key выбирает нужную строку соединения
G>>5) Для fan-out queries пишем также функцию слияния (чтобы множество сортированных результатов сливались вместе, давая сортированный результат)
G>>Если знать и уметь, то все это делается за пару часов.
G>>6) Как вариант сделать distributed view внутри SQL Server с триггерами, которые отправляют запрос записи нужному серваку.
G>>А можно тупо LB сделать с pont-to-point синхронной репликацией. Говорят что такое дает 1,7 коэффициент масштабирования (типа два сервера работают как 1,7).

_>Ужасы какие. Это же переделка всего. В то время как в случае nosql мы вообще ничего не трогаем проекте. Только запускаем новые сервера, правим конфиг и всё.


п1-5 можно написать один раз и потом использовать.

G>>Вообще-то SQL Server горизонтально масштабируется очень хорошо, если с умом подходить к процессу. Проблему представляют лицензии в данном случае.

_>Если бы это было так, то все эти современные проекты даже не родились бы. А все монстры спокойно сидели на sql.
А они и так сидят
Hype вокруг NoSQL уже года 2 есть, а до сих пор ни одного нагруженного проекта на NoSQL нету.
Все "монстры" используют NoSQL базы как кеш или промежуточный слой, но никак не основное хоранилище.

G>>Вертикальное масштабирование для взрослых СУБД банально выгоднее.

_>Для субд выгоднее, а для кармана бизнеса — нет))) Для какого-нибудь там Сбербанка возможно и проще так. Ну а мы лучше более экономными решениями обойдёмся. )
Вот только практика показывает что бизнес выбирает mature решения.

G>>А для Azure (где горизонтальное масштабироваие по-умолчанию) уже придумали federations.


_>2. Это масштабирования только до определённых пределов. Не помню какие там сейчас цифры. Т.е. в целом это решение подходит только до определённой нагрузки, а дальше вообще никак.

Пруфлинк?

_>3. Система оплаты с облаком (если оно не своё) частенько бывает менее выгодной, чем свой сервер.

Да ну? Только железо и ОС выйдет дороже, чем SQL Azure.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[26]: SQL vs NOSQL
От: alex_public  
Дата: 22.04.12 15:32
Оценка:
Здравствуйте, gandjustas, Вы писали:

_>>Если бы это было так, то все эти современные проекты даже не родились бы. А все монстры спокойно сидели на sql.

G>А они и так сидят
G>Hype вокруг NoSQL уже года 2 есть, а до сих пор ни одного нагруженного проекта на NoSQL нету.
G>Все "монстры" используют NoSQL базы как кеш или промежуточный слой, но никак не основное хоранилище.

Я вообще то приводил здесь ссылку, по которой была собрана в одном месте информация по "монстрам". И там хорошо видно кто на чём сидит и куда направлена тенденция развития. Особенно мне там понравилась идея кластеров mysql работающих в режиме ключ-значение (и запретом join) с автоматическим шардингом (через свой велосипед). И почему то не удивительно что именно эта компания так вложилась в nosql разработку.

G>Вот только практика показывает что бизнес выбирает mature решения.


Что мы подразумеваем под бизнесом? Если некомпьютерные компании, то они вообще используют что дают под их задачи. Т.е. прикладной софт использующий nosql только только начинает появляться. Если же компьютерные, то тут тоже не всё просто — для работающих проектов переход на nosql может не окупиться даже при явном техническом преимуществе, просто за счёт цены перехода. А вот новые проекты... Тут уже всё гораздо интереснее... Более того, если опять же посмотрим на те данные по "монстрам" (другие просто труднее найти), то увидим что большинство новых функций даже в рабочие проекты добавляются через nosql.

Так что каких-то резких рывков естественно не будет. Всё происходит постепенно и в основном на новых проектах...

G>>>А для Azure (где горизонтальное масштабироваие по-умолчанию) уже придумали federations.

_>>2. Это масштабирования только до определённых пределов. Не помню какие там сейчас цифры. Т.е. в целом это решение подходит только до определённой нагрузки, а дальше вообще никак.
G>Пруфлинк?

Лень искать сейчас. Помню где-то на msdn видел. Смутно вспоминаются цифры в 50Гб...

_>>3. Система оплаты с облаком (если оно не своё) частенько бывает менее выгодной, чем свой сервер.

G>Да ну? Только железо и ОС выйдет дороже, чем SQL Azure.

Под своим серверов подразумевается и аренда. ) Я имел в виду именно разницу в принципе оплаты: по месяцам или по тактам. Бывают задачи в которых выгоднее как один принцип, так и другой.
Re[27]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.04.12 17:21
Оценка:
Здравствуйте, alex_public, Вы писали:

G>>Вот только практика показывает что бизнес выбирает mature решения.


_>Что мы подразумеваем под бизнесом? Если некомпьютерные компании, то они вообще используют что дают под их задачи. Т.е. прикладной софт использующий nosql только только начинает появляться.

И что это за софт? Пока что это говнософт, который ни для одной business critical задачи не подойдет.
Тенденции к улучшению не видно, потому что основная идея — отсутствие гарантий в обмен на производительность.

_>Если же компьютерные, то тут тоже не всё просто — для работающих проектов переход на nosql может не окупиться даже при явном техническом преимуществе, просто за счёт цены перехода. А вот новые проекты... Тут уже всё гораздо интереснее...

Ссылки? В микроскоп не видно.

_>Более того, если опять же посмотрим на те данные по "монстрам" (другие просто труднее найти), то увидим что большинство новых функций даже в рабочие проекты добавляются через nosql.

Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.

G>>>>А для Azure (где горизонтальное масштабироваие по-умолчанию) уже придумали federations.

_>>>2. Это масштабирования только до определённых пределов. Не помню какие там сейчас цифры. Т.е. в целом это решение подходит только до определённой нагрузки, а дальше вообще никак.
G>>Пруфлинк?

_>Лень искать сейчас. Помню где-то на msdn видел. Смутно вспоминаются цифры в 50Гб...


Фигня какая-то. Можно одну базу на 150 гб поднять. А federations по сути создает базы. Так что фактически предел = 150(максимальное количество federations) * 150(размер БД) = 22,5 ТБ и стоить это все будет $34к (это очень мало)


_>>>3. Система оплаты с облаком (если оно не своё) частенько бывает менее выгодной, чем свой сервер.

G>>Да ну? Только железо и ОС выйдет дороже, чем SQL Azure.

_>Под своим серверов подразумевается и аренда. ) Я имел в виду именно разницу в принципе оплаты: по месяцам или по тактам. Бывают задачи в которых выгоднее как один принцип, так и другой.

Если аренда реального сервака, то за такты никто не будет брать. Будут брать за реальное время. При этом стоит у тебя сервак выключенный или считает что-то — не важно.
Поэтому для маленьких проектов проще взять один сервак в аренду и на нем запустить все: и базу, и приложение. А когда нагрузки растут, то становится неудобно. Или нужно покупать\брать в аренду много, или сервис будет лежать.

"облачный" подход с оплатой за использование и разделением compute и storage делает масштабирование гораздо выгоднее.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[29]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 22.04.12 18:13
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Всё Pro Server по ссылке выглядят подходящими предложениями. А вот сколько их надо для замены одной из мегамашинок обсуждаемых выше — трудно сказать, т.к. это существенно зависит от софта. Т.е. при сравнение разных баз данных будут разные цифры. Надо смотреть конкретно. Но если взглянуть на цены (70 баксов/месяц!), то там их стооооооолько можно набрать...

Я вас разочарую. В перформансе (любой) СУБД главную роль играет не коробка, а дисковая подсистема. Эти чудесные "ProServer" оборудованы парой 7200rpm дисков. У них крайне низкий IOPS, и улучшить это невозможно. Именно поэтому розничная цена такого сервера — примерно штука баксов, т.е. дешевле чем игровой десктоп. То есть мы имеем соотношение аренда:покупка примерно 1:10, как и должно быть.
Теперь, допустим, мы упёрлись в предел вашего маленького сервера. Скажем, я хочу улучшить его суммарные 6Gbps дисковой скорости в 12 раз.
Если я поставлю 12 таких "маленьких серверов", то буду платить $840 в месяц + $2400 единовременных расходов.
А если я куплю один Dell PowerEdge515 c 12ю 10к-rpm 2.5" винтами, то отдам $8511. Т.е. лишние затраты составят $6000, и окупятся за 8 месяцев.
А ведь этот сервер можно и в аренду взять! В сети нет готовых предложений, но ставка аренды обычно составляет примерно те же 10% покупной цены. Так что, как видите, не стоит переоценивать преимущества маленьких коробок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[20]: SQL vs NOSQL
От: Дельгядо Филипп Россия  
Дата: 22.04.12 23:42
Оценка: +2
G>>>так подними 30 млн. транзакций в минуту на NoSQL, в чем вопрос? Возьми первое место в TPC-C
>>А там вообще результаты от сетей компьютеров (не кластеров) принимают? )
G>Я думаю принимают.

Собственно, указанный результат на 30 млн. транзакций в минуту — он как раз для кластерных решений.

Но интересно посравнивать NoSQL решения с чем-нибудь вроде http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=110081701
(200000 tpm, 100k$, один прцессор (6 ядер)). Это как раз пример, что в БД главное — это дисковая система.

Ну или с чем-нибудь вроде http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=108072901
(тут всего-то 17k$, 20K tpm — и это результат 2008го года, так что цену можно смело уменьшить раза в три-четыре. Да и БД — откровенно не лидер).

Только надо еще помнить, что TPC-C — это полная реализация бизнес-логики (на уровне БД), т.е. надо сравнивать не только с NoSQL движком, а с всем комплексом из БД и бизнес-логики на сервере приложения.

Ну и если для относительно монолитных систем в TPC-C стоимость сетевой инфраструктуры еще можно опустить, для сетки из 1000 дешевых машинок стоимость инфраструктуры окажется уже сравнима со стоимостью самих машинок
Re[13]: SQL vs NOSQL
От: Дельгядо Филипп Россия  
Дата: 23.04.12 00:05
Оценка: +2
Здравствуйте, alex_public, Вы писали:


_>Эмм, ну основное то преимущество "by design" известно всем вроде.

_>Что вместо такого http://www.hi-lo.ru/news/clustrix-helps-scaling-without-sharding или http://habrahabr.ru/post/72122/ мы делаем просто
_>так http://gliffer.ru/articles/nosql--sharding-mongodb-na-paltsah/ и всё. У нас же задачи всё же определяет бизнес, а не кто-то ещё. А если взглянуть на цены первых двух ссылок, то всё становится очевидно.
_>Но вообще частенько (это уже зависит от конкретной задачи) преимущества проявляются и в случае одной машины. Например в комментах к этой статье http://habrahabr.ru/post/74144/ интересный пример человек приводит. Кстати, и сама статья любопытная в контексте нашего обсуждения.

Замечательные статьи. Честно говоря, я уже давно думаю, что сотрудников, читающих хабр без смеха надо увольнять, но получить сразу такую коллекцию подтверждений.
Человек не понимает, ни как работает Mongo, ни как работает SQL и даже не понимает, что его решение задачи "Яндекс.Маркета" на Mongo — полностью эквивалентно его же (неправильному) решению для РСУБД — но пишет про mongo и sql.
Впрочем, заглавная статья из LJ — тоже то еще сборище глупостей (хм, одна только мысль, что работа со списком имеет константное время уже позволяет не читать дальше).

В использовании нереляционных хранилищ есть несколько осмысленных идей, но вот пока их будут пропагандировать, гм, не слишком опытные программисты — то и отношение будет к ним соответствующее

P.S. Практически все прелести mongo (включая шардинг) делаются где-то за день-два на любой реляционной базе (оставляя в живых ACID, но прощаясь с гарантиями целостности, разумеется).
Re[4]: SQL vs NOSQL
От: Дельгядо Филипп Россия  
Дата: 23.04.12 00:15
Оценка:
Здравствуйте, Mamut, Вы писали:

M>О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается


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

Ну, может, что-нибудь из решений для хранения социальных графов для сетей — и выйдет в open-source...
Re[3]: SQL vs NOSQL
От: a_g_99 США http://www.hooli.xyz/
Дата: 23.04.12 05:21
Оценка:
Здравствуйте, Ромашка, Вы писали:
Р>О... А в чем он вообще имеет преимущества, кроме [полу]объектной модели?
В идеальном мире SQL побеждает без всяких возражений. С точки зрения DL это мощный простой изящный язык для DM-операций. Но мы же в идеальном мире? Т.е. нужно понимать что для реализации подобной системы требуются определенные ресурсы. Напр. сервер большой тройки сначала реализует этапы препроцессинга запроса, потом нормализует его, далее в работу включаются эвристический или стоимостной оптимизаторы. Они строят стратегии исполнения в зависимости от индексов, статистики, селективности, предыдущих планов исполнения и пр. Это значит, что системе потребуются расширенные ресурсы (память, потоки, жесткий диск и т.д.), и мин. требования будут достаточно жесткими. Стоит посмотреть на чемпиона TPC-C Oracle 11g DB, мин. требования вряд ли вам покажутся мягкими (как и цена) по сравнению напр. с tokyo cabinet. Отсюда и вытекают преимущества/недостатки noSQL:
1) Мобильность решения. Как правило такие системы крайне просты, имеют открытый код и их возможно пересобрать под свои нужды. Можно использовать в embedded, куда Oracle не поставишь в силу ограничений аппаратной части (напр. в тостер или телефон), на "экзотические" ОС
2) Возможно модифицировать и оптимизировать noSQL под собственный DL. Хотите кластеринг для определенной задачи — это возможно реализовать в силу открытости и отсутствия ограничения накладываемых на SQL. Требуется независимость от вендора в проекте (это про Гугл?) — welcome to opensource noSQL.

Ну и если у вас много энтузиазма + курсовая/научный проект и нет 20k на покупку норм. IMDB + RDBMS, вам поможет TinyCDB .
Re[28]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 05:36
Оценка:
G>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.

Фактически, ты говоришь глупости.
Re[4]: SQL vs NOSQL
От: Дельгядо Филипп Россия  
Дата: 23.04.12 06:12
Оценка:
Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, Ромашка, Вы писали:

Стоит посмотреть на чемпиона TPC-C Oracle 11g DB, мин. требования вряд ли вам покажутся мягкими (как и цена) по сравнению напр. с tokyo cabinet.

Хм, минимальные требования для минимального Oracle на самом деле выглядят так — "любой не очень старый компьютер". Цена при этом, разумеется, нулевая (да-да, у Oracle есть бесплатные редакции). Более того, требования у TokyoCabinet жестче, так как требуется *nix, а Oracle можно запустить и под Windows.

Ну и, конечно, есть и opensource РСУБД и встраиваемые РСУБД — на любой вкус.

Так что если и искать преимущества NoSQL — то в другом месте.
Re[5]: SQL vs NOSQL
От: Mamut Швеция http://dmitriid.com
Дата: 23.04.12 06:17
Оценка: 1 (1)
M>>О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается

ДФ>Ну, на практике графов, не влезающих в память довольно мало, делать для них движки смысла нет, проще писать конкретное решение. А если влезают — то и не шибко важно, как его хранить в persistance


Ну, вообще-то это не так. Ведь базы данных, которые в память не помещаются, откуда-то берутся? А любая реляционная база данных содержит в себе, по сути, графы (пусть и не всегда глубокие).

ДФ>Ну, может, что-нибудь из решений для хранения социальных графов для сетей — и выйдет в open-source...


Ну, граф-базы данных есть, и в опенсорсе в том числе — Neo4J, HyperGraphDB, OrientDB и т.п. Есть даже расширение для SQL под названием SPARQL для этих баз данных. Или там набор библиотек от TinkerPop'а. Но всем этим, правда, занимается полтора человека, и у всех проблемы — что делать с масштабируемостью, потому что никто не имеет представления, как разносить графы по нескольким машинам


dmitriid.comGitHubLinkedIn
Re[5]: SQL vs NOSQL
От: a_g_99 США http://www.hooli.xyz/
Дата: 23.04.12 07:17
Оценка:
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Хм, минимальные требования для минимального Oracle на самом деле выглядят так — "любой не очень старый компьютер". Более того, требования у TokyoCabinet жестче, так как требуется *nix, а Oracle можно запустить и под Windows.
Вы наверное шутите или тонко меня подкалываете ? Конечно, вы можете запустить на "любом не очень старом компьютере", но это не даст вам никаких преимуществ в использовании этого software. RDBMS (в частности сервера большой тройки) система уже сконфигурированная на реализацию определенных алгоритмов/методик и требует ресурсов (а также правильного dba-подхода). Это напоминает мне сравнения типа — "я поставил на своем бюджетном ноутбуке mysql и mssql (а еще linux, смотрю фильм, играю в стрелялку) и что-то не вижу преимуществ sql server.".
SQL обеспечивает простоту и гибкость получения данных, оптимизатор высокую производительность SQL-операций в условиях масштабирования без пересборки/переконфигурирования системы. За эти две фичи пользователь и готов платить большие деньги, в отличие от noSQL которые не могут этого. Но как я уже писал эффективная оптимизация (в целом без вашего участия) требует ресурсов больших чем "не очень старый компьютер".
>Цена при этом, разумеется, нулевая (да-да, у Oracle есть бесплатные редакции)
Использовать такой продукт можно только в учебных или демонстрационных целях. Мейджор и консалтеры рядом своего не упустит. Это касается не только тройки, но "бесплатных" младших братьев типа MySQL (посм. на Percona). A noSQL бесплатен как не крути.
>Более того, требования у TokyoCabinet жестче, так как требуется *nix, а Oracle можно запустить и под Windows
Для бизнеса — согласен на 100% (даже и слушать не захотят про токио). А для меня как для программиста, или положим для стартапера — это не требование. MiniGw в руки и вперед. Не нравится такой подход, есть BerkleyDB для win32 — он пока бесплатен.
ДФ>Ну и, конечно, есть и opensource РСУБД и встраиваемые РСУБД — на любой вкус.
Приведите примеры. Так чтобы это было бесплатно, не хлам типа Ingres DB, не сырой MariaDB от пупкин-софт с норм. производительностью, драйверами для мейнстрима + кроссплатформенность (win + unix). Самому интересно
Re[29]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 08:00
Оценка:
Здравствуйте, Enomay, Вы писали:

G>>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.


E>Фактически, ты говоришь глупости.


Да что ты? Покажи где по-другому.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[6]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 08:02
Оценка: +1
Здравствуйте, a_g_99, Вы писали:

>>Цена при этом, разумеется, нулевая (да-да, у Oracle есть бесплатные редакции)

__>Использовать такой продукт можно только в учебных или демонстрационных целях. Мейджор и консалтеры рядом своего не упустит. Это касается не только тройки, но "бесплатных" младших братьев типа MySQL (посм. на Percona). A noSQL бесплатен как не крути.
С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях?

Кроме того, PosеgreSQL, Firebird бесплатны со всех сторон, например.

__>Приведите примеры. Так чтобы это было бесплатно, не хлам типа Ingres DB, не сырой MariaDB от пупкин-софт с норм. производительностью, драйверами для мейнстрима + кроссплатформенность (win + unix). Самому интересно

Смотри выше.
Производительность нормальная, дрова вроде бы тоже есть и с кроссплатформенностью (хотя к чему она при нетиражируемом решении я не пойму) тоже все в порядке. Сам не пользовал, но читал про сотни внедрений и продуктов, построенных на основе этих СУБД и у многих проблем с нехваткой нагрузки нет. А про сколько внедрений я еще не слышал.

Я вообще не понимаю, откуда вы выкапываете всякие марииДБ и прочий хлам, про которой в мире СУБД почти никто слыхом не слыхивал, и упорно игнорируете если не лидеров в своих сегментах, но весьма и весьма известные вещи.
Re[30]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 08:06
Оценка: -1
G>>>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.

E>>Фактически, ты говоришь глупости.


G>Да что ты? Покажи где по-другому.


NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.
Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.
Re[4]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 08:15
Оценка:
Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, Ромашка, Вы писали:

Р>>О... А в чем он вообще имеет преимущества, кроме [полу]объектной модели?
__>В идеальном мире SQL побеждает без всяких возражений. С точки зрения DL это мощный простой изящный язык для DM-операций. Но мы же в идеальном мире? Т.е. нужно понимать что для реализации подобной системы требуются определенные ресурсы. Напр. сервер большой тройки сначала реализует этапы препроцессинга запроса, потом нормализует его, далее в работу включаются эвристический или стоимостной оптимизаторы. Они строят стратегии исполнения в зависимости от индексов, статистики, селективности, предыдущих планов исполнения и пр. Это значит, что системе потребуются расширенные ресурсы (память, потоки, жесткий диск и т.д.), и мин. требования будут достаточно жесткими.

А nosql решения поиск святым духом выполняют?

Вообще-то NoSQL выигрывает в скорости за счет тотального кеширования и отсуствия механизмов разруливания конкуретного доступа.
Если база поддерживает только выборку по ключу, то накладные расходы на чтение невелики. Если нужны предикативные выборки (а они нужны чуть более чем всегда), то нужны индексы.
Индексы в NoSQL зачастую крайне неэффективны, у того же couchDB используется lucene куда помещается ВСЕ, объем индекса иногда превосходит объем данных в несколько раз.

Пока все умещается в ОП — работает прекрасно, как только перестает влезать, то начинается веселье. Особенно на нетривиальных предикатах. С записью вообще песня. Большинство субд используют низкогранулярные блокировки при записи, вплоть до блокировки целого сервера или базы. При большом объеме начинает работать медленно, nosql возвращает управление раньше чем происходит реально запись, что в отсутствии журналирования делает базу крайне неустойчивой.

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

На небольших проектах с низкой нагрузкой еще можно закрывать глаза на такое, на серезных, нагруженных проектах с большим объемом баз — уже так не выйдет.
Тогда начинается — шардинг, репликация итп И получается что куча железа, сетевая инфрастуктура и прочие "радости" выходят дороже чем поставить промышленную БД.


__>1) Мобильность решения. Как правило такие системы крайне просты, имеют открытый код и их возможно пересобрать под свои нужды. Можно использовать в embedded, куда Oracle не поставишь в силу ограничений аппаратной части (напр. в тостер или телефон), на "экзотические" ОС

Это верно. Область применения SQL — простые проекты, где нет конкурентного доступа и большого объема данных , типа embed или десктоп приложения.

__>2) Возможно модифицировать и оптимизировать noSQL под собственный DL. Хотите кластеринг для определенной задачи — это возможно реализовать в силу открытости и отсутствия ограничения накладываемых на SQL. Требуется независимость от вендора в проекте (это про Гугл?) — welcome to opensource noSQL.

Это вообще не понял, кластеризацию нельзя на промышленных БД реализовать?
Кстати сколько nosql баз поддерживают стандартный для windows NLB или умеют хоститься на IIS? Вот тебе и enterprise ready

__>Ну и если у вас много энтузиазма + курсовая/научный проект и нет 20k на покупку норм. IMDB + RDBMS, вам поможет TinyCDB .

Если курсовая, ты можешь бесплатно по dreamspark юзать enterprise версию sql server.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[31]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 08:18
Оценка:
Здравствуйте, Enomay, Вы писали:

E>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.

E>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.

Т.е. я могу уложить биллинг, бухгалтерию, или другую задачу финансового учета в NoSQL и он будет работать так же надежно как с СУБД, но быстрее?

А почему аналитику нельзя уложить?
Re[32]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 08:22
Оценка:
E>>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.
E>>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.
_AB>Т.е. я могу уложить биллинг, бухгалтерию, или другую задачу финансового учета в NoSQL и он будет работать так же надежно как с СУБД, но быстрее?

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

_AB>А почему аналитику нельзя уложить?


отчеты удобнее строить сиквелом
Re[6]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 08:30
Оценка:
Здравствуйте, a_g_99, Вы писали:

__>A noSQL бесплатен как не крути.


Как раз таки большинcтво NoSQL имеют очень даже платные версии, а бесплатные обычно не превосходят бесплатные аналоги из мира SQL.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[7]: SQL vs NOSQL
От: a_g_99 США http://www.hooli.xyz/
Дата: 23.04.12 08:32
Оценка:
Здравствуйте, _ABC_, Вы писали:
_AB>С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях?
А как вы еще планируете ее использовать при наложенных ограничениях на процессор/диск/память? В live applications?

_AB>Кроме того, PosеgreSQL, Firebird бесплатны со всех сторон, например.

Про PostgreSQL я писал (Ingres) — не вижу перспектив данной системы, исключая БД от EnterpriseDB (и то надо думать ), но она платная.
Про Firebird — вы же не серьезно? 10 мб чистого фана . уж лучше нереляционная BerkleyDB от мейджора

_AB>Производительность нормальная, дрова вроде бы тоже есть и с кроссплатформенностью (хотя к чему она при нетиражируемом решении я не пойму) тоже все в порядке. Сам не пользовал, но читал про сотни внедрений и продуктов, построенных на основе этих СУБД и у многих проблем с нехваткой нагрузки нет. А про сколько внедрений я еще не слышал.

_AB>Я вообще не понимаю, откуда вы выкапываете всякие марииДБ и прочий хлам, про которой в мире СУБД почти никто слыхом не слыхивал, и упорно игнорируете если не лидеров в своих сегментах, но весьма и весьма известные вещи.
Приводите реальные примеры. Примеры типа — внедрение блогоплатформы в Бангладеше руками индейцов на платформе Firebird, о которой я читал в 199N году не подходит.
Re[31]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 08:34
Оценка:
Здравствуйте, Enomay, Вы писали:

G>>>>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.


E>>>Фактически, ты говоришь глупости.


G>>Да что ты? Покажи где по-другому.


E>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.

То что ты думаешь никого не интересует. Ты покажи реальные примеры, с нагрузкой. Такие чтобы можно было руками пощупать, а не гугл (у себя гугл при всем желании не поднимешь) или фейсбук (аналогично).


E>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.

Да-да, "быстрее" это как раз на чтение и с отсутствием гарантий при записи. Это есть сценарий кеширования.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[8]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 08:39
Оценка:
Здравствуйте, a_g_99, Вы писали:

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

_AB>>С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях?
__>А как вы еще планируете ее использовать при наложенных ограничениях на процессор/диск/память? В live applications?
Для десктоп решений более чем подходит даже при указанных ограничениях. Кроме того возможен вариант с распределенной работой при использовании синхронизации с центральной базой.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[32]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 08:58
Оценка:
E>>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.
G>То что ты думаешь никого не интересует. Ты покажи реальные примеры, с нагрузкой. Такие чтобы можно было руками пощупать, а не гугл (у себя гугл при всем желании не поднимешь) или фейсбук (аналогично).

http://www.mongodb.org/display/DOCS/Production+Deployments

E>>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.

G>Да-да, "быстрее" это как раз на чтение и с отсутствием гарантий при записи. Это есть сценарий кеширования.

Ну по вопросу скорости ты уже раз сфейлился. Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.

Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса
Re[33]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 09:01
Оценка:
Здравствуйте, Enomay, Вы писали:

E>а в чем проблема?

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

Не знаю, в чем проблема. Пытаюсь выяснить. Например, как мы будем хранить информацию о счетах? О транзакциях?


E>отчеты удобнее строить сиквелом

Дело только в "удобнее писать", или в чем-то еще, наподобие "сложнее собрать данные" и т.п.?
Re[34]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 09:04
Оценка:
_AB>Не знаю, в чем проблема. Пытаюсь выяснить. Например, как мы будем хранить информацию о счетах? О транзакциях?

В виде документов


E>>отчеты удобнее строить сиквелом

_AB>Дело только в "удобнее писать", или в чем-то еще, наподобие "сложнее собрать данные" и т.п.?

имхо, на sql проще написать логику агрегации большого объема данных, и сиквел скорее всего с этим справится лучше, нежели кастомное решение, в большинстве случаев.
Re[8]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 09:16
Оценка: :)
Здравствуйте, a_g_99, Вы писали:

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

_AB>>С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях?
__>А как вы еще планируете ее использовать при наложенных ограничениях на процессор/диск/память? В live applications?

Для приложений, которые не испытывают высокой нагрузки. Скажем, простенький сайт типа блога с кол-вом посещений до 10 000 в сутки с пиком в 1 500 в час Express редакция вполне себе потянет.

Ну, или для простых конфигураций 1С с небольшим количеством клиентов.

__>Про PostgreSQL я писал (Ingres) — не вижу перспектив данной системы, исключая БД от EnterpriseDB (и то надо думать ), но она платная.

1. Ingres мертв давным давно.
2. Это личное мнение. Я, например, не вижу перспектив noSQL, как замены SQL и что?

Доля PostgreSQL 19% от рынка основных опен-сорсных продуктов и я не думаю, что она будет падать. Да, ему не повезло попасть в hype в свое время, но это СУБД высокого уровня и свою долю рынка иметь будет. Особенно, учитывая неясное будущее mySQL.

__>Про Firebird — вы же не серьезно? 10 мб чистого фана . уж лучше нереляционная BerkleyDB от мейджора

Для небольших, но высоконагруженных проектов с размером БД не выше 50 ГБ вполне себе неплохое решение, ИМХО.

__>Приводите реальные примеры. Примеры типа — внедрение блогоплатформы в Бангладеше руками индейцов на платформе Firebird, о которой я читал в 199N году не подходит.

Хм... Что-то с реальными примерами с другой стороны туговато. Зачем мне это делать? Примеры успешных внедрений гуглятся на раз. Если будет интересно, сами найдете.
Re[33]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 09:20
Оценка:
Здравствуйте, Enomay, Вы писали:

E>>>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.

G>>То что ты думаешь никого не интересует. Ты покажи реальные примеры, с нагрузкой. Такие чтобы можно было руками пощупать, а не гугл (у себя гугл при всем желании не поднимешь) или фейсбук (аналогично).

E>http://www.mongodb.org/display/DOCS/Production+Deployments


E>>>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.

G>>Да-да, "быстрее" это как раз на чтение и с отсутствием гарантий при записи. Это есть сценарий кеширования.

E>Ну по вопросу скорости ты уже раз сфейлился.

В смыссе сфейлился? MS SQL Express без оптимизаций выдал примерно столько же сколько mongodb.
А ты не привел скрипт для воспроизведения.

E>Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.

Давай, нивопрос. Предлагай сценарий.

E>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса

Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью? И как бороться в случае если это произойдет? Выгодно в этом плане только raven отличается, у него честный acid есть.

Взять например сценарий бухгалтерского\складского учета. За день до 10000 проводок. Одна потеряется — жопа, баланс не сойдется, как потом найти какая потерялась или как восстановить?
А если все это еще сложить с отсутствием механизмов конкурентного доступа, то целостность данных можно обеспечить только когда связанные данные помещаются в один документ, а это крайне сложно в том же учете.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[35]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 09:21
Оценка:
Здравствуйте, Enomay, Вы писали:

_AB>>Не знаю, в чем проблема. Пытаюсь выяснить. Например, как мы будем хранить информацию о счетах? О транзакциях?


E>В виде документов


А поподробнее можно? Есть у нас, допустим, 1 000 000 счетов и, ну пусть будет 8 000 000 транзакций в сутки с ними и между ними. Как мы всё это будем хранить на логическом и физическом уровне?


E>>>отчеты удобнее строить сиквелом

_AB>>Дело только в "удобнее писать", или в чем-то еще, наподобие "сложнее собрать данные" и т.п.?

E>имхо, на sql проще написать логику агрегации большого объема данных, и сиквел скорее всего с этим справится лучше, нежели кастомное решение, в большинстве случаев.


Т.е., проблем с тем, чтобы собрать согласованные на один момент времени данные, проблем не будет, верно?
Re[34]: SQL vs NOSQL
От: Cyberax Марс  
Дата: 23.04.12 09:23
Оценка:
Здравствуйте, gandjustas, Вы писали:

E>>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса

G>Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью?
Не надо бредить. У большинства NoSQL есть гарантия атомарности и durability для отдельной записи (хотя она часто тоже отключаема) на отдельном узле.

Ты путаешь с гарантией глобальной атомарности и консистентности.
Sapienti sat!
Re[34]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 09:27
Оценка: -1
E>>Ну по вопросу скорости ты уже раз сфейлился.
G>В смыссе сфейлился? MS SQL Express без оптимизаций выдал примерно столько же сколько mongodb.

да ну? такой же результат выдало при сериализации объектов на сторону .NET. без него результат 2-3ms. это на стороне сервера.
у тебя в сиквеле результат исключительно на стороне сервера замерялся. и он более 250ms.
сиквел слил.

G>А ты не привел скрипт для воспроизведения.


да ну? внимательней ответы смотри. во-вторых, не ясно что в данном контексте подразумевается под скриптом.

E>>Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.

G>Давай, нивопрос. Предлагай сценарий.

мне зачем? я уверен в скорости. тебе ж нужны доказательства.

E>>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса

G>Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью? И как бороться в случае если это произойдет? Выгодно в этом плане только raven отличается, у него честный acid есть.

а если в датацентр ядерная бомба попадет, то ваще капец.

G>Взять например сценарий бухгалтерского\складского учета. За день до 10000 проводок. Одна потеряется — жопа, баланс не сойдется, как потом найти какая потерялась или как восстановить?


и чо, таки теряются? не верю. жалобы есть?

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


конкуретный доступ реализуется по сути так же как в сиквеле.
Re[35]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 09:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


E>>>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса

G>>Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью?
C>Не надо бредить. У большинства NoSQL есть гарантия атомарности и durability для отдельной записи (хотя она часто тоже отключаема) на отдельном узле.
MongoDB — только появилось в 2.0 в x64, raven — чуть раньше, redis до сих пор не durable, cassandra вроде поддерживает durable, то там проблемы с consistency возникают.

C>Ты путаешь с гарантией глобальной атомарности и консистентности.

Нет, как раз не путаю.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[35]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 09:37
Оценка:
Здравствуйте, Enomay, Вы писали:

E>>>Ну по вопросу скорости ты уже раз сфейлился.

G>>В смыссе сфейлился? MS SQL Express без оптимизаций выдал примерно столько же сколько mongodb.

E>да ну? такой же результат выдало при сериализации объектов на сторону .NET. без него результат 2-3ms. это на стороне сервера.

E>у тебя в сиквеле результат исключительно на стороне сервера замерялся. и он более 250ms.
Да, именно это и замерялось

E>сиквел слил.

Повторение чуши доказательством не является.

G>>А ты не привел скрипт для воспроизведения.

E>да ну? внимательней ответы смотри. во-вторых, не ясно что в данном контексте подразумевается под скриптом.
Приведи полный скрипт в ответе тут.


E>>>Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.

G>>Давай, нивопрос. Предлагай сценарий.
E>мне зачем? я уверен в скорости. тебе ж нужны доказательства.

Эпично слил, нет слов.

E>>>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса

G>>Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью? И как бороться в случае если это произойдет? Выгодно в этом плане только raven отличается, у него честный acid есть.
E>а если в датацентр ядерная бомба попадет, то ваще капец.
Ага, только вероятность с ядерной бомбой равна нуля в любом обозримом будущем. А отказы ПО, сетей, питания и дисков случаются чаще, чем тебе хотелось бы.

G>>Взять например сценарий бухгалтерского\складского учета. За день до 10000 проводок. Одна потеряется — жопа, баланс не сойдется, как потом найти какая потерялась или как восстановить?

E>и чо, таки теряются? не верю. жалобы есть?
Жалоб нет, потому что в здравом уме никто бухгалтерию на nosql не делает. А вообще потери случаются, может интернеты почитать.

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

E>конкуретный доступ реализуется по сути так же как в сиквеле.

Ну давай расскажи как конкурентный доступ в SQL делается и как в любом движке на твое усмотрение.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[36]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 09:48
Оценка:
E>>да ну? такой же результат выдало при сериализации объектов на сторону .NET. без него результат 2-3ms. это на стороне сервера.
E>>у тебя в сиквеле результат исключительно на стороне сервера замерялся. и он более 250ms.
G>Да, именно это и замерялось

E>>сиквел слил.

G>Повторение чуши доказательством не является.

тоесть, 300+ms против 2-3ms в RavenDB сливом не является? Да ты парень болван

G>>>А ты не привел скрипт для воспроизведения.

E>>да ну? внимательней ответы смотри. во-вторых, не ясно что в данном контексте подразумевается под скриптом.
G>Приведи полный скрипт в ответе тут.

Я там привел. Тебе надо — иди возьми.

E>>>>Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.

G>>>Давай, нивопрос. Предлагай сценарий.
E>>мне зачем? я уверен в скорости. тебе ж нужны доказательства.
G>
G>Эпично слил, нет слов.

ты и правда болван


E>>а если в датацентр ядерная бомба попадет, то ваще капец.

G>Ага, только вероятность с ядерной бомбой равна нуля в любом обозримом будущем. А отказы ПО, сетей, питания и дисков случаются чаще, чем тебе хотелось бы.

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

G>>>Взять например сценарий бухгалтерского\складского учета. За день до 10000 проводок. Одна потеряется — жопа, баланс не сойдется, как потом найти какая потерялась или как восстановить?

E>>и чо, таки теряются? не верю. жалобы есть?
G>Жалоб нет, потому что в здравом уме никто бухгалтерию на nosql не делает. А вообще потери случаются, может интернеты почитать.

как говорил мой хороший друг, Станиславский — не верю!

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

E>>конкуретный доступ реализуется по сути так же как в сиквеле.
G>
G>Ну давай расскажи как конкурентный доступ в SQL делается и как в любом движке на твое усмотрение.

мне это зачем?
Re[37]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 09:59
Оценка:
Здравствуйте, Enomay, Вы писали:

E>>>да ну? такой же результат выдало при сериализации объектов на сторону .NET. без него результат 2-3ms. это на стороне сервера.

E>>>у тебя в сиквеле результат исключительно на стороне сервера замерялся. и он более 250ms.
G>>Да, именно это и замерялось

E>>>сиквел слил.

G>>Повторение чуши доказательством не является.

E>тоесть, 300+ms против 2-3ms в RavenDB сливом не является?

Приведи скрипт для воспроизведения, вместе с генерацией тестовых данных.


E>Да ты парень болван

Отойди от зеркала.

G>>>>А ты не привел скрипт для воспроизведения.

E>>>да ну? внимательней ответы смотри. во-вторых, не ясно что в данном контексте подразумевается под скриптом.
G>>Приведи полный скрипт в ответе тут.

E>Я там привел. Тебе надо — иди возьми.

Я "там" не видел, приведи еще раз.

E>>>>>Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.

G>>>>Давай, нивопрос. Предлагай сценарий.
E>>>мне зачем? я уверен в скорости. тебе ж нужны доказательства.
G>>
G>>Эпично слил, нет слов.

E>ты и правда болван

Яж говорю, отойди от зеркала.


E>>>а если в датацентр ядерная бомба попадет, то ваще капец.

G>>Ага, только вероятность с ядерной бомбой равна нуля в любом обозримом будущем. А отказы ПО, сетей, питания и дисков случаются чаще, чем тебе хотелось бы.

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


G>>>>Взять например сценарий бухгалтерского\складского учета. За день до 10000 проводок. Одна потеряется — жопа, баланс не сойдется, как потом найти какая потерялась или как восстановить?

E>>>и чо, таки теряются? не верю. жалобы есть?
G>>Жалоб нет, потому что в здравом уме никто бухгалтерию на nosql не делает. А вообще потери случаются, может интернеты почитать.
E>как говорил мой хороший друг, Станиславский — не верю!
Нивопрос, покажи кто пишет.

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

E>>>конкуретный доступ реализуется по сути так же как в сиквеле.
G>>
G>>Ну давай расскажи как конкурентный доступ в SQL делается и как в любом движке на твое усмотрение.
E>мне это зачем?
См выделенное. Есть подозрение что ты не понимаешь как разруливается конкурентный доступ.
Ты кстати уже показал полную безграмотность на тему балансировки нагрузки SQL, так что рекомендую сначала изучать, а потом писать.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[8]: SQL vs NOSQL
От: Дельгядо Филипп Россия  
Дата: 23.04.12 11:20
Оценка: +1
Здравствуйте, a_g_99, Вы писали:

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

_AB>>С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях?
__>А как вы еще планируете ее использовать при наложенных ограничениях на процессор/диск/память? В live applications?

Хм, для весьма заметной части приложений этого достаточно. Собственно, не так уж и много реальных систем, где не хватит бесплатного Оракла или, тем более, DB2 UDB (где нет ограничений на объем БД).


_AB>>Кроме того, PosеgreSQL, Firebird бесплатны со всех сторон, например.

__>Про PostgreSQL я писал (Ingres) — не вижу перспектив данной системы, исключая БД от EnterpriseDB (и то надо думать ), но она платная.

Э, и почему это у самой лучшей из бесплатных СУБД нет перспектив? Почему у какого-нибудь mongo есть, а у от Postgre — нет? На основании чего сделан такой вывод?

__>Приводите реальные примеры. Примеры типа — внедрение блогоплатформы в Бангладеше руками индейцов на платформе Firebird, о которой я читал в 199N году не подходит.


Ну, Postgre используется почти во всех крупных компаниях (правда, там и MySQL используется, что мало о чем говорит).
IBM DB2 в бесплатной редакции, например, стоит в крупнейшей российской букмекерской компании (не говоря уж о многих других местах). Ну, может, поддержку купили — не в курсе...
Бесплатного Оракла в продакшне не видел.
Бесплатные версии MS SQL — в огромной куче корпоративных приложений, но они embedded, так что снаружи не видно
Re[5]: SQL vs NOSQL
От: a_g_99 США http://www.hooli.xyz/
Дата: 23.04.12 11:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Вообще-то NoSQL выигрывает в скорости за счет тотального кеширования и отсуствия механизмов разруливания конкуретного доступа.

+ разбор и нормализация SQL и подготовка плана исполнения (хорошо написано здесь про MySQL YOSHINORI MATSUNOBU)

G>Индексы в NoSQL зачастую крайне неэффективны, у того же couchDB используется lucene куда помещается ВСЕ, объем индекса иногда превосходит объем данных в несколько раз.

А чем по вашему индексы noSQL отличаются от индексов RDBMS ? Физически эффективность "простого" индексирования будет определяться data structure и алгоритмом его обхода. И кстати что же представляет собой кластерный индекс в mssql на уровне leaf_lavel по вашему? Про более сложные модели индексирования я не говорю, думаю сейчас это бессмысленно.

G>Пока все умещается в ОП — работает прекрасно, как только перестает влезать, то начинается веселье. Особенно на нетривиальных предикатах. С записью вообще песня.

Это неверно. Здесь вообще обратная ситуация — в зависимости от реализации любой БД все работает либо хорошо либо плохо. Конечно, в rdbms большой тройки работа с дисковой подсистемой реализована на высшем уровне с возможностью многократного масштабирования. Но что мешает правильно организовать такие механизмы и в noSQL (ответ ничего и насколько понимаю это сделано в Google)?
Опять же rdbms — не только работа с диском (как многие тут утверждают). Вокруг них есть целые экосистемы IMDB, которые могут эффективно увеличить производительность в 5-7 раз (TimesTen, solidDB; я лично использовал solidDB и был очень доволен). Так что говорить что rdbms это в основном диск, а noSQL только память неправильно.
>Большинство субд используют низкогранулярные блокировки при записи, вплоть до блокировки целого сервера или базы. При большом объеме начинает работать медленно, nosql возвращает управление раньше чем происходит реально запись, что в отсутствии журналирования делает базу крайне неустойчивой.
Тут я не понял. В случае noSQL процесс управления блокировками ложится на пользователя в объектной модели/коде, он либо сам реализует механизмы с помощью API или использует/дополняет уже готовые механизмы. Наборы lock objects у всех разные — от [db, row] до похожих на mssql [db, page, index, row]. Если требуется эскалация производится вручную в зависимости мнения программиста, когда это нужно сделать (все как обычно )
>При большом объеме начинает работать медленно, nosql возвращает управление раньше чем происходит реально запись
Это про транзакции. Напр. в BerkleyDB они реализованы хорошо и такого там не происходит. К делу это отношения не имеет .
>в отсутствии журналирования делает базу крайне неустойчивой
Такие фичи как (качественная система журналирования) правило продаются за деньги . Не уровень open source noSQL.

G>Индексы в большинстве случаев пересчитываются асинхронно, что также приводит к тормозам или несогласованному поведению.

Приведите пример такого поведения. Проблема в том что в noSQL вообще редко что происходит "асинхронно", потому как там обычно голая data structure + простой api layer сверху & несколько major features. Пользователь все должен кодить ручками (в этом и смысл отсутствия sql)

G>На небольших проектах с низкой нагрузкой еще можно закрывать глаза на такое, на серезных, нагруженных проектах с большим объемом баз — уже так не выйдет.

G>Тогда начинается — шардинг, репликация итп И получается что куча железа, сетевая инфрастуктура и прочие "радости" выходят дороже чем поставить промышленную БД.
Это верно. Здесь часто основная идея — избежать vendor lock-in (что характерно для мейджоров, которые не имеют собственных БД — напр. Гоголь, Facebook, Inv. Banking) даже в убыток себе. И это правильно с точки зрения бизнеса.

G>Это вообще не понял, кластеризацию нельзя на промышленных БД реализовать?

G>Кстати сколько nosql баз поддерживают стандартный для windows NLB или умеют хоститься на IIS? Вот тебе и enterprise ready
Тут вас сильно занесло . БД не могут "хоститься на IIS", и это хорошо . Да и зачем им это ?

G>Если курсовая, ты можешь бесплатно по dreamspark юзать enterprise версию sql server.

Или включить мозги и сделать что-то самостоятельно. Или это не MSFT way ?
Re[9]: SQL vs NOSQL
От: a_g_99 США http://www.hooli.xyz/
Дата: 23.04.12 12:33
Оценка:
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Хм, для весьма заметной части приложений этого достаточно. Собственно, не так уж и много реальных систем, где не хватит бесплатного Оракла или, тем более, DB2 UDB (где нет ограничений на объем БД).
Не соглашусь. К сожалению, в моем случае всегда "не хватало". Впрочем, опыт у каждого разный

ДФ>Э, и почему это у самой лучшей из бесплатных СУБД нет перспектив? Почему у какого-нибудь mongo есть, а у от Postgre — нет? На основании чего сделан такой вывод?

Работал с ней в ранние годы, если очень коротко — медленная с vldb, слабый оптимизатор, мало enterprise-фич, саппорт стоит конских денег.

А что mongo вдруг резко стала реляционной?
Re[10]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 12:45
Оценка:
Здравствуйте, a_g_99, Вы писали:

__>Не соглашусь. К сожалению, в моем случае всегда "не хватало". Впрочем, опыт у каждого разный

С какими работали и на каких сценариях?

__>Работал с ней в ранние годы, если очень коротко — медленная с vldb, слабый оптимизатор, мало enterprise-фич, саппорт стоит конских денег.

С какими версиями?
Re[3]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.04.12 13:28
Оценка:
Здравствуйте, Ромашка, Вы писали:


Р>О... А в чем он вообще имеет преимущества, кроме [полу]объектной модели?


Например Google Megastore. Репликация между географически распределёнными датацентрами с приемлимой скоростью работы. Можно сравнить с возможностями того, что начал продавать амазон для mysql после полного даунтайма одного своего датацентра.

Кстати, на этот счет есть статейка: Life beyond Distributed Transactions — там вывод, если вам нужны гарантии целостности внутри определённой группы данных (т.е. обеспечить ACID), то, вам прийдётся сделать так, что эта группа влазила на один инстанс БД (одна машина или что-то a-la RAC) потому, что обеспечивать синхронизацию между разными удалёнными инстансами дорого. По-этому оптимальная стратегия — определить группу в рамках которой acid гарантируется. В то же время между групами консистентность не обеспечивается. Именно по такой схеме и работает Google Megastore.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[9]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.04.12 13:39
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>Для приложений, которые не испытывают высокой нагрузки. Скажем, простенький сайт типа блога с кол-вом посещений до 10 000 в сутки с пиком в 1 500 в час Express редакция вполне себе потянет.

_AB>Ну, или для простых конфигураций 1С с небольшим количеством клиентов.
_AB>Для небольших, но высоконагруженных проектов с размером БД не выше 50 ГБ вполне себе неплохое решение, ИМХО.

Всё так. В теории. А на практике приходится людям какие-то `tag engine` городить. Это к слову о SO, как примеру pure RDBMS.

При том если даже лимита производительности нет, то всё равно возникает куча проблем, экспертиза по решению которых уже давно наработана (потому многие их вообще проблемами не считают). Но "механичность" их решения делает эти проблемы еще более идиотскими по сути.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[5]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.04.12 13:40
Оценка:
Здравствуйте, Дельгядо Филипп, Вы писали:

M>>О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается

ДФ>Ну, на практике графов, не влезающих в память довольно мало, делать для них движки смысла нет, проще писать конкретное решение. А если влезают — то и не шибко важно, как его хранить в persistance
ДФ>Ну, может, что-нибудь из решений для хранения социальных графов для сетей — и выйдет в open-source...

https://github.com/twitter/flockdb
Твоё мнение, это SQL или noSQL?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[9]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.04.12 13:43
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>2. Это личное мнение. Я, например, не вижу перспектив noSQL, как замены SQL и что?


это не замена SQL. Его нужна туда где SQL нафиг не нужен. SQL останется там где без него никак — внизу. Что б сверху его не видно и неслышно было.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[10]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 13:43
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Всё так. В теории. А на практике приходится людям какие-то `tag engine` городить. Это к слову о SO, как примеру pure RDBMS.

А нельзя ли не давать ссылок на сомнительные ресурсы, требующие регистрации? Тем более, что насколько я понимаю, этот ресурс насквозь вторичен и найти первоисточник не будет проблемой.
Re[11]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.04.12 13:46
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>>Всё так. В теории. А на практике приходится людям какие-то `tag engine` городить. Это к слову о SO, как примеру pure RDBMS.

_AB>А нельзя ли не давать ссылок на сомнительные ресурсы, требующие регистрации? Тем более, что насколько я понимаю, этот ресурс насквозь вторичен и найти первоисточник не будет проблемой.

О, мне стыдно — накосячил. Ссылка вот: http://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 13:55
Оценка: +1
Здравствуйте, a_g_99, Вы писали:

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


G>>Вообще-то NoSQL выигрывает в скорости за счет тотального кеширования и отсуствия механизмов разруливания конкуретного доступа.

__>+ разбор и нормализация SQL и подготовка плана исполнения (хорошо написано здесь про MySQL YOSHINORI MATSUNOBU)
Это как раз мелочи, потому что планы кешируются.

G>>Индексы в NoSQL зачастую крайне неэффективны, у того же couchDB используется lucene куда помещается ВСЕ, объем индекса иногда превосходит объем данных в несколько раз.

__>А чем по вашему индексы noSQL отличаются от индексов RDBMS ?
Как минимум тем что:
1) РСУБД имеет регулярную структуру. Например нет множественных значений.
2) Индекс РСУБД оптимизирован по размеру.
3) Операции в СУБД отличаются, поэтому и индексы отличаются.

__>Физически эффективность "простого" индексирования будет определяться data structure и алгоритмом его обхода. И кстати что же представляет собой кластерный индекс в mssql на уровне leaf_lavel по вашему? Про более сложные модели индексирования я не говорю, думаю сейчас это бессмысленно.

Эффективность индекса в первую очередь зависит от того как он используется. Обсуждать структуру бессмысленно без паттернов использования.

G>>Пока все умещается в ОП — работает прекрасно, как только перестает влезать, то начинается веселье. Особенно на нетривиальных предикатах. С записью вообще песня.

__>Это неверно. Здесь вообще обратная ситуация — в зависимости от реализации любой БД все работает либо хорошо либо плохо. Конечно, в rdbms большой тройки работа с дисковой подсистемой реализована на высшем уровне с возможностью многократного масштабирования. Но что мешает правильно организовать такие механизмы и в noSQL (ответ ничего и насколько понимаю это сделано в Google)?
Действительно что мешает? Но пока в mongodb (самая массовая nosql на сегодня) — writelock на сервер.
Так что "неверно" это только теоретически.

__>Опять же rdbms — не только работа с диском (как многие тут утверждают). Вокруг них есть целые экосистемы IMDB, которые могут эффективно увеличить производительность в 5-7 раз (TimesTen, solidDB; я лично использовал solidDB и был очень доволен). Так что говорить что rdbms это в основном диск, а noSQL только память неправильно.

Я не говорил что "только", но основной упор именно на это. Поэтому SQL хорошо по размеру масштабируется, а nosql по ресурсам.
Но сделать над sql слой с распределенным кешем несложно, а вот заставить nosql работать при высокой нагрузке при больших объемах — сложно.

__>Тут я не понял. В случае noSQL процесс управления блокировками ложится на пользователя в объектной модели/коде, он либо сам реализует механизмы с помощью API или использует/дополняет уже готовые механизмы. Наборы lock objects у всех разные — от [db, row] до похожих на mssql [db, page, index, row]. Если требуется эскалация производится вручную в зависимости мнения программиста, когда это нужно сделать (все как обычно )

Ручное управление блокировками — жопа, 100% дедлоки и тормоза. Кайф РСУБД, что тебе достаточно указать уровень изоляции и остальное база делает сама очень эффективным способом.
Ручным управлением можно сделать и быстрее, но только в теории.

Кстати я вообще сомневаюсь что в распределенной среде управление блокировками будет хоть как-то работать (когда много серверов с БД и много frontend серверов).

>>При большом объеме начинает работать медленно, nosql возвращает управление раньше чем происходит реально запись

__>Это про транзакции. Напр. в BerkleyDB они реализованы хорошо и такого там не происходит. К делу это отношения не имеет .
>>в отсутствии журналирования делает базу крайне неустойчивой
__>Такие фичи как (качественная система журналирования) правило продаются за деньги . Не уровень open source noSQL.

Во всех взрослых РСУБД оно есть, в том числе в бесплатных версиях.

G>>Индексы в большинстве случаев пересчитываются асинхронно, что также приводит к тормозам или несогласованному поведению.

__>Приведите пример такого поведения. Проблема в том что в noSQL вообще редко что происходит "асинхронно", потому как там обычно голая data structure + простой api layer сверху & несколько major features. Пользователь все должен кодить ручками (в этом и смысл отсутствия sql)

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

G>>На небольших проектах с низкой нагрузкой еще можно закрывать глаза на такое, на серезных, нагруженных проектах с большим объемом баз — уже так не выйдет.

G>>Тогда начинается — шардинг, репликация итп И получается что куча железа, сетевая инфрастуктура и прочие "радости" выходят дороже чем поставить промышленную БД.
__>Это верно. Здесь часто основная идея — избежать vendor lock-in (что характерно для мейджоров, которые не имеют собственных БД — напр. Гоголь, Facebook, Inv. Banking) даже в убыток себе. И это правильно с точки зрения бизнеса.
Это бредятина, которую сторонники опенсорса рассказывают. vendor lock-in в первую очередь происходит от приложений, а не от БД. Как ни крути ты не заставишь 1С работать на nosql.
В банках вообще поголовно MS SQL \ oracle, за такие бабки, что не снилось и никто не думает о "избежать vendor lock-in".

G>>Это вообще не понял, кластеризацию нельзя на промышленных БД реализовать?

G>>Кстати сколько nosql баз поддерживают стандартный для windows NLB или умеют хоститься на IIS? Вот тебе и enterprise ready
__>Тут вас сильно занесло . БД не могут "хоститься на IIS", и это хорошо . Да и зачем им это ?
А то что многие по веб-протоколам работают, а IIS имеет хороший пайплайн по обработке запросов, авторизации, кешированию и прочим радостям. Да и не-веб протоколы тоже поддерживаются.

G>>Если курсовая, ты можешь бесплатно по dreamspark юзать enterprise версию sql server.

__>Или включить мозги и сделать что-то самостоятельно. Или это не MSFT way ?
Если есть цель сделать самостоятельно, то можно сделать. Если такой цели нет, то использовать что дают.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[33]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.04.12 15:33
Оценка:
Здравствуйте, Enomay, Вы писали:
E>Ну по вопросу скорости ты уже раз сфейлился. Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.
E>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса
Вот эти две фразы — они как одновременно работают?
Я к тому, что БД упирается в IOPS дисковой системы. Вот у нас, допустим, есть RDBMS. Что она делает при commit, мы хорошо знаем — в redo log выполняется flush. Поэтому делать коммитов в секунду больше, чем диск умеет IOPS, принципиально не получится. И это RDBMS ещё экономит на записи, т.к. откладывает запись собственно изменений данных. Если во время коммита не произошёл Flush на диск, то ни о какой durability говорить смысла нет.
А теперь расскажите мне, благодаря какой магии NoSQL обойдут это ограничение?
Я лично вижу только один способ — отказаться от flush при commit, в надежде, что между commit и следующим flush всё будет хорошо. Т.е. как раз отсутствие гарантии при записи.
Если вы знаете какой-то другой способ — молю, поделитесь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[36]: SQL vs NOSQL
От: Cyberax Марс  
Дата: 23.04.12 15:44
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>Не надо бредить. У большинства NoSQL есть гарантия атомарности и durability для отдельной записи (хотя она часто тоже отключаема) на отдельном узле.

G>MongoDB — только появилось в 2.0 в x64, raven — чуть раньше,
Лень смотреть, но он точно давно durable.

G>redis до сих пор не durable

Snapshotting is not very durable. If your computer running Redis stops, your power line fails, or you accidentally kill -9 your instance, the latest data written on Redis will get lost. While this may not be a big deal for some applications, there are use cases for full durability, and in these cases Redis was not a viable option.
The append-only file is an alternative, fully-durable strategy for Redis. It became available in version 1.1.

http://antirez.com/post/redis-persistence-demystified.html

Опционально durable c давних времён.

G>cassandra вроде поддерживает durable,

Cassandra's example configuration shows CommitLogSync set to periodic, meaning that we sync the commitlog every CommitLogSyncPeriodInMS ms, so you can potentially lose up to that much data in a crash. This is decently performant even with the commitlog shared with data directories. You can also select "batch" mode, where Cassandra will guarantee that it syncs before acknowledging writes, i.e., fully durable mode, in batches of CommitLogSyncBatchWindowInMS. To use this mode we strongly recommend splitting your commitlog onto a separate device, as described above.

Тоже опционально durable.

В общем, не-durable (хотя бы и опционально) БД надо ещё поискать.

G>то там проблемы с consistency возникают.

Ну так. NoSQL типично не имеет гарантий глобальной consistency вообще.
Sapienti sat!
Re[10]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 15:59
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Всё так. В теории. А на практике приходится людям какие-то `tag engine` городить. Это к слову о SO, как примеру pure RDBMS.


1. Stack Overflow совсем не небольшой, хотя и высоконагруженный проект.

2. А чем не pure? Данные хранятся в RDBMS, просто кешируются для производительности. Насколько я понял, кэш обновляется раз в минуту как раз данными из БД. Вполне себе нормальное явление, совсем не редкое в 3-х звенной архитектуре.

ANS>При том если даже лимита производительности нет, то всё равно возникает куча проблем, экспертиза по решению которых уже давно наработана (потому многие их вообще проблемами не считают). Но "механичность" их решения делает эти проблемы еще более идиотскими по сути.


С каких пор наличие отработанных и известных решений известных проблем делает проблемы идиотскими? Примерчик можно такой идиотской проблемы, чтобы понять о чем речь?
Re[37]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 16:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать.


А они все по умолчанию не-durable случайно не потому, что иначе начнут проигрывать в производительности РСУБД? Есть какое-нибудь сравнение на эту тему? Заранее спасибо, если есть.
Re[11]: SQL vs NOSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.04.12 16:05
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>2. А чем не pure? Данные хранятся в RDBMS, просто кешируются для производительности. Насколько я понял, кэш обновляется раз в минуту как раз данными из БД. Вполне себе нормальное явление, совсем не редкое в 3-х звенной архитектуре.


тогда и к тебе вопрос. FlockDB ( https://github.com/twitter/flockdb ) работает поверх MySql. Это как SQL или noSql?

ANS>>При том если даже лимита производительности нет, то всё равно возникает куча проблем, экспертиза по решению которых уже давно наработана (потому многие их вообще проблемами не считают). Но "механичность" их решения делает эти проблемы еще более идиотскими по сути.


_AB>С каких пор наличие отработанных и известных решений известных проблем делает проблемы идиотскими? Примерчик можно такой идиотской проблемы, чтобы понять о чем речь?


дедлок.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[28]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 16:13
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ссылки? В микроскоп не видно.


Я вроде бы уже кидал здесь эту http://www.mongodb.org/display/DOCS/Production+Deployments ссылку. Неужели ни одного знакомого имени там нет? )))

И это только один из многих nosql движков. Тут http://nosql-database.org можно увидеть их общий список.

G>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.


Уже даже по ссылке выше видно что это не так.

G>Фигня какая-то. Можно одну базу на 150 гб поднять. А federations по сути создает базы. Так что фактически предел = 150(максимальное количество federations) * 150(размер БД) = 22,5 ТБ и стоить это все будет $34к (это очень мало)


Ааа ну значит 150 гигов уже, а не 50. Возможно я читал раньше или же читал про конкретное реальное облако. В общем помню что была цифра в 50 гигов.

Что касается federation, то вообще то это же у нас и есть классический шардинг) Такой вот велосипедик от MS для sql. Только он работает не автоматически, как и все sql решения. И работает только под их облако.

Но кстати показательно что уже и MS начинает думать в сторону нормальных средств масштабирования, а не полагаться на замечательное "вертикальное масштабирование".

G>"облачный" подход с оплатой за использование и разделением compute и storage делает масштабирование гораздо выгоднее.


Сферовакуумный разговор без перехода к конкретной задаче и конкретным хостерам/облакам. И не вижу смысла вообще это обсуждать здесь, т.к. достаточно чуть поменяться ценам на рынке и всё переиграется.
Re[12]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 16:19
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>тогда и к тебе вопрос. FlockDB ( https://github.com/twitter/flockdb ) работает поверх MySql. Это как SQL или noSql?

Вопрос не в этом. Вопрос в том, СУБД это, или нет?

ANS>дедлок.

Можно раскрыть тему? В том смысле, что наличие решения делает эту проблему "еще более идиотской".
Re[30]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 16:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я вас разочарую. В перформансе (любой) СУБД главную роль играет не коробка, а дисковая подсистема. Эти чудесные "ProServer" оборудованы парой 7200rpm дисков. У них крайне низкий IOPS, и улучшить это невозможно. Именно поэтому розничная цена такого сервера — примерно штука баксов, т.е. дешевле чем игровой десктоп. То есть мы имеем соотношение аренда:покупка примерно 1:10, как и должно быть.

S>Теперь, допустим, мы упёрлись в предел вашего маленького сервера. Скажем, я хочу улучшить его суммарные 6Gbps дисковой скорости в 12 раз.
S>Если я поставлю 12 таких "маленьких серверов", то буду платить $840 в месяц + $2400 единовременных расходов.
S>А если я куплю один Dell PowerEdge515 c 12ю 10к-rpm 2.5" винтами, то отдам $8511. Т.е. лишние затраты составят $6000, и окупятся за 8 месяцев.
S>А ведь этот сервер можно и в аренду взять! В сети нет готовых предложений, но ставка аренды обычно составляет примерно те же 10% покупной цены. Так что, как видите, не стоит переоценивать преимущества маленьких коробок.

Я там по ссылкам на Dell PowerEdge515 не смотрел... Но в эти $8511 входит оплата места в дата-центре с оплатой трафика и саппорта по серверу? А то там на colocation и поддержку обычно цены тоже приличные. )
Re[14]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 16:34
Оценка:
Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>P.S. Практически все прелести mongo (включая шардинг) делаются где-то за день-два на любой реляционной базе (оставляя в живых ACID, но прощаясь с гарантиями целостности, разумеется).


Ну не за день-два, но действительно делаются. Если использовать sql базу в режиме ключ-значение. Однако быстродействие будет несравнимо.
Re[38]: SQL vs NOSQL
От: Cyberax Марс  
Дата: 23.04.12 16:41
Оценка:
Здравствуйте, _ABC_, Вы писали:

C>>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать.

_AB>А они все по умолчанию не-durable случайно не потому, что иначе начнут проигрывать в производительности РСУБД? Есть какое-нибудь сравнение на эту тему? Заранее спасибо, если есть.
Зависит. Обычно NoSQL всё равно быстрее.
Sapienti sat!
Re[5]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 16:42
Оценка:
Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>Более того, требования у TokyoCabinet жестче, так как требуется *nix, а Oracle можно запустить и под Windows.


TokyoCabinet — это старая реализация. Kyoto Cabinet работает лучше и на windows в том числе.

Однако я не вижу смысла обсуждать такие решения вообще. На встраиваемых базах преимущества nosql увидеть очень трудно. Более того, для простых задач (где sql не нужен) и в рамках встроенной базы проще вообще делать свой формат файла и не думать о каких-то nosql движках.

ДФ>Ну и, конечно, есть и opensource РСУБД и встраиваемые РСУБД — на любой вкус.


Да, sqlite отличная вещь. Пользуемся.
Re[5]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 16:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это верно. Область применения SQL — простые проекты, где нет конкурентного доступа и большого объема данных , типа embed или десктоп приложения.


Бред какой. Как раз в этой области увидеть преимущества nosql практически невозможно. Тут логичнее использовать sqlite или вообще просто свой формат файла.
Re[32]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 16:49
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>Т.е. я могу уложить биллинг, бухгалтерию, или другую задачу финансового учета в NoSQL и он будет работать так же надежно как с СУБД, но быстрее?


http://www.mongodb.org/display/DOCS/Production+Deployments тут можно увидеть не только применения nosql в системах электронной комерции, но и ссылки на статьи обосновывающие преимущество таких решений.

P.S. Кидаю эту ссылку уже наверное 3-ий раз. Так же как и до этого приходилось повторять мысли по несколько раз. Сколько у нас тут вообще писателей-не-читателей? )
Re[38]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 16:54
Оценка:
E>>тоесть, 300+ms против 2-3ms в RavenDB сливом не является?
G>Приведи скрипт для воспроизведения, вместе с генерацией тестовых данных.

class Program
{
private static IDocumentSession session;

static void Main(string[] args)
{
var documentStore = new DocumentStore { Url = "http://localhost:8080/" }.Initialize();

session = documentStore.OpenSession("testDB");

//FillDB(); return;

var timer = new Stopwatch();

timer.Start();

var result = session.Query<Post>().Where(p => p.Tags.Any(t => t == "Tag 51") && p.Tags.Any(t => t == "Tag 79") && p.Tags.Any(t => t == "Tag 69")).ToArray();

timer.Stop();

foreach (var post in result)
{
Console.WriteLine(post);
}

Console.WriteLine("Count: " + result.Count());
Console.WriteLine(timer.ElapsedMilliseconds);

Console.ReadLine();
}

public static void FillDB()
{
const int maxTags = 100;
const int tagsPerPost = 10;
const int postCount = 100000;

var tags = Enumerable.Range(1, maxTags).Select(i => "Tag " + i).ToArray();

var rnd = new Random();

Func<string[]> getRandomTags = () =>
{
var result = new string[tagsPerPost];

for (int i = 0; i < tagsPerPost; i++) result[i] = tags[rnd.Next(tags.Length — 1)];

return result;
};

for (int i=1; i<=postCount; i++) session.Store(new Post{ Text = "Post " + i, Tags = getRandomTags()});

session.SaveChanges();
}
}

public class Post
{
public string Id { get; set; }
public string Text { get; set; }
public string[] Tags { get; set; }

public override string ToString()
{
return string.Format("Post id: {0}", Id);
}
}


G>>>Эпично слил, нет слов.

E>>ты и правда болван
G>Яж говорю, отойди от зеркала.

то есть ты таки слил? ок.

G>>>Жалоб нет, потому что в здравом уме никто бухгалтерию на nosql не делает. А вообще потери случаются, может интернеты почитать.

E>>как говорил мой хороший друг, Станиславский — не верю!
G>Нивопрос, покажи кто пишет.

тебе приводили аргументы, ты их игноришь.

G>>>Ну давай расскажи как конкурентный доступ в SQL делается и как в любом движке на твое усмотрение.

E>>мне это зачем?
G>См выделенное. Есть подозрение что ты не понимаешь как разруливается конкурентный доступ.

ну давай ты рапишешь что ты хочешь получить, а мы потом подумаем как это можно сделать. а главное, нужно ли.
Re[34]: SQL vs NOSQL
От: Enomay  
Дата: 23.04.12 16:58
Оценка: :))) :)
S>Если вы знаете какой-то другой способ — молю, поделитесь.

я не знаю как в какой бд оно реализовано.
сиквел помимо записи диск грузит еще кучей тасков. в nosql их как правило нет. потому оно и быстрее, что проще.
Re[7]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 17:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

__>>А чем по вашему индексы noSQL отличаются от индексов RDBMS ?

G>Как минимум тем что:
G>1) РСУБД имеет регулярную структуру. Например нет множественных значений.
G>2) Индекс РСУБД оптимизирован по размеру.
G>3) Операции в СУБД отличаются, поэтому и индексы отличаются.

Я понял, индексы в рсубд волшебные.

Только почему тогда наши совместные измерения показали прямо противоположный результат? )

G>Ручное управление блокировками — жопа, 100% дедлоки и тормоза. Кайф РСУБД, что тебе достаточно указать уровень изоляции и остальное база делает сама очень эффективным способом.

G>Ручным управлением можно сделать и быстрее, но только в теории.

Я согласен, что всяким недопрограммерам к nosql лучше не подходить. Хотя конечно современные инструменты типа mongodb сглаживают ситуацию, но всё же лучше не стоит. Пускай лучше sql запросы мастерят — умная база частенько исправляет их кривизну.

Но наличие плохих специалистов в мире не означает что не нужно развивать инструменты для профессионалов.
Re[31]: SQL vs NOSQL
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.04.12 17:23
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Я там по ссылкам на Dell PowerEdge515 не смотрел... Но в эти $8511 входит оплата места в дата-центре с оплатой трафика и саппорта по серверу? А то там на colocation и поддержку обычно цены тоже приличные. )

Нет, не входит — это я в магазине смотрел. Но цены на colocation для него, очевидно, будут раз в 10 ниже, чем для для 12 коробок. Это же 2U. Поймите, чудес не бывает. Да, наверное, реально топовый сервер (это, скажем, 40 ядер, 2TB памяти, секси дисковая подсистема) стоит не в 40 раз дороже этих унылых фуджитсу. Но до него типичному веб-проекту придётся расти лет десять.
А в целом, раздать, скажем, 48GB памяти, 16 ядер, и 16 винтов по 16 машинам никак не выйдет дешевле, чем поставить их все в одно шасси.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[33]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 17:24
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_AB>>Т.е. я могу уложить биллинг, бухгалтерию, или другую задачу финансового учета в NoSQL и он будет работать так же надежно как с СУБД, но быстрее?


_>http://www.mongodb.org/display/DOCS/Production+Deployments тут можно увидеть не только применения nosql в системах электронной комерции, но и ссылки на статьи обосновывающие преимущество таких решений.


И где там использование noSQL в "биллинге, бухгалтерии или другой задаче финансового учета"?

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

Нигде эта система не используется как инструмент управления денежными потоками. Или я не нашел?

Зато я нашел гениальную фразу об управлении финансами при помощи связки RDBMS и MongoDB: "we never really trust a value stored in Mongo". В той презентации, несмотря на кучу натяжек относительно RDBMS (вызванных очевидно тем, что под РСУБД авторами понимается исключительно mySQL), четко описанны границы применимости Mongo.

_>P.S. Кидаю эту ссылку уже наверное 3-ий раз. Так же как и до этого приходилось повторять мысли по несколько раз. Сколько у нас тут вообще писателей-не-читателей? )

Толку-то от того, что ты её кидаешь, если кинуто не в тему и не отвечает на поставленный вопрос? Хотя... Отвечает, но отрицательно.
Re[8]: SQL vs NOSQL
От: _ABC_  
Дата: 23.04.12 17:34
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Я согласен, что всяким недопрограммерам к nosql лучше не подходить. Хотя конечно современные инструменты типа mongodb сглаживают ситуацию, но всё же лучше не стоит. Пускай лучше sql запросы мастерят — умная база частенько исправляет их кривизну.


Только вот в статьях, хвалящих nosql я часто вижу запросы типа "смотрите, я всего то десяток cross join'ов на таблицы в 100500 записей накидал, чтобы выбрать одну запись и изменить её, а она тупит. И это при том, что я на каждую таблицу по 300 индексов создал. А если бы их не было, я бы вообще состарился к моменту завершения запроса...".

Умная база часто исправляет кривизну. Но когда не справляется, виноватой почему-то объявляется СУБД, а не "перепрограммер", неспособный понять простейших вещей.

_>Но наличие плохих специалистов в мире не означает что не нужно развивать инструменты для профессионалов.

Согласен. Пусть РСУБД развиваются.
Re[37]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 17:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

G>>redis до сих пор не durable

C>Опционально durable c давних времён.

Append-only это не то что можно в конфиге включить, это требует переделки приложения.


C>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать.

Ну да, только если включить durable начинаются проблемы похлеще, чем у SQL решений.

G>>то там проблемы с consistency возникают.

C>Ну так. NoSQL типично не имеет гарантий глобальной consistency вообще.
Дык, я про глобальные вещи и не говорю, даже в локальных случаях проблемы возникают.

Сравни это с синхронным коммитом и DTC для SQL.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[29]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 18:20
Оценка:
Здравствуйте, alex_public, Вы писали:


G>>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.

_>Уже даже по ссылке выше видно что это не так.
Как раз по ссылке видно что это так. Там business critical приложений меньше трети, почитай внимательно.
И это самая популярная NoSQL БД. То есть реально меньше 1% рынка, это и есть "в микроскоп не видно".

G>>Фигня какая-то. Можно одну базу на 150 гб поднять. А federations по сути создает базы. Так что фактически предел = 150(максимальное количество federations) * 150(размер БД) = 22,5 ТБ и стоить это все будет $34к (это очень мало)

_>Ааа ну значит 150 гигов уже, а не 50. Возможно я читал раньше или же читал про конкретное реальное облако. В общем помню что была цифра в 50 гигов.
Это на одну базу, ты federations не считал.

_>Что касается federation, то вообще то это же у нас и есть классический шардинг) Такой вот велосипедик от MS для sql. Только он работает не автоматически, как и все sql решения. И работает только под их облако.

Я вообще с трудом представляю автоматический шардинг в SQL. Я его также с трудом представляю как делать rollup по всем документам в распределенном nosql.
Например получить список всех тегов по частоте использования в этой самой базе со статьями.
Расскажешь как это делается?

_>Но кстати показательно что уже и MS начинает думать в сторону нормальных средств масштабирования, а не полагаться на замечательное "вертикальное масштабирование".

В облаке можно много чего себе позволить вендору, потому что всегд корректно все настроено и железа хватает.
Если сам поднимаешь инфраструктуру, то так бывает далеко не всегда.

G>>"облачный" подход с оплатой за использование и разделением compute и storage делает масштабирование гораздо выгоднее.


_>Сферовакуумный разговор без перехода к конкретной задаче и конкретным хостерам/облакам. И не вижу смысла вообще это обсуждать здесь, т.к. достаточно чуть поменяться ценам на рынке и всё переиграется.

Есть устойчивая тенденция снижения цены за единицу ресурса.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[38]: SQL vs NOSQL
От: Cyberax Марс  
Дата: 23.04.12 18:21
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>redis до сих пор не durable

C>>Опционально durable c давних времён.
G>Append-only это не то что можно в конфиге включить, это требует переделки приложения.
Неа.

C>>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать.

G>Ну да, только если включить durable начинаются проблемы похлеще, чем у SQL решений.
Неа.

G>Сравни это с синхронным коммитом и DTC для SQL.

CAP-теорема.
Sapienti sat!
Re[6]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 18:22
Оценка:
Здравствуйте, alex_public, Вы писали:

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


G>>Это верно. Область применения SQL — простые проекты, где нет конкурентного доступа и большого объема данных , типа embed или десктоп приложения.


_>Бред какой. Как раз в этой области увидеть преимущества nosql практически невозможно. Тут логичнее использовать sqlite или вообще просто свой формат файла.


Почему же, преимущества на лице:
1) работа в терминах объектной модели, на надо знать sql
2) высокая скорость работы
3) надежность не ниже надежности самого устройства
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[8]: SQL vs NOSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.04.12 18:32
Оценка:
Здравствуйте, alex_public, Вы писали:

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


__>>>А чем по вашему индексы noSQL отличаются от индексов RDBMS ?

G>>Как минимум тем что:
G>>1) РСУБД имеет регулярную структуру. Например нет множественных значений.
G>>2) Индекс РСУБД оптимизирован по размеру.
G>>3) Операции в СУБД отличаются, поэтому и индексы отличаются.

_>Я понял, индексы в рсубд волшебные.

В чем волшебство то? Сценарии использования разные.


_>Только почему тогда наши совместные измерения показали прямо противоположный результат? )


В чем он противоположный? Время работы почти одинаковое, при том что у меня работала версия Express у которой ограничение в 1гб памяти.
Напомню что изначально апологеты заявляли что SQL сольет. Вот не слил. Хотя такая задача поиска по тегам — крайне тяжелая для sql. Посмотри статьи как этот поиск сделан в stackoverflow, там один большой жосткий хак. В sql server 2012 вроде докрутили FTS и теперь он нормально работает на таких сценариях.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[32]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 19:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Нет, не входит — это я в магазине смотрел. Но цены на colocation для него, очевидно, будут раз в 10 ниже, чем для для 12 коробок. Это же 2U. Поймите, чудес не бывает. Да, наверное, реально топовый сервер (это, скажем, 40 ядер, 2TB памяти, секси дисковая подсистема) стоит не в 40 раз дороже этих унылых фуджитсу. Но до него типичному веб-проекту придётся расти лет десять.

S>А в целом, раздать, скажем, 48GB памяти, 16 ядер, и 16 винтов по 16 машинам никак не выйдет дешевле, чем поставить их все в одно шасси.

Угу, чудес не бывает. Как раз поэтому актуальны оба вида решений. И нам (клиентам) это только хорошо — пускай конкурируют между собой, снижая цены.

Но если смотреть глобально, то я всё же вижу большую перспективу у распределённых систем.
Re[34]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 19:41
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>И где там использование noSQL в "биллинге, бухгалтерии или другой задаче финансового учета"?


Ох... Просто пролистал начало списка (и это при том, что конкретная область применения указана только у части):

"Yabblr uses MongoDB for everything, including inventory management and orders. Yabblr is an E-Commerce platform which..."

"OpenSky uses MongoDB for just about everything (not just analytics). "

"Auriga USA is a financial services company that operates in the residential mortgage space. Moving to MongoDB solved a host of problems, and assisted Auriga USA in upgrading the functionality of their loan inventory management system to handle many new features and different types of assets, including student loans, credit cards, and asset-back securities. "

"Storeden is a cloud ecommerce solution. With Storeden you can sell on facebook, ebay, and more. We use mongoDB as: — storage, with our wrapper for GridFS — database for product, users, order, tracking, and so -real time statistics. "

Или это типа тоже не то? )
Re[9]: SQL vs NOSQL
От: alex_public  
Дата: 23.04.12 19:46
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>Только вот в статьях, хвалящих nosql я часто вижу запросы типа "смотрите, я всего то десяток cross join'ов на таблицы в 100500 записей накидал, чтобы выбрать одну запись и изменить её, а она тупит. И это при том, что я на каждую таблицу по 300 индексов создал. А если бы их не было, я бы вообще состарился к моменту завершения запроса...".

_AB>Умная база часто исправляет кривизну. Но когда не справляется, виноватой почему-то объявляется СУБД, а не "перепрограммер", неспособный понять простейших вещей.

Таких к nosql тем более нельзя подпускать. ) Даже страшно представить себе результат. )))

_>>Но наличие плохих специалистов в мире не означает что не нужно развивать инструменты для профессионалов.

_AB>Согласен. Пусть РСУБД развиваются.



Ну в целом когда-то так и было) Однако сейчас php+mysql+apache — это уже фирменный набор технологий недопрограммера (что не означает что только они используют этот набор). Так что... )))
Re[30]: SQL vs NOSQL