Здравствуйте, Sinclair, Вы писали:
S>Ваша ошибка — в попытке оценивать сложность в отрыве от задачи. Для описания операций с данными SQL значительно проще, чем любой GPPL, будь то си, паскаль, или жава. S>И чем сложнее эти операции, тем сильнее рулит SQL.
Кстати не всё так однозначно. Иначе бы, когда появились orm, на них не ломанулись бы толпы. А сейчас вообще на nosql посматривают...
О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html
Здравствуйте, alex_public, Вы писали:
_>Кстати не всё так однозначно. Иначе бы, когда появились orm, на них не ломанулись бы толпы. А сейчас вообще на nosql посматривают...
Толпы ломанулись на ОРМ оттого, что вопрос взаимодействия прикладного кода с SQL стоял очень остро. Ну и мода — тоже большое дело. Я лично занимался ORM тогда, когда Фаулер свои "паттерны ентерпрайза" ещё не придумал. Тогда казалось, что ООП — это то, чего всем не хватает, и щасте — в ORM, который наконец-то всех спасёт.
_>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html
В целом понятно всё, кроме одного: никто до сих пор так и не смог мне объяснить про отсутствие alter table. Вот оттуда же пример с добавлением commentsByRatings — откуда они волшебным образом появятся в старых постах? Да ниоткуда.
То есть мой код должен везде быть обложен доп проверками — а вдруг нужного индекса как раз тут и не оказалось.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html S>В целом понятно всё, кроме одного: никто до сих пор так и не смог мне объяснить про отсутствие alter table. Вот оттуда же пример с добавлением commentsByRatings — откуда они волшебным образом появятся в старых постах? Да ниоткуда. S>То есть мой код должен везде быть обложен доп проверками — а вдруг нужного индекса как раз тут и не оказалось.
Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее.
Здравствуйте, alex_public, Вы писали:
_>Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее.
Тогда непонятно, в чём собственно тут преимущество.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Собственно всё так и есть. Подход nosql — это писать самим (или в нынешних реалиях брать готовый) лишний код. Это всё и раньше было (достаточно вспомнить всякие беркли дб), просто в нынешних реалиях оно уже наконец то стало выгоднее. S>Тогда непонятно, в чём собственно тут преимущество.
Мы говорим всё ещё про преимущества для программиста или про преимущества nosql вообще?
Второй вопрос достаточно широко освещён в последнее время и я не думаю что стоит повторять сейчас здесь все эти возможности масштабирования, реплицирования и т.п.
Ну и естественно что при выборе технологии именно это учитывается в первую очередь, а не вкусы программистов.
Но если всё же продолжить рассуждать про них, то тут мне кажется всё неоднозначно. Т.е. уже на этом форуме видно что есть много народу, который любит полностью контролировать всё происходящее с кодом. И так же есть много народу придерживающихся противоположных вкусов. Соответственно одни должны быть ближе современные nosql методы, а остальным классические sql базы. Но как я уже сказал, естественно что в нормальных условиях выбор идёт не поэтому параметру, поэтому тут может только повезти в совпадение задач и вкусов... )))
Здравствуйте, alex_public, Вы писали:
_>Мы говорим всё ещё про преимущества для программиста или про преимущества nosql вообще?
Для программиста. Статья была вроде бы про это. Вот я и не понимаю таких аргументов. Это всё равно как говорить "а вот у меня в доме зато нет этого надоедливого лифта". Офигенное преимущество — каждый раз бегать на десятый этаж пешком.
_>Второй вопрос достаточно широко освещён в последнее время и я не думаю что стоит повторять сейчас здесь все эти возможности масштабирования, реплицирования и т.п.
Не, не стоит. Тем более, что SQL и масштабируется, и реплицируется.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Для программиста. Статья была вроде бы про это. Вот я и не понимаю таких аргументов. Это всё равно как говорить "а вот у меня в доме зато нет этого надоедливого лифта". Офигенное преимущество — каждый раз бегать на десятый этаж пешком.
Ну так я и говорю дело вкуса. Сколько тут было споров про RAII vs GC? ) Причём формально говоря RAII — это как "лишний код" казалось бы. В теории... А на практике ничего подобного, если писать код правильно и на правильном языке.
И аналогично выбирается инструмент для работы не по предпочтению во вкусах, а по запросам реальной задачи. Т.е. если берём например какую-нибудь реалтайм обработку видео, то понятно что лучше взять C++. И с ним скорее всего автоматом придёт RAII, что возможно будет по вкусу разработчику, а может и нет. )))
S>Не, не стоит. Тем более, что SQL и масштабируется, и реплицируется.
Ну да, ну да. И на php в теории можно писать для HPC...
Здравствуйте, alex_public, Вы писали:
_>Ну так я и говорю дело вкуса. Сколько тут было споров про RAII vs GC? ) Причём формально говоря RAII — это как "лишний код" казалось бы. В теории... А на практике ничего подобного, если писать код правильно и на правильном языке.
Не видел я таких споров. RAII никак не противоречит GC — это ортогональные штуки.
_>И аналогично выбирается инструмент для работы не по предпочтению во вкусах, а по запросам реальной задачи. Т.е. если берём например какую-нибудь реалтайм обработку видео, то понятно что лучше взять C++. И с ним скорее всего автоматом придёт RAII, что возможно будет по вкусу разработчику, а может и нет. )))
Я понимаю, когда выбирается инструмент. Не понимаю, когда выбирается отсутствие инструмента.
_>Ну да, ну да. И на php в теории можно писать для HPC...
При чём тут "в теории". Вон stackoverflow работает на MS SQL и не жужжит. Мало кому из современных веб-проектов грозит такая нагрузка. Я понимаю, что SQL годится не для всего — скажем, результаты экспериментов на коллайдере складывают, АФАИК, в нереляционную базу. Но там это реально оправдано. А в жизни мы наблюдаем такие аргументы от NoSQL, которые прямо-таки рекламируют SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не видел я таких споров. RAII никак не противоречит GC — это ортогональные штуки.
Ну да, формально споры GC против ручного управления памятью. Но последнее сделанное не через RAII — это уже мазохизм. ))) Хотя временами и такое бывает необходимо.
S>Я понимаю, когда выбирается инструмент. Не понимаю, когда выбирается отсутствие инструмента.
Ооо, вот как раз так и было в прошлом (во времена беркли дб). И тогда nosql выбирали только в очень специальных случаях. Но это давно изменилось. Сейчас то появились именно инструменты. Т.е. сейчас мы ставим какую-нибудь mongodb + MongoAlchemy и наслаждаемся результатом сразу.
S>При чём тут "в теории". Вон stackoverflow работает на MS SQL и не жужжит.
Ну так мы же не знаем чего это им стоило.
S>Мало кому из современных веб-проектов грозит такая нагрузка.
У всяких гуглов, фейсбуков, твитеров меньше что ли? )
S>Я понимаю, что SQL годится не для всего — скажем, результаты экспериментов на коллайдере складывают, АФАИК, в нереляционную базу. Но там это реально оправдано. А в жизни мы наблюдаем такие аргументы от NoSQL, которые прямо-таки рекламируют SQL.
Здравствуйте, alex_public, Вы писали:
_>Ооо, вот как раз так и было в прошлом (во времена беркли дб). И тогда nosql выбирали только в очень специальных случаях. Но это давно изменилось. Сейчас то появились именно инструменты. Т.е. сейчас мы ставим какую-нибудь mongodb + MongoAlchemy и наслаждаемся результатом сразу.
Я не против — только раскройте тему. Я читаю конкретный аргумент: "нету alter table". На вопрос "а как вы меняете структуру существующих данных" ответ простой "а никак". Я же говорю — вы решили проблему с лифтом, который надо было каждый раз вызывать и нажимать эти непонятные кнопки. А иногда он вообще застревал (ну, не у меня, но я знаю чувака, который читал про это на форуме). Теперь вы можете сразу бежать на десятый этаж пешком, детально контролируя весь процесс подъёма.
_>Ну так мы же не знаем чего это им стоило.
Отлично знаем. Инфа про них лежит в открытом доступе.
_>У всяких гуглов, фейсбуков, твитеров меньше что ли? )
И сколько гуглов, фейсбуков, и твиттеров вы пишете в год?
_>Нуу не знаю. Например если взглянуть сюда http://www.mongodb.org/display/DOCS/Production+Deployments то мы увидим явно не только коллайдер. А это всего лишь один из многих nosql движков.
Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.
А что тут непонятного. SQL достаточно сложный сам по себе, а в контексте БД это вообще капец (консистентность, локи, дедлоки и пр.). В результате SQL народ не знает. Некоторые считают, что это проблема народа, но по факту это проблема SQL. Как только цена мегабайта ОЗУ упала до определённой отметки и размер ОЗУ в Гб смог хранить весь working-set типичного приложения, так народ и показал фигу SQL. Фактически, как только позволила техническая БД, так сразу и сбылась мечта ООБД-истов.
А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом.
Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся.
Конечно, по мере, развития ситуации опять появится куча данных, которые не влазят в ОЗУ и по которым нужно делать интерактивные ad-hoc запросы (сейчас там hadoop, но он не интерактивный) и там будут RDBMS. Но SQL должны будут знать единицы по сравнению с текущей ситуацией. По факту человек знающий SQL будет как сантехник сейчас — их мало и никто их не любит.
S>>Ну и что? Я к тому, что причины выбора для коллайдера понятны. Для всех подряд — нет, непонятны. Надо объяснять.
ANS>А что тут непонятного. SQL достаточно сложный сам по себе, а в контексте БД это вообще капец (консистентность, локи, дедлоки и пр.). В результате SQL народ не знает.
Локи к SQL не имеют отношения. Конкурентный доступ вообще сложная тема и БД она еще очень хорошо решается по сравнению например с мейнстримовыми ЯП.
ANS>Некоторые считают, что это проблема народа, но по факту это проблема SQL.
Тогда уж проблема реляционной модели.
ANS>Как только цена мегабайта ОЗУ упала до определённой отметки и размер ОЗУ в Гб смог хранить весь working-set типичного приложения, так народ и показал фигу SQL. Фактически, как только позволила техническая БД, так сразу и сбылась мечта ООБД-истов.
А причем тут память? Конкурентный доступ и требование durable транзакций остается.
ANS>А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом.
Для говносайтов такое вполне может быть, для серьезных приложений — никогда.
ANS>Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся.
Покачто применение noSQL не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет.
Здравствуйте, gandjustas, Вы писали:
G> она еще очень хорошо решается
Угу, просто мало людей, которые понимают, что с этим решение делать.
ANS>>Некоторые считают, что это проблема народа, но по факту это проблема SQL. G>Тогда уж проблема реляционной модели.
Хоть лбом, хоть по лбу.
G>А причем тут память? Конкурентный доступ
Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?
Да и, ты говоришь так, будто этим "Конкурентным доступ" просто бери и пользуйся. А фиг.
G>и требование durable транзакций остается.
Да-да. Помню помню, недавно обсуждалось. Всё закончилось, тем, что "durable" это не когда данные сохраняются, а когда сервер после сбоя быстро стартует.
ANS>>А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом. G>Для говносайтов такое вполне может быть, для серьезных приложений — никогда.
Бу-га-га. См. выше про дюрабилити. И вот такие вот 99.9% "серьезных приложений".
ANS>>Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся. G>Покачто применение noSQL не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет.
Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
G>>А причем тут память? Конкурентный доступ
ANS>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других?
Ты о чем? 8-ка полагается на механизмы SQL Server.
ANS>Да и, ты говоришь так, будто этим "Конкурентным доступ" просто бери и пользуйся. А фиг.
По сравнению с другими способами разруливания — да, бери и пользуйся. Потому что в основе математика.
А что будет с nosql базой если одновременно два запроса за запись придут? А если они придут на разные шарды?
G>>и требование durable транзакций остается. ANS>Да-да. Помню помню, недавно обсуждалось. Всё закончилось, тем, что "durable" это не когда данные сохраняются, а когда сервер после сбоя быстро стартует.
Это ты такое утверждал. Все остальные говорят что durable это когда изменения остаются после commit пока целостность хранилища не нарушена.
SQL такое обеспечивает целостность данных, ссылочную целостность и целостность индексов, даже если сразу после commit все упадет. А nosql, кроме отдельных отдельных образцов, не обеспечивает и такого. Даже то что после записи данные будут доступны.
ANS>>>А ACID народ заменил на soft-ACID. Это по аналогии с "soft real time". Типа в большинстве случаев у нас ACID (само как-то так получается), а над теми пользователями-неудачниками, которым не повезло народ ржёт по пятницам за пивом. G>>Для говносайтов такое вполне может быть, для серьезных приложений — никогда.
ANS>Бу-га-га. См. выше про дюрабилити. И вот такие вот 99.9% "серьезных приложений".
Ты о чем вообще? Сколько раз сам наблюдал нарушение целостности БД какого нить SQL Server без поломок дисков?
А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно.
Может поправили, но это не было нештатных ситуаций.
ANS>>>Понятно, что те, кто изучал SQL теперь в шоке — мол жизнь прошла, ерундой прозанимался, а оказывается JavaScript нужно было учить. Но такое, никто и не обещал, что в царстве небесном всем место найдётся. G>>Покачто применение noSQL не видно в микроскоп по сравнению с реляционными БД и тенденции пока нет. ANS>Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно.
А он тут причем?
Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.
Здравствуйте, Sinclair, Вы писали:
S>Я не против — только раскройте тему.
Я возможно изначально не очень чётко выразил свою точку зрения на всё это.
Все преимущества nosql заложены в них изначально по самому принципу строения. Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.
Т.е. допустим нам для решения задачи первоначально достаточно даже sqlite. Но благодаря тому, что современные nosql инструменты позволяют потратить на разработку времени не больше чем для sqlite варианта, мы можем сразу заложиться хоть на 1000 кратный рост нагрузки. Т.е. особо важным этот новый тренд является как раз для стартапов и т.п., т.к. всяческие монстры и так в большинстве своём используют nosql базы (часто собственной разработки).
Снова немного сумбурно вышло. Но нельзя подробно объяснить подобное не делая полноценную статью. Да и я почему то был уверен что здесь все уже давно обчитались подобных статей.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sinclair, Вы писали:
S>>Я не против — только раскройте тему.
_>Я возможно изначально не очень чётко выразил свою точку зрения на всё это.
_>Все преимущества nosql заложены в них изначально по самому принципу строения.
Это какие такие преимущества? Какой принцип строения?
_>Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.
За счет чего снята?
_>Т.е. допустим нам для решения задачи первоначально достаточно даже sqlite. Но благодаря тому, что современные nosql инструменты позволяют потратить на разработку времени не больше чем для sqlite варианта, мы можем сразу заложиться хоть на 1000 кратный рост нагрузки. Т.е. особо важным этот новый тренд является как раз для стартапов и т.п., т.к. всяческие монстры и так в большинстве своём используют nosql базы (часто собственной разработки).
Как раз "монстры" используют вполне промышленные субд, а вот nosql там в основном для кеширования и других, далеко не критичных, плюшек.
_>Снова немного сумбурно вышло. Но нельзя подробно объяснить подобное не делая полноценную статью. Да и я почему то был уверен что здесь все уже давно обчитались подобных статей.
Проблема одна — в статьях (и у тебя тоже) лозунги. Как доходит до дела
. Вообще интересная тема получилась, если бы не желание некоторых обсуждать личности. Там есть пара примеров когда MS SQL заруливает на тех задачах, которые вроде как приписываются NoSQL как основные.
Здравствуйте, gandjustas, Вы писали:
G>А вот тот же ravendb (очень крутой nosql движок)
Сколько смотрел разного про nosql, но ни разу не слышал про ravendb. Сейчас глянул в гугле (ссылок то как мало на него): http://ravendb.net/testimonials — что-то совсем не впечатляющее. Теперь понятно откуда такие воззрения... )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.
_>Ээээ, десяток сервисов гугла подойдёт? )))
Не подойдет. Гугл уже терял всю почту на многих ящиках gmail. Вот тебе и репликация. Кроме того они вполне могут под свои особенности адаптировать движок, что в обычных проектах разработчики позволить себе не могут.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>А вот тот же ravendb (очень крутой nosql движок)
_>Сколько смотрел разного про nosql, но ни разу не слышал про ravendb. Сейчас глянул в гугле (ссылок то как мало на него): http://ravendb.net/testimonials — что-то совсем не впечатляющее. Теперь понятно откуда такие воззрения... )))
По сравнению с другими NoSQL субд Raven умеет честный acid и автоматически строить индексы. В подавляющем большинстве других баз с этим крайне плохо.
Вообще-то никто так и не привел решения задаче
Здравствуйте, alex_public, Вы писали:
_>Все преимущества nosql заложены в них изначально по самому принципу строения. Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену.
Я продолжаю непонимать, что это за преимущества. Все почему-то делают вид, что они очевидны, но когда начинаешь копать, все преимущества начинаются со слова no. Типа "у нас нет языка запросов, нет поддержки индексов, нет гарантий целостности". Отлично. Преимущество-то в чём?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
ANS>>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других? G>Ты о чем? 8-ка полагается на механизмы SQL Server.
Ну, вот привели там пример гигантской обработки на C# под Парус. Допустим в её середине вылетело исключение "SQLState 40001". Его обрабатывает сама платформа, или проталкивает наверх к прикладному программисту (что ему делать)? Или платформа что-то делает, чтобы такие ошибки в принципе не вылетали?
ANS>>Да и, ты говоришь так, будто этим "Конкурентным доступ" просто бери и пользуйся. А фиг. G>По сравнению с другими способами разруливания — да, бери и пользуйся. Потому что в основе математика. G>А что будет с nosql базой если одновременно два запроса за запись придут? А если они придут на разные шарды?
Хе-хе. Понятия "одновременно" в распределённой системе нету. Нет понятия — нет проблемы
G>>>и требование durable транзакций остается. ANS>>Да-да. Помню помню, недавно обсуждалось. Всё закончилось, тем, что "durable" это не когда данные сохраняются, а когда сервер после сбоя быстро стартует. G>Это ты такое утверждал.
? Бывает.
G>Все остальные говорят что durable это когда изменения остаются после commit пока целостность хранилища не нарушена. G>SQL такое обеспечивает целостность данных, ссылочную целостность и целостность индексов, даже если сразу после commit все упадет. А nosql, кроме отдельных отдельных образцов, не обеспечивает и такого. Даже то что после записи данные будут доступны.
Всё так. Но сама по себе RDBM сейчас никому не нужна. Нужна система с которой пользователь взаимодействует. И тут возникает парадокс, система построена на RDBM, у RDBM гарантии ACID есть, а у системы в целом — нет.
ANS>>Бу-га-га. См. выше про дюрабилити. И вот такие вот 99.9% "серьезных приложений". G>Ты о чем вообще? Сколько раз сам наблюдал нарушение целостности БД какого нить SQL Server без поломок дисков?
См. выше. Толку с этих гарантий если в куче случаев разработчик опираясь на них на выходе пшик получает.
G>А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно. G>Может поправили, но это не было нештатных ситуаций.
, так сразу начнётся, то не все для атомных станций софт пишут, то не все фейсбуки пишут, то не все просто пишут.
Ты просто осознай, что вот есть какой-то там MySql (ACID не смотря на технологические огрехи). Прикрутили люди поперед него memcached — почти 100% стала nosql система. Притом сразу с багами. Организовали шарды — nosql.
Работает это всё случайно. Может и не работает, но разработчики не замечают то.
Здравствуйте, Sinclair, Вы писали:
S>Я продолжаю непонимать, что это за преимущества. Все почему-то делают вид, что они очевидны, но когда начинаешь копать, все преимущества начинаются со слова no. Типа "у нас нет языка запросов, нет поддержки индексов, нет гарантий целостности". Отлично. Преимущество-то в чём?
Но вообще частенько (это уже зависит от конкретной задачи) преимущества проявляются и в случае одной машины. Например в комментах к этой статье http://habrahabr.ru/post/74144/ интересный пример человек приводит. Кстати, и сама статья любопытная в контексте нашего обсуждения.
Что касается языка запросов, то тут не всё так однозначно. ))) Например здесь http://www.unqlspec.org/display/UnQL/Example+Queries+and+Usage можно взглянуть на пример такого языка для nosql, продвигаемого авторами одного из движков. Естественно совсем не обязательно что это станет каким-то стандартом. Но что бы "оценить суть" он вполне показателен.
Здравствуйте, 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>Избирательная память
? Бывает.
Так это и не я утверждал.
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
.
Тогда возвращаемся к вопросу что такое NoSQL. Очевидны проблемы с позиционированием таких систем.
ANS>>>Не пытайся закрывать глаза на очевидное. Купи книжку Крокфорда пока не поздно. G>>А он тут причем? ANS>Выучишь кошерный JavaScript
Я его и так знаю, это тут при чем?
G>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.
ANS>А смысл? Ну буду я что-то называть
, так сразу начнётся, то не все для атомных станций софт пишут, то не все фейсбуки пишут, то не все просто пишут. ANS>Ты просто осознай, что вот есть какой-то там MySql (ACID не смотря на технологические огрехи). Прикрутили люди поперед него memcached — почти 100% стала nosql система. Притом сразу с багами. Организовали шарды — nosql. ANS>Работает это всё случайно. Может и не работает, но разработчики не замечают то.
MySQL + кеш это NoSQL?
Тогда вообще о чем разговор? Если в основе все равно лежит SQL БД, с которой надо работать.
Здравствуйте, gandjustas, Вы писали:
G>Это какие такие преимущества? Какой принцип строения?
Ответил в сообщение для Sinclair)
_>>Но раньше у них была некая проблема — высокий уровень вхождения (естественно если мы хотим действительно эффективные решения). Который могли себе позволить (собственно у них и не было другого выхода) только всяческие гуглы и т.п. А сейчас эта проблема снята. Т.е. попросту говоря, теперь мы можем получить все преимущества nosql (которые у них от рождения, просто по дизайну), не платя за это высокую цену. G>За счет чего снята?
За счёт появления массы уже разработаных решений. Как "подарков от монстров", которые они выкладывают на допиливание, так и собственно небольших разработок. Для большинства задач уже можно найти практически готовое решение. Более того, всякие фреймворки уже начинают включать nosql базы в набор поддерживаемых.
G>Как раз "монстры" используют вполне промышленные субд, а вот nosql там в основном для кеширования и других, далеко не критичных, плюшек.
Эмм, гугл, яндекс, амазон — они хранят данные в sql? )))
G>Проблема одна — в статьях (и у тебя тоже) лозунги. Как доходит до дела
. Вообще интересная тема получилась, если бы не желание некоторых обсуждать личности. Там есть пара примеров когда MS SQL заруливает на тех задачах, которые вроде как приписываются NoSQL как основные.
Не видел раньше этой темки. Наверное уже не буду её сейчас всю читать. Но первое сообщение прочитал. Если бы я делал проект с нуля, то взял бы nosql решение. Т.к. разработка не была бы сложнее, а при этом я был бы абсолютно спокоен за будущее, а не думал бы постоянно "укладываемся ли мы ещё одну машину или уже нет" (тут же не только объём базы важен, но и количество запросов).
Здравствуйте, gandjustas, Вы писали:
G>>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю. _>>Ээээ, десяток сервисов гугла подойдёт? ))) G>Не подойдет. Гугл уже терял всю почту на многих ящиках gmail. Вот тебе и репликация.
От этого оно перестало быть "серьёзным приложением"? ))) Тогда интересует определение "серьёзного приложения".
G>Кроме того они вполне могут под свои особенности адаптировать движок, что в обычных проектах разработчики позволить себе не могут.
Так я про это и писал. Более того, большинство "монстров" не адаптировали что-то, а разработали с нуля под себя. А уже потом многие выложили свои разработки на допиливание сообществом — тут и пошло развитие этой тематики в массы...
Здравствуйте, 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>>Проблема одна — в статьях (и у тебя тоже) лозунги. Как доходит до дела
. Вообще интересная тема получилась, если бы не желание некоторых обсуждать личности. Там есть пара примеров когда MS SQL заруливает на тех задачах, которые вроде как приписываются NoSQL как основные.
_>Не видел раньше этой темки. Наверное уже не буду её сейчас всю читать. Но первое сообщение прочитал. Если бы я делал проект с нуля, то взял бы nosql решение. Т.к. разработка не была бы сложнее, а при этом я был бы абсолютно спокоен за будущее, а не думал бы постоянно "укладываемся ли мы ещё одну машину или уже нет" (тут же не только объём базы важен, но и количество запросов).
Если Ваш заказчик готов купить супер сервер за несколько миллионов долларов (а по мере роста — десятков миллионов и т.д.), что-бы сэкономить время, но сделать все быстро, можете дальше эту статью не читать .
Чисто для справки: мировой рекорд по 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 баз, ни реляционных баз. Воспользоваться шардингом по ключу не удастся, т.к. нет гарантии, что запрос идёт по ключу. Воспользоваться индексами не удастся, т.к. нет структуры. В общем, имхо — это мертворождённая штука.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
ANS>>>>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других? G>>>Ты о чем? 8-ка полагается на механизмы SQL Server.
ANS>>Ну, вот привели там пример гигантской обработки на C# под Парус. Допустим в её середине вылетело исключение "SQLState 40001". Его обрабатывает сама платформа, или проталкивает наверх к прикладному программисту (что ему делать)? Или платформа что-то делает, чтобы такие ошибки в принципе не вылетали?
G>Абстрактная ошибка в абстрактном коде будет также абстрактно обрабатываться. G>Ты чего сказать то хотел?
, ошибка тоже — конкретней не бывает.
G>Как нету? Так нету. По сути тебе ничего не отвечу, потому что сути вопроса не понимаю.
G>Так это и не я утверждал.
Я тебе это и не пенял.
ANS>>Всё так. Но сама по себе RDBM сейчас никому не нужна. Нужна система с которой пользователь взаимодействует. И тут возникает парадокс, система построена на RDBM, у RDBM гарантии ACID есть, а у системы в целом — нет. G>Если система в целом ниче криминального с базой не делает, а честно туда пишет изменения, то как это acid нету? G>Ты покажи пример чтоли того о чем ты говоришь. Только не абстрактный, а конкретный.
Я ж написал. Почти любая система с memcached. Проблема в том, что эти самые данные записать это последний шаг. До этого их нужно вычитать и обработать.
G>Так это проблема разработчика.
Ошибаешься. Раньше людей делали для БД. Сейчас появляется техническая возможность БД делать для людей.
G>Ты предлагаешь сразу все гарантии отбросить чтобы разработчикам проще было? Это говнософт получается.
Нет. Я предлагаю явно определить каких гарантий нет, какие есть, чего это стоит.
G>>>А вот тот же ravendb (очень крутой nosql движок) умудрялся терять индексы при нормальной работе. Полгода назад вебкаст был, там это очень хорошо видно. G>>>Может поправили, но это не было нештатных ситуаций.
ANS>>Никогда ни про какой ravendb не слышал. Но в любом случае, это проблема незрелости. Со временем это пройдёт. Сейчас время NoSql систем построенных поверх зрелого SQL
пока не поменял. И, да, проблемы с позиционированием есть.
G>>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.
G>MySQL + кеш это NoSQL? G>Тогда вообще о чем разговор? Если в основе все равно лежит SQL БД, с которой надо работать. Нет, работать нужно с другим уровнем и другими гарантиями.
. Просто сейчас люди делают это неявно и ожидают ACID гарантий. Я предлагаю делать явно, по четко определённому протоколу, с четким определением существующих гарантий.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>>>Локи, дедлоки. Мне интересно послушать AndrewVK на примере с "Парусом" как они решают проблемы конкурентности и консистентности. В 1С7 проблему решили просто — нет конкурентности, нет проблемы. Как в 8 и у других? G>>>>Ты о чем? 8-ка полагается на механизмы SQL Server.
ANS>>>Ну, вот привели там пример гигантской обработки на C# под Парус. Допустим в её середине вылетело исключение "SQLState 40001". Его обрабатывает сама платформа, или проталкивает наверх к прикладному программисту (что ему делать)? Или платформа что-то делает, чтобы такие ошибки в принципе не вылетали?
G>>Абстрактная ошибка в абстрактном коде будет также абстрактно обрабатываться. G>>Ты чего сказать то хотел?
ANS>Код конкретный
, ошибка тоже — конкретней не бывает.
С чего там ошибка? В каком месте?
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
пока не поменял. И, да, проблемы с позиционированием есть.
Твое определение неконструктивно, не позволяет разделить системы на SQL и NoSQL.
G>>>>Назови 10 серьезных приложений, которые используют nosql, я тебе поверю.
G>>MySQL + кеш это NoSQL? G>>Тогда вообще о чем разговор? Если в основе все равно лежит SQL БД, с которой надо работать. ANS>Нет, работать нужно с другим уровнем и другими гарантиями.
. Просто сейчас люди делают это неявно и ожидают ACID гарантий. Я предлагаю делать явно, по четко определённому протоколу, с четким определением существующих гарантий.
Тем не менее гарантии не могут быть сильнее, чем гарантии хранилища и перформанс в среднем — тоже.
Здравствуйте, 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>Там есть хорошая задача и её решение
Ну во-первых я не вижу задачки, а вижу только решение уже, в стиле sql. А ведь если использовать nosql базы, то частенько более эффективное решение может выглядеть совсем по другому (не в табличном виде).
А во-вторых зачем мне это? )
Здравствуйте, 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 в формальном описание видны индексы, коммиты и т.п. Сам детали не смотрел. )
Здравствуйте, 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>>Там есть хорошая задача и её решение
. Сделай его на nosql, покажи результаты.
_>Ну во-первых я не вижу задачки, а вижу только решение уже, в стиле sql. А ведь если использовать nosql базы, то частенько более эффективное решение может выглядеть совсем по другому (не в табличном виде).
Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000.
Полнотекстовый поиск не использовать.
_>А во-вторых зачем мне это? )
Это часть исходной задачи про stackoverflow. Некоторые утвреждали что SQL сосет на таких задачах. MS SQL отлично сработал, теперь интересно посмотреть на результаты хоть для одной NoSQL бд.
Здравствуйте, gandjustas, Вы писали:
G>С чего там ошибка? В каком месте?
Я ж написал "SQLState 40001". Дедлок или что там. С чего он вылетает и в каком месте? Вот я и спрашиваю, как платформа себя с ним ведёт.
G>В NoSQL, например mongodb — writelock на сервер. При большой нагрузке и чтении\записи хотябы 10 к 1 mongo ляжет.
А ты про это. А мне плевать Мне монго ни к чему. Я уже написал, что всё это слишком immature, что бы в реальности этим пользоваться. Но концепция мне нравится.
G>Да хоть 10 memcached, в memcached хранятся данные, которые отдаются клиенту, записи сразу проваливаются в БД со сбросом кеша. Следующее чтение обновляет кеш. Возможно обновление кеша сразу после записи, чтобы не ждать пока кто-нить обратится. G>Такая схема дает и скорость, и acid, и является практически стандартом для нагруженных веб-приложений.
Ну вот. Прекрасный пример. Скорость даёт, acid херит , но является практически стандартом для нагруженных веб-приложений.
G>Внимание вопрос, где тут NoSQL или что оно тут может улучшить?
G>Ну правильно. Оптимизаторы БД становлятся все круче, сами оптимизируют планы, сами предлагают индексы и другие оптимизации. настройка HA и DR делается парой кликов мышки.
.
G>Над этим всем понастроены мощные фреймворки и платформы, позволяющие работать в терминах предметной области, а не таблиц и связей.
Этот вопрос в начале топика поднимался. Ничего хорошего из того, что ты перечислил не нашлось.
G>>>Ты предлагаешь сразу все гарантии отбросить чтобы разработчикам проще было? Это говнософт получается. ANS>>Нет. Я предлагаю явно определить каких гарантий нет, какие есть, чего это стоит. G>Так acid более чем явно гарантии дает. Если не считать багов реализации. G>Вот только не всегда программист способен своим кодом гарантии не нарушать. G>даже есл ты от части гарантий окажешься, то это не поможет программисту не нарушать остальные.
если всё это это вынести в отдельный сервер, программист туда только запросы посылал, а не писал сам эту логику,
то ошибится программист не сможет. Останутся только баги реализации, которые ты приемлишь.
G>Твое определение неконструктивно, не позволяет разделить системы на SQL и NoSQL.
А мне кажется, что оно вполне фальсифицируемо, а значит конструктивно. Я даже скажу, что оно в тысчу раз конструктивнее любых определений DSL в этом топике.
G>Тем не менее гарантии не могут быть сильнее, чем гарантии хранилища и перформанс в среднем — тоже.
Здравствуйте, 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>Ты маркетолог? А то если спустится на землю (заглянуть в соседний форум), то вдруг найдутся менее радостные картины
.
В чем они менее радостные? У чувака база внезапно стала работать быстрее чем он ожидал. Он только не понял почему.
Я в технологиях сторонник подхода — "не чини пока не сломано".
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>Оно, как бы могут, но, это мы проходили
, — в данном случае главный плюс не в усилении гарантий, а в управляемом ослаблении оных.
Ссылаться на свои же невернуе утверждения — верх демагогии.
В чем плюс таки заключается? Ослабление гарантий дает недостатки, это очевидно. Какие преимущества оно дает?
Здравствуйте, 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>>Ты маркетолог? А то если спустится на землю (заглянуть в соседний форум), то вдруг найдутся менее радостные картины
, — в данном случае главный плюс не в усилении гарантий, а в управляемом ослаблении оных. G>Ссылаться на свои же невернуе утверждения — верх демагогии. G>В чем плюс таки заключается? Ослабление гарантий дает недостатки, это очевидно. Какие преимущества оно дает?
Я сослался не только на своё утверждение, а и на всё последующее обсуждение. Там было и про преимущества. Повторно обсасывать смысла же нет?
Еще я хочу заметить, что всё это напоминает логические обоснования, почему JavaScript в браузере умрёт из-за SIlverlight или еще чего. Только в конце концов Silverlight врезал дуба, а JS полез на сервера.
Здравствуйте, 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 базы.
, то это дурят, rsdn криво написан и никто об этом не знает или rsdn криво написан и об этом все знают, но правильно сделать сложно и проще забить ?
G>>>А можно реально пользоваться только тем что поверх SQL работает? ANS>>Ох-ох. Так Flockdb это SQL или нет. G>Нафига мне исходники смотреть. Приведи описание того что умеет, посмотрим.
Крути вниз — там README с описанием. Но, можеш посмотреть на википедии.
G>Таких надо учить, а не пытаться защитить от сурового мира.
результат, тем не менее, предопределён.
G> G>Убери memcached, ситуация изменится? Ни разу. Это общий вопрос распределенных систем — как только ты получил данные из внешней системы, они перестали быть актуальные.
изменится. пропадёт распределённость. вот так вот и все — пытаются прикрутить кеширование, а прикручивают распределённость и неопределённость. а продолжают со всем этим работать, как буд-то по прежнему есть только одна система.
ANS>>Хотя я помню, что ты тверждал, что ACID не гарантирует того, что ты прочитаешь те же данные, как и записал. Так что для тебя каша в данных наверное норма. G>В одной транзакции — гарантирует. Межу транзакциями может произойти что угодно, надеюсь это все понимают. Если мне нужно прочитать ровно тоже что я записал, я просто транзакцию не закрою. И пока открыта транзакция гарантия есть.
G>NoSQL же зачастую говорит что нет возможности гарантировать что ты прочитаешь то что записал. Какие бы ужимки ты не принимал. G>Вот собственно и разница. А из этой разницы следует очень много. Например любые данные любого учета (бухгалтерия, банк, склад) нельзя складывать в NoSQL системы, нет гарантии что они там вообще окажутся. Даже в банальном форуме я не могу выполнить асинхронную отправку и на клиенте показать результат, потому что нету у меня гарантии что он вообще добавился.
Однако по факту, например в Facebook, nosql используют для мыла и месенджера.
G>А вот NoSQL — говно полнейшее, которое никем из больших игроков не поддержвается. Oracle, MS, IBM.
Еещ пример: Google Tenzing: пускает запросы поверх MapReduce и позволило Google уйти с той СУБД, которая была до (мне почему-то кажется, что была Terradata, но название они в pdf специально не указывают).
Вот спасибо! Прямо идеальное дополнение к моим аргументам. Смотрю на цены по этим ссылкам и ситуация с преимуществом 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 секунды.
Как мы видим получается что значительно более короткий и простой код работает даже слегка быстрее. И при этом я могу масштабировать это решение на много компьютеров парой движений (причём даже не в исходном коде).
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Ну да, обновить страницу страшнее не куда. А потерять данные — ниче.
ANS>Ага. Т.е. когда в форумах говорят, что по правильному нужно рестартовать транзакцию
, то это дурят, rsdn криво написан и никто об этом не знает или rsdn криво написан и об этом все знают, но правильно сделать сложно и проще забить ?
Я не знаю как rsdn написан. Но при появлении такого сообщения на форуме абсолютно нестрашно сделать f5.
G>>>>А можно реально пользоваться только тем что поверх SQL работает? ANS>>>Ох-ох. Так Flockdb это SQL или нет. G>>Нафига мне исходники смотреть. Приведи описание того что умеет, посмотрим.
ANS>Крути вниз — там README с описанием. Но, можеш посмотреть на википедии.
Мда, в википедии один абзац. Ты сам быстрее напишешь про фичи.
G>> G>>Убери memcached, ситуация изменится? Ни разу. Это общий вопрос распределенных систем — как только ты получил данные из внешней системы, они перестали быть актуальные. ANS>изменится. пропадёт распределённость. вот так вот и все — пытаются прикрутить кеширование, а прикручивают распределённость и неопределённость. а продолжают со всем этим работать, как
буд-то по прежнему есть только одна система.
С чего это она пропадет? Сервак все равно на другой машине. А клиент на третьей. Ведь кто-то может поменять данные к тот момент пока до клиента идет результат запроса.
Ниче, никто не умер. Просто все видят немного старые данные. Вот только они видят эти данные, взамен этого NoSQL говорят что клиент их может и не увидеть. Это уже плохо.
ANS>>>Хотя я помню, что ты тверждал, что ACID не гарантирует того, что ты прочитаешь те же данные, как и записал. Так что для тебя каша в данных наверное норма. G>>В одной транзакции — гарантирует. Межу транзакциями может произойти что угодно, надеюсь это все понимают. Если мне нужно прочитать ровно тоже что я записал, я просто транзакцию не закрою. И пока открыта транзакция гарантия есть.
ANS>Не юли
ты слишком много сам на себя сылаешься.
По сути: ты не согласен что в одной транзакции нельзя прочитать то что записал? Тогда ты видимо не знаком с транзакциями вообще.
То что ты не прочитаешь то что записал через неопределенно большое время я тебе и так могу сказать.
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 сливает.
Здравствуйте, 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 загнать? А то питон не хочется ставить.
Здравствуйте, gandjustas, Вы писали:
G>так подними 30 млн. транзакций в минуту на NoSQL, в чем вопрос? Возьми первое место в TPC-C
А там вообще результаты от сетей компьютеров (не кластеров) принимают? )
G>Есть, индекс я так понимаю после каждой правки надо пересчитывать, это мягко говоря дофига времени займет.
А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? )
G>Кстати есть код, который можно в интерпретатор mongo загнать? А то питон не хочется ставить.
Я даже не смотрел какой там язык в mongodb shell и не открывал ни разу. Зачем? Всё равно реальный код пишется на каком-то нормальном языке. И скрипты любые намного удобнее на Питоне. А в чём проблема с Питоном? На винде это значит пару msi запустить и всё. ) Могу подсказать какие.)
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>так подними 30 млн. транзакций в минуту на NoSQL, в чем вопрос? Возьми первое место в TPC-C
_>А там вообще результаты от сетей компьютеров (не кластеров) принимают? )
Я думаю принимают.
G>>Есть, индекс я так понимаю после каждой правки надо пересчитывать, это мягко говоря дофига времени займет. _>А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? )
Может и так, но это происходит само и гораздо быстрее.
G>>Кстати есть код, который можно в интерпретатор mongo загнать? А то питон не хочется ставить.
_>Я даже не смотрел какой там язык в mongodb shell и не открывал ни разу. Зачем? Всё равно реальный код пишется на каком-то нормальном языке. И скрипты любые намного удобнее на Питоне. А в чём проблема с Питоном? На винде это значит пару msi запустить и всё. ) Могу подсказать какие.)
Я просто обратил внимание что самую интересную операцию, пересечение множеств, ты сделал на питоне.
Здравствуйте, gandjustas, Вы писали:
_>>А там вообще результаты от сетей компьютеров (не кластеров) принимают? ) G>Я думаю принимают.
А где там гугл тогда? )
_>>А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? ) G>Может и так, но это происходит само и гораздо быстрее.
Тут тоже всё само. Там в коде именно операция создания индекса (навсегда), а не какого-то обновления.
И откуда интересно данные что "гораздо быстрее"?
G>Я просто обратил внимание что самую интересную операцию, пересечение множеств, ты сделал на питоне.
Ну так это и есть стиль nosql. ))) То самое, что Sinclair критиковал.
Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>А там вообще результаты от сетей компьютеров (не кластеров) принимают? ) G>>Я думаю принимают.
_>А где там гугл тогда? )
Я думаю у гугла на 30 млн транзакций в минуту приходится гораздо больше железа. Там ведь не запросы чтения данных считают.
_>>>А в sql базах не так что ли? ) Там индексы волшебные и работают без затрат времени? ) G>>Может и так, но это происходит само и гораздо быстрее.
_>Тут тоже всё само. Там в коде именно операция создания индекса (навсегда), а не какого-то обновления. _>И откуда интересно данные что "гораздо быстрее"?
В SQL создание индексов заняло около 10 секунд. Сделал drop и create
G>>Я просто обратил внимание что самую интересную операцию, пересечение множеств, ты сделал на питоне.
_>Ну так это и есть стиль nosql. ))) То самое, что Sinclair критиковал.
Это чревато перекачкой большого объема данных из базы в приложение.
_>Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...
Не думаю что разница превысила бы 10%
но напоследок замечу, что картинка, как в анекдоте получается: там где семья потенциальных миллионеров, а по факту одни проститутки.
так и тут, потенциально миллиарды транзакций на сервере слабее zx-spectrum, идеальное разруливание конкурентного доступа, оптимизаторы умнее человека, полная изоляция, полное durability,
а в реальности, нужно обвесить костылями a-la memcached, запросы хинтами обтыкать, в полях json хранить, для дюрабельности асинхронную master-master репликацию сделать (sic!) и себя еще и убеждать, что там да, страничка иногда не работает, но пользователь F5 потыкает (чай корона не упадёт), там он данные будет старые видёть, но ничё — через 15 мин кеш проэкспайрится и ок. А когда говоришь, что система получилось гуано, отвечают ничего не гуано, у нас acid и математика, а про кашу в данных врёшь ты всё, потому что смотри п.первый про асид, и лучше быть ничего не может потому что смотри п.первый про асид и второй про математику. Сюр.
Здравствуйте, 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 каком нить и надеется (а что ему еще остается) что все будет нормально.
Здравствуйте, alex_public, Вы писали:
_>А где там гугл тогда? )
А гугл и не подавал никогда.
И я так думаю, что в TPC-C у гугла не больше шансов, чем у прочих. Их технология разработана не совсем для этого случая.
_>Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями...
Тогда бы мы получили полную противоположность декларируемым преимуществам NoSQL — высокий порог вхождения и массовые забеги с напильником для получения приемлемого быстродействия, вместо того, чтобы за 20 минут накидать базу на SQL Express, а масштабировать — потом, когда у проекта будут деньги на это.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000. G>Полнотекстовый поиск не использовать.
У нас похожая задача, только база 10 000 000 статей, тегов произвольное количество, всего тегов 100 000, связей тегов со статьями 500 000 000, разные критерии сортировки, которые надо гибко настраивать и менять, которые зависят от введенных тегов, значений в таблице связей, авторов статей, ... При выдаче обязательно необходимо выдавать общее количество статей, которые удовлетворяют условиям поиска. Также сходные результаты не должны следовать один за другим. Поиск не менее секунды, а лучше 0.1. И еще ряд условий... MySQL и Postge не справились в наших руках, ни у кого не хватило квалификации.
_> _>Вот спасибо! Прямо идеальное дополнение к моим аргументам. Смотрю на цены по этим ссылкам и ситуация с преимуществом nosql становится просто очевидной. )
Правда что ли?
А вы уверены, что всё честно посчитали на стороне NoSQL? У TPC-C — очень жёсткие критерии подсчёта стоимости. Например, туда входит стоимость клиентских машин. Ваше NoSQL решение, надо полагать, их тоже учитывает? Учитывается ли стоимость поддержки на срок 3 года?
Посмотрите спецификации на TPC-C, попробуйте рассчитать стоимость NoSQL варианта с аналогичной производительностью. Необязательно брать сразу два миллиона TpMc, возьмите что-нибудь маленькое, тысяч на двадцать, и посмотрите в прайс. Там очень подробно расписано — сколько стоит железо, сколько диски, сколько сеть, сколько лицензии — и так далее. Попробуйте найти способ сэкономить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>так и тут, потенциально миллиарды транзакций на сервере слабее zx-spectrum, идеальное разруливание конкурентного доступа, оптимизаторы умнее человека, полная изоляция, полное durability, ANS>а в реальности, нужно обвесить костылями a-la memcached, запросы хинтами обтыкать, в полях json хранить, для дюрабельности асинхронную master-master репликацию сделать (sic!) и себя еще и убеждать, что там да, страничка иногда не работает, но пользователь F5 потыкает (чай корона не упадёт), там он данные будет старые видёть, но ничё — через 15 мин кеш проэкспайрится и ок. А когда говоришь, что система получилось гуано, отвечают ничего не гуано, у нас acid и математика, а про кашу в данных врёшь ты всё, потому что смотри п.первый про асид, и лучше быть ничего не может потому что смотри п.первый про асид и второй про математику. Сюр.
Коллега, вы бы вместо того, чтобы позориться, почитали отчёты с TPC-С. Там очень подробно написано, какие ухищрения и для чего делаются, и какие результаты получаются. Прикол в том, что результаты там засчитываются только "кинетические", а не "потенциальные". Т.е. недостаточно просто написать туда "я думаю, что можно вот так всё настроить". Нужно реально построить кластер и провести измерения.
Так что насчёт гуанности систем — я, пожалуй, подожду, пока NoSQL сумеет в TPC-C занять хоть какое-то место. Тогда можно будет сравнивать перформанс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 не справились в наших руках, ни у кого не хватило квалификации.
Реально такие задачи решаются полнотекстовым поиском.
Здравствуйте, gandjustas, Вы писали:
G>Реально такие задачи решаются полнотекстовым поиском.
Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Реально такие задачи решаются полнотекстовым поиском.
M>Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.
Что ты имеешь ввиду "проще самому пошагово рассказать"?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>С чего там ошибка? В каком месте?
ANS>Я ж написал "SQLState 40001". Дедлок или что там. С чего он вылетает и в каком месте? Вот я и спрашиваю, как платформа себя с ним ведёт.
в 8 ке блокировки проталкивает на верх которые могут быть например при установлении блокировок на записи или при интенсивных изменениях индекса.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
M>>Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.
G>Что ты имеешь ввиду "проще самому пошагово рассказать"?
На моем компе дома шахматный движок считает 7 000 000 позиций в секунду на одном ядре. Мне проще написать на C++ алгоритм поиска по SHM, чем мучится настраивая полнотекстовые индексы, полнотекстовый поиск и т. п. чтобы считалось так, как я хочу, и быстро.
эх, не сдержался.
G>Ты мешаешь много факторов в одну кучу, не понимая как каждый и них в отдельности влияет на полную картину.
а что тут не понятного, люди во всю ищут альтернативу.
G>1) Для надежности master-master репликация не нужна, она может понадобится для LB и\или локальности.
Персонально я этой штуке применения вообще не вижу. я тебе указываю для чего её пытаются другие применять.
G>2) Без memcached отлично работает. Вот stackoverflow долгое время без кешей работал. Только через год они начали кеши использовать.
я так и думал, что всё настолько хорошо работает на голом SQL, что SO прикрутил кеши для той же причины, что и колонны в греческих храмах — для красоты
G>3) Lazy кеш надо использовать очень осторожно, он людям не нравится. Те кто используют его везде — неправильно делают.
G>4) Если есть распределенный кеш, то поддерживать его когерентность совсем несложно.
Это один из ключевых моментов. ты считаешь, что это легко и нет проблем, а на самом деле, во многих случаях многие ослабления гарантий растут именно из этого "беспроблемного" места.
G>>>С чего там ошибка? В каком месте? ANS>>Я ж написал "SQLState 40001". Дедлок или что там. С чего он вылетает и в каком месте? Вот я и спрашиваю, как платформа себя с ним ведёт. S>в 8 ке блокировки проталкивает на верх которые могут быть например при установлении блокировок на записи или при интенсивных изменениях индекса.
"на верх" это в прикладной уровень и разруливать там вручную нужно? и какая общая практика, чтобы у бухов крышу не сносило? "забить" или что-то более интеллектуальное?
ANS>"на верх" это в прикладной уровень и разруливать там вручную нужно? и какая общая практика, чтобы у бухов крышу не сносило? "забить" или что-то более интеллектуальное?
Вот такого плана
Ошибка при вызове метода контекста (Заблокировать): Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки из-за ожидания сессии 16972
Народ понимает плохо
и солнце б утром не вставало, когда бы не было меня
Ошибка выполнения запроса: Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Превышено время ожидания запроса на блокировку.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=33, Severity=10, native=1222, line=1
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Serginio1, Вы писали:
S>> Народ понимает плохо
ANS>Т.е. "забить". я об этом и говорил, что пишут, что "проблем нет, рестартонул и всё", а по факту пользователь сидит и репу чешет.
ANS>А мне потом еще рассказывают, что они мол о пользователях заботятся, а я их гноблю.
Вообще при таких ошибках можно былобы предусмотреть перезапуск транзакции. Либо приходится самому делать цикл, обрабатывая текст ошибки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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>Это один из ключевых моментов. ты считаешь, что это легко и нет проблем, а на самом деле, во многих случаях многие ослабления гарантий растут именно из этого "беспроблемного" места.
Я тебе уже писал как это разруливается. Запись идет сразу в базу, кеш сбрасывается и обновляется при первом обращении или прямо после записи.
В случае распределенного кеша ничего не нарушается.
Обращение к кешу идет только когда надо вывести данные. На основе данных из кеша логика, изменяющая данные не работат.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Задачи связанные, но не совсем. Sphinx некоторое время работал, потом от него отказались. Основная проблема в том, что в таких случаях проще самому пошагово рассказать, как надо искать, в каком порядке что делать, чем пытаться заставить другой движок заточить под эти требования.
G>>Что ты имеешь ввиду "проще самому пошагово рассказать"?
M>На моем компе дома шахматный движок считает 7 000 000 позиций в секунду на одном ядре. Мне проще написать на C++ алгоритм поиска по SHM, чем мучится настраивая полнотекстовые индексы, полнотекстовый поиск и т. п. чтобы считалось так, как я хочу, и быстро.
Причем тут твои шахматы? Мы про поиск статей по тегам\авторам\другим_атрибутам говорили. Что значит "проще самому пошагово рассказать"
Здравствуйте, gandjustas, Вы писали:
G>Причем тут твои шахматы? Мы про поиск статей по тегам\авторам\другим_атрибутам говорили. Что значит "проще самому пошагово рассказать"
При том, что даже тупой перебор миллиона вариантов (записей) не должен быть проблемой для современных компов. Но, часто, это проблема для SQL
G>Я тебе уже писал как это разруливается. Запись идет сразу в базу, кеш сбрасывается и обновляется при первом обращении или прямо после записи. G>В случае распределенного кеша ничего не нарушается.
Оно и в случае локального кеша нарушается, а при распределённом тем более. Я тебе указывал на ошибку (ссылку не даю, потому что тебя это беспокоит) — ты рассматриваешь последовательности "запись — сброс" и "вычитка — обновление", как атомарные и строго упорядоченные. По факту они не только не атомарные, но и могут "переупорядочиваться".
G>Обращение к кешу идет только когда надо вывести данные. На основе данных из кеша логика, изменяющая данные не работат.
Достаточно того, что пользователь левые данные 15 минут видит.
G>Где тут ослабление гарантий?
предыдущая беседа на эту тему началась с того, что никому распределённые системы не нужны, а значит CAP-теорема не актуальна.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Причем тут твои шахматы? Мы про поиск статей по тегам\авторам\другим_атрибутам говорили. Что значит "проще самому пошагово рассказать"
M>При том, что даже тупой перебор миллиона вариантов (записей) не должен быть проблемой для современных компов. Но, часто, это проблема для SQL
Перебор не проблема. Считывание с диска — проблема. Именно это и оптимизируют базы.
Ведь 1,000,000 статей, каждая хотябы по 1 кб размером — гиг данных. База умудряется искать статьи по автору за доли секунды. Напиши перебор, который так же быстро сработает.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Я тебе уже писал как это разруливается. Запись идет сразу в базу, кеш сбрасывается и обновляется при первом обращении или прямо после записи. G>>В случае распределенного кеша ничего не нарушается.
ANS>Оно и в случае локального кеша нарушается, а при распределённом тем более. Я тебе указывал на ошибку (ссылку не даю, потому что тебя это беспокоит) — ты рассматриваешь последовательности "запись — сброс" и "вычитка — обновление", как атомарные и строго упорядоченные. По факту они не только не атомарные, но и могут "переупорядочиваться".
И что? Оно на логику не повлияет. Кеш это только оптимизация, за счет того что пользователь может увидеть слегка старые результаты, но так как результаты запроса сразу устаревают после считывания из базы, то клиент ниче не теряет.
А если нужны гарантии, то кеш идет лесом и используются транзакции.
До сих пор не понял? В SQL такое всегда можно сделать. А вот в NoSQL системах внутри всякие кеши используются, асинхронные обновления индексов и другие ненадежные вещи, которые слабо контролируются снаружи.
G>>Обращение к кешу идет только когда надо вывести данные. На основе данных из кеша логика, изменяющая данные не работат. ANS>Достаточно того, что пользователь левые данные 15 минут видит.
15 минут? Этож как такой брен написать надо.
Ты вот на форуме видишь старые данные? А кеши скорее всего используются.
G>>Где тут ослабление гарантий? ANS>предыдущая беседа на эту тему началась с того, что никому распределённые системы не нужны, а значит CAP-теорема не актуальна.
CAP ни о чем, оно рассматривает внешнюю систему как черный ящик. Если отказаться от идеи "черного ящика", то все гораздо проще.
Ты ведь тоже самое говоришь про NoSQL.
Здравствуйте, gandjustas, Вы писали:
G>Я думаю у гугла на 30 млн транзакций в минуту приходится гораздо больше железа. Там ведь не запросы чтения данных считают.
Да, безусловно железа больше. И что?
G>В SQL создание индексов заняло около 10 секунд. Сделал drop и create
Протестировал. Получилось 4,9 секунды создание индекса.
_>>Ну так это и есть стиль nosql. ))) То самое, что Sinclair критиковал. G>Это чревато перекачкой большого объема данных из базы в приложение.
Согласен. Тут уже всё зависит от квалификации разработчика...
_>>Кстати, в данном примере у нас медленный Питон... А вот если бы я на C++ аналогичный код написал бы (кстати выглядело бы так же — в STL же тоже есть операции с множествами), да ещё и со всеми оптимизациями... G>Не думаю что разница превысила бы 10%
Не факт. Я же не про алгоритмы говорю и даже не про то что у C++ лучший оптимизирующий компилятор. Я про представление данных... Скажем представление id в виде строки, в виде 12 байтного числа и в виде указателя на объект будут очень сильно различаться на операции сравнения, которая в данном случае чаще всего и вызывается. Так что не исключено очень существенное увеличение быстродействия, но это надо конкретно детали смотреть уже — естественно я это не буду делать.
Но собственно говоря это всё и не нужно, т.к. и на медленном Питоне оно быстрее sql варианта — куда там ещё оптимизироваться то...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Serginio1, Вы писали:
S>> Народ понимает плохо
ANS>Т.е. "забить". я об этом и говорил, что пишут, что "проблем нет, рестартонул и всё", а по факту пользователь сидит и репу чешет.
Отлови ошибку по коду, и покажи пользователю сообщение "повторите еще раз". А если внутри кода можешь ошибку разрулить, то сам повтори вызов.
Здравствуйте, Sinclair, Вы писали:
S>А гугл и не подавал никогда. S>И я так думаю, что в TPC-C у гугла не больше шансов, чем у прочих. Их технология разработана не совсем для этого случая.
Ну я может не особо разобрался что там за рейтингм, так посмотрел только цифры по ссылкам. Но в любом случае мне кажется что как раз технология гугла перспективнее в любых применениях. Так что может рейтинг отражает уже не актуальные параметры? )
S>Тогда бы мы получили полную противоположность декларируемым преимуществам NoSQL — высокий порог вхождения и массовые забеги с напильником для получения приемлемого быстродействия, вместо того, чтобы за 20 минут накидать базу на SQL Express, а масштабировать — потом, когда у проекта будут деньги на это.
Ох,у меня такое впечателение что я постоянно говорю одно, а все вокруг слышат другое. Я же вроде несколько раз в этой теме говорил что как раз у nosql всегда был высокий порог вхождения. В отличие от sql, где мы придумали запросец и всё — дальше "база там как-то сама оптимально всё выполнит". А только в последние годы порог nosql стал снижаться до уровня удобной и простой работы. И соответственно сразу туда повалил народ.
Ну и кстати по моему примеру вроде как видно насколько продвинулись в этом. Он просто несравнимо короче и проще диких и страшных запросов с кучей join. Про xml схему базы я вообще молчу.
Здравствуйте, 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 варианта — куда там ещё оптимизироваться то...
Я питон так и не поставил, поэтому сравнить не могу.
Здравствуйте, Sinclair, Вы писали:
S>А вы уверены, что всё честно посчитали на стороне NoSQL? У TPC-C — очень жёсткие критерии подсчёта стоимости. Например, туда входит стоимость клиентских машин. Ваше NoSQL решение, надо полагать, их тоже учитывает? Учитывается ли стоимость поддержки на срок 3 года? S>Посмотрите спецификации на TPC-C, попробуйте рассчитать стоимость NoSQL варианта с аналогичной производительностью. Необязательно брать сразу два миллиона TpMc, возьмите что-нибудь маленькое, тысяч на двадцать, и посмотрите в прайс. Там очень подробно расписано — сколько стоит железо, сколько диски, сколько сеть, сколько лицензии — и так далее. Попробуйте найти способ сэкономить.
Что-то у вас какие-то странные представления о бизнесе, как будто бы там деньги девать некуда. Если у меня вдруг проект упрётся в базу данных (такого ещё не было кстати, но это просто потому что у нас другой профиль деятельности), то я просто арендую в том же датацентре ещё пару соседних серверов и раскидаю базу по ним. А тех денег с вашего "маленького решения" хватит лет на 10 аренды. Про первые две ссылки я вообще молчу — там просто цифры уникальные. )))
Здравствуйте, gandjustas, Вы писали:
G>Перебор не проблема. Считывание с диска — проблема. Именно это и оптимизируют базы. G>Ведь 1,000,000 статей, каждая хотябы по 1 кб размером — гиг данных. База умудряется искать статьи по автору за доли секунды. Напиши перебор, который так же быстро сработает.
Считывание в диска не проблема, все помещается в RAM, всего около 5 гиг.
На миллионе статей простой поиск по одному фильтру без индексов по памяти как раз за доли секунды выполняется в один поток.
Здравствуйте, gandjustas, Вы писали:
G>Ну то что с бесплатным NoSQL ты в том не попадешь, а если попадешь, то цена на транзакцию большая выйдет.
Вообще если брать простенькие сервера из мейнстрима, то несколько штук их будет стоить дешевле чем аналогичная их сети одна машина.
G>>>В SQL создание индексов заняло около 10 секунд. Сделал drop и create _>>Протестировал. Получилось 4,9 секунды создание индекса. G>У меня 60 секунд создавался на 100,000 статей по 10 тегов в каждой.
Ммм, не понял, это в какой базе?
G>Квалификация не при чем. Два предиката могут давать очень большие множества, но пересечение их будет пусто. СУБД используют статистику по индексам чтобы в первую очередь получать записи по тем предикатам, которые возвращают меньше всего.
Так мы же работаем под конкретную задачу — разработчик должен знать все нюансы и подбирать решение под неё. В отличие от универсальных алгоритмов sql субд, которые хороши в среднем везде.
G>Я питон так и не поставил, поэтому сравнить не могу.
Могу накидать краткую инструкцию со ссылками. Там делов на минуту)
Здравствуйте, alex_public, Вы писали:
_>Что-то у вас какие-то странные представления о бизнесе, как будто бы там деньги девать некуда. Если у меня вдруг проект упрётся в базу данных (такого ещё не было кстати, но это просто потому что у нас другой профиль деятельности), то я просто арендую в том же датацентре ещё пару соседних серверов и раскидаю базу по ним. А тех денег с вашего "маленького решения" хватит лет на 10 аренды. Про первые две ссылки я вообще молчу — там просто цифры уникальные. )))
Ну так то же самое касается и SQL решения. Или вы думаете, что арендовать можно только для NoSQL?
Насчёт 10 лет — что-то я сомневаюсь. Я не знаток рынка аренды серверов, но мне как-то странно. Зачем бы хостеру покупать сервер за $XXXXX баксов, а потом сдавать его в аренду по цене 1/120 от покупной цены? Ведь у него срок службы — от силы лет пять, а в аренду входит помимо самой железки ещё и электричество и охлаждение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Вообще если брать простенькие сервера из мейнстрима, то несколько штук их будет стоить дешевле чем аналогичная их сети одна машина.
1. Что вы называете "простеньким сервером из мейнстрима"?
2. Можно пруф на соотношение цен одной коробки и эквивалентной пачки коробок?
_>Так мы же работаем под конкретную задачу — разработчик должен знать все нюансы и подбирать решение под неё. В отличие от универсальных алгоритмов sql субд, которые хороши в среднем везде.
Дупа в том, что разработчик должен не только быть суперквалифицированным, но ещё и невероятно прозорливым. Заранее придумать нужные структуры данных и угадать, где именно будет узкое место. Т.к. "планы запросов" намертво вшиты в код приложения, лёгким манием руки поменять их "на лету" не выйдет.
Вот тут ссылочка пробегала в текущую темку в базах данных, где у парня внезапно сменился план запроса и index scan превратился в index seek. Это как раз типичный пример late optimization. Если бы задачу решал программист и вручную, то был бы велик риск того, что он бы заложился на index scan, который оказывался оптимальнее на тестовых данных. А потом было бы поздно пить боржоми, т.к. смена плана запроса — это переделка приложения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Ну я может не особо разобрался что там за рейтингм, так посмотрел только цифры по ссылкам. Но в любом случае мне кажется что как раз технология гугла перспективнее в любых применениях. Так что может рейтинг отражает уже не актуальные параметры? )
Этот рейтинг — он как рейтинг на RSDN. В начале легко попасть в top-10, но все дальнейшие победы требуют всё больших вложений.
Поэтому мне, к примеру, понятна неготовность условно-бесплатных решений к инвестициям в эксперимент, который поставит их на 2400 строчку в табели о рангах (хотя, если у них всё так здорово, можно было бы посоревноваться не в tpmC, а в tpmc/$)ю
А вот с ресурсами гугла поставить эксперимент стоимостью в полсотни миллионов — вполне реально. Тем более у них железа дохрена, так что покупать не обязательно — можно на пару дней занять из собственных запасов.
_>Ох,у меня такое впечателение что я постоянно говорю одно, а все вокруг слышат другое. Я же вроде несколько раз в этой теме говорил что как раз у nosql всегда был высокий порог вхождения. В отличие от sql, где мы придумали запросец и всё — дальше "база там как-то сама оптимально всё выполнит". А только в последние годы порог nosql стал снижаться до уровня удобной и простой работы. И соответственно сразу туда повалил народ.
Ну, это просто радикально расходится с тем, что говорят все остальные апологеты NoSQL. Вот, тут же в топике давали ссылку на статьи на хабре и не только, где основная идея — "мне не надо думать над структурой базы, и не надо бояться, что при росте нагрузки я упрусь в ограничения".
_>Ну и кстати по моему примеру вроде как видно насколько продвинулись в этом. Он просто несравнимо короче и проще диких и страшных запросов с кучей join. Про xml схему базы я вообще молчу.
Ну, это ещё как посмотреть. Запросы с join я хотя бы прочесть могу. Хотя с точки зрения компактности претензий нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну так то же самое касается и SQL решения. Или вы думаете, что арендовать можно только для NoSQL?
Эм, так предположим что у нас старшая конфигурация сервера в обычном (и поэтому по нормальным деньгам) дата-центре. Если мы выросли из него, то нам получается надо переходить в другой дата-центр (где есть более мощные серверы) или покупать свой. А случае nosql мы просто арендуем рядом ещё пару таких же и всё.
Собственно единственной альтернативой такого масштабирования сейчас являются облака — там даже проще, хотя и деньги идут по другому. Но у них есть ограничение сверху. Т.е. в определённых границах это хорошая альтернатива, но начиная с некоторых нагрузок уже не подходят.
S>Насчёт 10 лет — что-то я сомневаюсь. Я не знаток рынка аренды серверов, но мне как-то странно. Зачем бы хостеру покупать сервер за $XXXXX баксов, а потом сдавать его в аренду по цене 1/120 от покупной цены? Ведь у него срок службы — от силы лет пять, а в аренду входит помимо самой железки ещё и электричество и охлаждение.
Имелось в виду что сервера разные (как раз то, про что писали в след. сообщение).
Здравствуйте, Sinclair, Вы писали:
S>1. Что вы называете "простеньким сервером из мейнстрима"?
То что в данный момент предлагают хостеры по основным тарифам. Они как раз не дураки и обычно используют самые экономичные решения.
S>2. Можно пруф на соотношение цен одной коробки и эквивалентной пачки коробок?
Не выйдет так точно оценить. Потому что проблематично оценить эквивалентность без прямого иследования конкретных моделей. Ведь нам же тогда надо ставить базы данных туда и туда, нагружать и т.п. Лично я такого никогда не делал, так что болтать попросту не буду. Но в целом масштабы видны — слишком во много раз цены на топовые серверы больше обычных.
S>Дупа в том, что разработчик должен не только быть суперквалифицированным, но ещё и невероятно прозорливым. Заранее придумать нужные структуры данных и угадать, где именно будет узкое место. Т.к. "планы запросов" намертво вшиты в код приложения, лёгким манием руки поменять их "на лету" не выйдет. S>Вот тут ссылочка пробегала в текущую темку в базах данных, где у парня внезапно сменился план запроса и index scan превратился в index seek. Это как раз типичный пример late optimization. Если бы задачу решал программист и вручную, то был бы велик риск того, что он бы заложился на index scan, который оказывался оптимальнее на тестовых данных. А потом было бы поздно пить боржоми, т.к. смена плана запроса — это переделка приложения.
Ага, всё так и есть. Никто и не говорит что всё идеально. Но лично меня подобное не пугает. Доработка проекта всё равно обычно происходит.
Здравствуйте, Sinclair, Вы писали:
_>>Ох,у меня такое впечателение что я постоянно говорю одно, а все вокруг слышат другое. Я же вроде несколько раз в этой теме говорил что как раз у nosql всегда был высокий порог вхождения. В отличие от sql, где мы придумали запросец и всё — дальше "база там как-то сама оптимально всё выполнит". А только в последние годы порог nosql стал снижаться до уровня удобной и простой работы. И соответственно сразу туда повалил народ. S>Ну, это просто радикально расходится с тем, что говорят все остальные апологеты NoSQL. Вот, тут же в топике давали ссылку на статьи на хабре и не только, где основная идея — "мне не надо думать над структурой базы, и не надо бояться, что при росте нагрузки я упрусь в ограничения".
Так то что "мне не надо думать что я потом куда-то упрусь" — это я отношу к преимуществу эксплуатации, а не разработки. Т.е. разрабатывать nosql сложнее (ну точнее раньше было, сейчас уже не факт и даже на оборот бывает), но потом при эксплуатации уже больше ни о чём голова не болит.
Здравствуйте, alex_public, Вы писали:
_>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где nosql обсуждалось не с точки зрения их классических преимуществ держать нагрузку и масштабироваться, а именно с точки зрения программиста. Сейчас поищу... А, вот http://rainman-rocks.livejournal.com/120682.html
Потратил 2 мин., прочитал. Автор этой статьи должен мне две минуты своей жизни, потому как это очередной бред, не имеющий никого отношения к процессу разработки с применением БД. noSQL имеют определенные преимущества перед rdbms, но конечно они выражены не в том что цитирую автора "совершенно обычные, привычные каждому программисту списки в реляционных БД искажены до неузнаваемости и хранятся в неявном виде, где-то в индексах." (что это вообще за бред ).
Здравствуйте, a_g_99, Вы писали: __>noSQL имеют определенные преимущества перед rdbms, но конечно они выражены не в том что...
О... А в чем он вообще имеет преимущества, кроме [полу]объектной модели?
Нет, я серьезно. Насколько я понимаю, индексы noSQL это какая-то реализация материализированных вьюх. И чё? Я вьюху в SQL не могу создать? Какие там вообще преимущества в нагрузке и производительности могут быть? Ну, хотя-бы, в теории?
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sinclair, Вы писали:
S>>1. Что вы называете "простеньким сервером из мейнстрима"?
_>То что в данный момент предлагают хостеры по основным тарифам. Они как раз не дураки и обычно используют самые экономичные решения.
Здравствуйте, alex_public, Вы писали:
_>Эм, так предположим что у нас старшая конфигурация сервера в обычном (и поэтому по нормальным деньгам) дата-центре. Если мы выросли из него, то нам получается надо переходить в другой дата-центр (где есть более мощные серверы) или покупать свой. А случае nosql мы просто арендуем рядом ещё пару таких же и всё.
Здравствуйте, Ромашка, Вы писали:
Р>Нет, я серьезно. Насколько я понимаю, индексы noSQL это какая-то реализация материализированных вьюх. И чё? Я вьюху в SQL не могу создать?
Р>Какие там вообще преимущества в нагрузке и производительности могут быть? Ну, хотя-бы, в теории?
Может стоит почитать тему, перед тем, как писать? )
Здравствуйте, _ABC_, Вы писали:
_AB>Давайте без общих слов и на конкретных примерах. Что вылезло из гугла по запросу dedicated hosting: _AB>http://www.server4you.com/root-server/
Отличный примерчик. Я когда писал, то имел в виду даже чуть более дорогие решения (ну по своему опыту). А эти я смотрю не сильно хуже (хотя raid софтверный, память не ecc, opteron, а не xeon), а при этом ещё в 2 раза дешевле.
_AB>Что из этого простенькое из мейнстрима, а что сложненькое. Сколько простеньких заменяют одного сложненького?
Всё Pro Server по ссылке выглядят подходящими предложениями. А вот сколько их надо для замены одной из мегамашинок обсуждаемых выше — трудно сказать, т.к. это существенно зависит от софта. Т.е. при сравнение разных баз данных будут разные цифры. Надо смотреть конкретно. Но если взглянуть на цены (70 баксов/месяц!), то там их стооооооолько можно набрать...
Здравствуйте, Ромашка, Вы писали:
Р>Я тред прочитал от ушей и до хвоста. По теме замечания будут?
В этой теме уже были прямые ответы именно на вопрос о "преимуществах в нагрузке и производительности ". Собственно только это и обсуждали, поскольку первоначальное сообщение про "естественность для программиста" было скорее ради забавы в теме про DSL, а здесь уже обсуждение пошло про вообще nosql и по серьёзному. Так что какое-то странное прочтение было. Да, и никто специально повторять по второму кругу это не будет.
_>О, помнится я пару лет назади видел забавную статейку как раз на эту тему. Т.е. где 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 такого не предоставляет и предоставить не может.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, _ABC_, Вы писали:
_AB>>А что мешает с РСУБД сделать так же?
_>Шардинг sql баз? ) Вы сторонник садо-мазо? )))
Зачем шардинг обязательно? Если я вопрусь в ограничения по железу, то у меня есть много вариантов разнесения нагрузки. Только я и вопрусь позже, чем nosqlщики и времени на подумать у меня будет намного больше.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Перебор не проблема. Считывание с диска — проблема. Именно это и оптимизируют базы. G>>Ведь 1,000,000 статей, каждая хотябы по 1 кб размером — гиг данных. База умудряется искать статьи по автору за доли секунды. Напиши перебор, который так же быстро сработает.
M>Считывание в диска не проблема, все помещается в RAM, всего около 5 гиг.
M>На миллионе статей простой поиск по одному фильтру без индексов по памяти как раз за доли секунды выполняется в один поток.
Как раз считывание — проблема. Потому что оно идет долго. Ты от даже не пытался померить сколько оно займет. Любая серьезная база будет иметь объем больше ОП сервера и то что ты написал не подойдет.
Здравствуйте, 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. Там нету множеств и пересечений.
G>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000. G>Полнотекстовый поиск не использовать.
Здравствуйте, alex_public, Вы писали: _>В этой теме уже были прямые ответы именно на вопрос о "преимуществах в нагрузке и производительности ".
Не было тут ответов по производительности и нагрузке. Тут было подтасовывание фактов -- выборка происходит быстрее. Черт с ним, я могу насоздавать материализованных вьюх, которые будут обеспечивать точно такую же скорость выборки: O(log n). Скорость инсертов капитально просядет. Я понимаю почему. Я одного не понимаю, откуда в noSQL вдруг возьмется большая производительность, если в noSQL придется перестраивать как минимум столько же вьюх/индексов?
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, 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.
Здравствуйте, Enomay, Вы писали:
G>>Задача простая — поиск статей по тегам. База статей: 100,000 статей, к ним привязано любое количество тегов, нужно найти все статьи с 3 произвольными тегами. Всего разных тегов 100, связей тегов со статьями 1,000,000. G>>Полнотекстовый поиск не использовать.
E>250-300 мс. 8 гигов памяти. проц 5ти летней давности E6850.
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, alex_public, Вы писали: _>>В этой теме уже были прямые ответы именно на вопрос о "преимуществах в нагрузке и производительности ".
Р>Не было тут ответов по производительности и нагрузке. Тут было подтасовывание фактов -- выборка происходит быстрее. Черт с ним, я могу насоздавать материализованных вьюх, которые будут обеспечивать точно такую же скорость выборки: O(log n). Скорость инсертов капитально просядет. Я понимаю почему. Я одного не понимаю, откуда в noSQL вдруг возьмется большая производительность, если в noSQL придется перестраивать как минимум столько же вьюх/индексов?
В среднем SQL + кеш + полнотекстовый индекс (внешний) будет выигрывать у NoSQL. NoSQL рулит только в получении по ключу при небольшом количестве записей.
С современных веб-проектах, особенно где не требуются гарантии сохранности данных, можно около 80% сценариев свести к получению по ключу. Остальное делать через map-reduce индексы. Вот только это требует гораздо больших усилий со стороны разработчика и гораздо проще сделать все неправильно. Хоть при этом и не надо понимать нормальные формы и реляционную алгебру, все равно для NoSQL требуется больше умений.
Так что я вообще не вижу где можно использовать NoSQL кроме самых простых проектов. Ну и обсуждения в интернетах показываю что основная аудитория nosql — те кто sql ниасилил и теперь их проекты хоть как-то работают на nosql.
Здравствуйте, 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.
В целом да, статья "ненаучная" и люди выбирают 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 вообще не проблема. Весь вопрос в том, какая скорость у этого будет.
Здравствуйте, _ABC_, Вы писали:
_AB>Зачем шардинг обязательно? Если я вопрусь в ограничения по железу, то у меня есть много вариантов разнесения нагрузки.
OK. Какие ещё варианты разнесения на десяток машин базы данных? Можно пример как это делается с sql базами? С nosql я пример уже привёл в этой темке.
_AB> Только я и вопрусь позже, чем nosqlщики и времени на подумать у меня будет намного больше.
Здравствуйте, gandjustas, Вы писали:
G>Что-то слабо верится. Расчеты какиенить приведи со ссылкой на вендора.
Да вроде все ссылки по ценам уже были здесь. Осталось только научиться вычислять сети из скольких простеньких машин равносилен один суперсервер. Я сразу говорю что не представляю как оценить — только провести эксперимент... ) Но судя по ценам там ТАКОЙ запас возникает, что... )))
G>Ну то есть нужно на более низком уровне работать, руками выполняя то что делает РСУБД автоматом. Тут некоторые пытаются сказать что NoSQL как раз более высокий уровень абстракции дает.
Согласен. Не знаю с чего тут некоторые говорят такое. По алгоритмам нет вопросов — более низкий уровень. А вот смысле организации данных... В nosql возможен более объектный подход, который автоматом кое-какие мелочи включает (ну вот как в примере нашем: там тэги и статья — по сути единая сущность). Но в целом согласен.
G>Лучше скрипт сразу. Встроенный язык shell — javascript. Там нету множеств и пересечений.
Брррр, если можно писать на красивом языке, то зачем делать это на ужасном? )
Здравствуйте, 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. подозреваю что накладка в десериализации объектов.
Здравствуйте, Ромашка, Вы писали:
Р>Не было тут ответов по производительности и нагрузке. Тут было подтасовывание фактов -- выборка происходит быстрее. Черт с ним, я могу насоздавать материализованных вьюх, которые будут обеспечивать точно такую же скорость выборки: O(log n). Скорость инсертов капитально просядет. Я понимаю почему. Я одного не понимаю, откуда в noSQL вдруг возьмется большая производительность, если в noSQL придется перестраивать как минимум столько же вьюх/индексов?
Вроде бы же ясно сказали, что преимущество возникает когда мы упираемся в рамки одной машины. У sql баз тут сразу дикие ужасы. А у nosql всё автоматом из коробки работает. Когда-то раньше разработка под nosql была заметно сложнее, соответственно для большинства проектов было глупо использовать nosql на ранних стадиях — ещё не известно понадобится ли масштабирование в принципе или нет. Но в последнее время с современными инструментами разработка под nosql стала не особо сложнее slq решений. И соответственно уже появляется смысл заложить автоматическое масштабирование на будущее, т.к. это практически бесплатно становится.
Что касается сравнения скорости работы в рамках одной машины, то тут уже совсем другая картина и всё зависит от конкретной задачи. Т.е. частенькой (особенно в веб-проектах) nosql ускоряет и тут, но только из-за особенности задачи, а не то что такое преимущество заложено (как в ситуации, когда мы переходим на несколько машин) в сами основы.
Теперь понятно? И между прочим всё это уже было высказано в теме.
Здравствуйте, 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. Система оплаты с облаком (если оно не своё) частенько бывает менее выгодной, чем свой сервер.
Здравствуйте, gandjustas, Вы писали:
G>Как раз считывание — проблема. Потому что оно идет долго. Ты от даже не пытался померить сколько оно займет. Любая серьезная база будет иметь объем больше ОП сервера и то что ты написал не подойдет.
Информация, которая нужна для хитрого поиска, у нас помещается в ОЗУ с большим запасом: 5G / 64G ~= 8%. А другие теоретические задачи меня не интересуют. Там где нужна транзакционность, там используется как раз SQL.
M>>И это все фигня
_>В целом да, статья "ненаучная" и люди выбирают nosql естественно не за какую-то "приятность для программиста". Но всё же ней что-то есть... Например при попытке засунуть в sql базу иерархию произвольной вложенности с возможностью обхода по дереву, мысль о неестественности таких баз возникает сама собой. )))
О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается
Здравствуйте, 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.
Здравствуйте, 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.
Под своим серверов подразумевается и аренда. ) Я имел в виду именно разницу в принципе оплаты: по месяцам или по тактам. Бывают задачи в которых выгоднее как один принцип, так и другой.
Здравствуйте, 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 делает масштабирование гораздо выгоднее.
Здравствуйте, 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% покупной цены. Так что, как видите, не стоит переоценивать преимущества маленьких коробок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G>>>так подними 30 млн. транзакций в минуту на NoSQL, в чем вопрос? Возьми первое место в TPC-C >>А там вообще результаты от сетей компьютеров (не кластеров) принимают? ) G>Я думаю принимают.
Собственно, указанный результат на 30 млн. транзакций в минуту — он как раз для кластерных решений.
Только надо еще помнить, что TPC-C — это полная реализация бизнес-логики (на уровне БД), т.е. надо сравнивать не только с NoSQL движком, а с всем комплексом из БД и бизнес-логики на сервере приложения.
Ну и если для относительно монолитных систем в TPC-C стоимость сетевой инфраструктуры еще можно опустить, для сетки из 1000 дешевых машинок стоимость инфраструктуры окажется уже сравнима со стоимостью самих машинок
Замечательные статьи. Честно говоря, я уже давно думаю, что сотрудников, читающих хабр без смеха надо увольнять, но получить сразу такую коллекцию подтверждений.
Человек не понимает, ни как работает Mongo, ни как работает SQL и даже не понимает, что его решение задачи "Яндекс.Маркета" на Mongo — полностью эквивалентно его же (неправильному) решению для РСУБД — но пишет про mongo и sql.
Впрочем, заглавная статья из LJ — тоже то еще сборище глупостей (хм, одна только мысль, что работа со списком имеет константное время уже позволяет не читать дальше).
В использовании нереляционных хранилищ есть несколько осмысленных идей, но вот пока их будут пропагандировать, гм, не слишком опытные программисты — то и отношение будет к ним соответствующее
P.S. Практически все прелести mongo (включая шардинг) делаются где-то за день-два на любой реляционной базе (оставляя в живых ACID, но прощаясь с гарантиями целостности, разумеется).
Здравствуйте, Mamut, Вы писали:
M>О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается
Ну, на практике графов, не влезающих в память довольно мало, делать для них движки смысла нет, проще писать конкретное решение. А если влезают — то и не шибко важно, как его хранить в persistance
Ну, может, что-нибудь из решений для хранения социальных графов для сетей — и выйдет в open-source...
Здравствуйте, Ромашка, Вы писали: Р>О... А в чем он вообще имеет преимущества, кроме [полу]объектной модели?
В идеальном мире 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 .
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Ромашка, Вы писали:
Стоит посмотреть на чемпиона TPC-C Oracle 11g DB, мин. требования вряд ли вам покажутся мягкими (как и цена) по сравнению напр. с tokyo cabinet.
Хм, минимальные требования для минимального Oracle на самом деле выглядят так — "любой не очень старый компьютер". Цена при этом, разумеется, нулевая (да-да, у Oracle есть бесплатные редакции). Более того, требования у TokyoCabinet жестче, так как требуется *nix, а Oracle можно запустить и под Windows.
Ну и, конечно, есть и opensource РСУБД и встраиваемые РСУБД — на любой вкус.
Так что если и искать преимущества NoSQL — то в другом месте.
M>>О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается
ДФ>Ну, на практике графов, не влезающих в память довольно мало, делать для них движки смысла нет, проще писать конкретное решение. А если влезают — то и не шибко важно, как его хранить в persistance
Ну, вообще-то это не так. Ведь базы данных, которые в память не помещаются, откуда-то берутся? А любая реляционная база данных содержит в себе, по сути, графы (пусть и не всегда глубокие).
ДФ>Ну, может, что-нибудь из решений для хранения социальных графов для сетей — и выйдет в open-source...
Ну, граф-базы данных есть, и в опенсорсе в том числе — Neo4J, HyperGraphDB, OrientDB и т.п. Есть даже расширение для SQL под названием SPARQL для этих баз данных. Или там набор библиотек от TinkerPop'а. Но всем этим, правда, занимается полтора человека, и у всех проблемы — что делать с масштабируемостью, потому что никто не имеет представления, как разносить графы по нескольким машинам
Здравствуйте, Дельгядо Филипп, Вы писали: ДФ>Хм, минимальные требования для минимального 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). Самому интересно
Здравствуйте, Enomay, Вы писали:
G>>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.
E>Фактически, ты говоришь глупости.
Здравствуйте, a_g_99, Вы писали:
>>Цена при этом, разумеется, нулевая (да-да, у Oracle есть бесплатные редакции) __>Использовать такой продукт можно только в учебных или демонстрационных целях. Мейджор и консалтеры рядом своего не упустит. Это касается не только тройки, но "бесплатных" младших братьев типа MySQL (посм. на Percona). A noSQL бесплатен как не крути.
С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях?
Кроме того, PosеgreSQL, Firebird бесплатны со всех сторон, например.
__>Приведите примеры. Так чтобы это было бесплатно, не хлам типа Ingres DB, не сырой MariaDB от пупкин-софт с норм. производительностью, драйверами для мейнстрима + кроссплатформенность (win + unix). Самому интересно
Смотри выше.
Производительность нормальная, дрова вроде бы тоже есть и с кроссплатформенностью (хотя к чему она при нетиражируемом решении я не пойму) тоже все в порядке. Сам не пользовал, но читал про сотни внедрений и продуктов, построенных на основе этих СУБД и у многих проблем с нехваткой нагрузки нет. А про сколько внедрений я еще не слышал.
Я вообще не понимаю, откуда вы выкапываете всякие марииДБ и прочий хлам, про которой в мире СУБД почти никто слыхом не слыхивал, и упорно игнорируете если не лидеров в своих сегментах, но весьма и весьма известные вещи.
G>>>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.
E>>Фактически, ты говоришь глупости.
G>Да что ты? Покажи где по-другому.
NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.
Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.
Здравствуйте, 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.
Здравствуйте, Enomay, Вы писали:
E>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю. E>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.
Т.е. я могу уложить биллинг, бухгалтерию, или другую задачу финансового учета в NoSQL и он будет работать так же надежно как с СУБД, но быстрее?
E>>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю. E>>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее. _AB>Т.е. я могу уложить биллинг, бухгалтерию, или другую задачу финансового учета в NoSQL и он будет работать так же надежно как с СУБД, но быстрее?
а в чем проблема?
разница в подходах. если вы опираетесь исключительно на движок базы данных, то такой вариант у вас не пройдет. но если база всего лишь хранилище, то не вижу проблем.
_AB>А почему аналитику нельзя уложить?
Здравствуйте, _ABC_, Вы писали: _AB>С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях?
А как вы еще планируете ее использовать при наложенных ограничениях на процессор/диск/память? В live applications?
_AB>Кроме того, PosеgreSQL, Firebird бесплатны со всех сторон, например.
Про PostgreSQL я писал (Ingres) — не вижу перспектив данной системы, исключая БД от EnterpriseDB (и то надо думать ), но она платная.
Про Firebird — вы же не серьезно? 10 мб чистого фана . уж лучше нереляционная BerkleyDB от мейджора
_AB>Производительность нормальная, дрова вроде бы тоже есть и с кроссплатформенностью (хотя к чему она при нетиражируемом решении я не пойму) тоже все в порядке. Сам не пользовал, но читал про сотни внедрений и продуктов, построенных на основе этих СУБД и у многих проблем с нехваткой нагрузки нет. А про сколько внедрений я еще не слышал. _AB>Я вообще не понимаю, откуда вы выкапываете всякие марииДБ и прочий хлам, про которой в мире СУБД почти никто слыхом не слыхивал, и упорно игнорируете если не лидеров в своих сегментах, но весьма и весьма известные вещи.
Приводите реальные примеры. Примеры типа — внедрение блогоплатформы в Бангладеше руками индейцов на платформе Firebird, о которой я читал в 199N году не подходит.
Здравствуйте, Enomay, Вы писали:
G>>>>Фактически роль NoSQL сводится к persistent cache + Full Text Search. В таком виде nosql оправдан.
E>>>Фактически, ты говоришь глупости.
G>>Да что ты? Покажи где по-другому.
E>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю.
То что ты думаешь никого не интересует. Ты покажи реальные примеры, с нагрузкой. Такие чтобы можно было руками пощупать, а не гугл (у себя гугл при всем желании не поднимешь) или фейсбук (аналогично).
E>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее.
Да-да, "быстрее" это как раз на чтение и с отсутствием гарантий при записи. Это есть сценарий кеширования.
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, _ABC_, Вы писали: _AB>>С чего вдруг Express редакции стало возможно использовать только в учебных или демонстрационных целях? __>А как вы еще планируете ее использовать при наложенных ограничениях на процессор/диск/память? В live applications?
Для десктоп решений более чем подходит даже при указанных ограничениях. Кроме того возможен вариант с распределенной работой при использовании синхронизации с центральной базой.
E>>NoSQL подходит для всех задач, в той или иной мере, кроме, аналитики, я думаю. G>То что ты думаешь никого не интересует. Ты покажи реальные примеры, с нагрузкой. Такие чтобы можно было руками пощупать, а не гугл (у себя гугл при всем желании не поднимешь) или фейсбук (аналогично).
http://www.mongodb.org/display/DOCS/Production+Deployments
E>>Все остальное можно уложить в NoSQL. И работать это будет, как мы уже могли удостовериться, быстрее. G>Да-да, "быстрее" это как раз на чтение и с отсутствием гарантий при записи. Это есть сценарий кеширования.
Ну по вопросу скорости ты уже раз сфейлился. Теперь поставим тест на запись? что бы ты уже окончательно сфейлился.
Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса
Здравствуйте, Enomay, Вы писали:
E>а в чем проблема? E>разница в подходах. если вы опираетесь исключительно на движок базы данных, то такой вариант у вас не пройдет. но если база всего лишь хранилище, то не вижу проблем.
Не знаю, в чем проблема. Пытаюсь выяснить. Например, как мы будем хранить информацию о счетах? О транзакциях?
E>отчеты удобнее строить сиквелом
Дело только в "удобнее писать", или в чем-то еще, наподобие "сложнее собрать данные" и т.п.?
_AB>Не знаю, в чем проблема. Пытаюсь выяснить. Например, как мы будем хранить информацию о счетах? О транзакциях?
В виде документов
E>>отчеты удобнее строить сиквелом _AB>Дело только в "удобнее писать", или в чем-то еще, наподобие "сложнее собрать данные" и т.п.?
имхо, на sql проще написать логику агрегации большого объема данных, и сиквел скорее всего с этим справится лучше, нежели кастомное решение, в большинстве случаев.
Здравствуйте, 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 году не подходит.
Хм... Что-то с реальными примерами с другой стороны туговато. Зачем мне это делать? Примеры успешных внедрений гуглятся на раз. Если будет интересно, сами найдете.
Здравствуйте, 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 проводок. Одна потеряется — жопа, баланс не сойдется, как потом найти какая потерялась или как восстановить?
А если все это еще сложить с отсутствием механизмов конкурентного доступа, то целостность данных можно обеспечить только когда связанные данные помещаются в один документ, а это крайне сложно в том же учете.
Здравствуйте, Enomay, Вы писали:
_AB>>Не знаю, в чем проблема. Пытаюсь выяснить. Например, как мы будем хранить информацию о счетах? О транзакциях?
E>В виде документов
А поподробнее можно? Есть у нас, допустим, 1 000 000 счетов и, ну пусть будет 8 000 000 транзакций в сутки с ними и между ними. Как мы всё это будем хранить на логическом и физическом уровне?
E>>>отчеты удобнее строить сиквелом _AB>>Дело только в "удобнее писать", или в чем-то еще, наподобие "сложнее собрать данные" и т.п.?
E>имхо, на sql проще написать логику агрегации большого объема данных, и сиквел скорее всего с этим справится лучше, нежели кастомное решение, в большинстве случаев.
Т.е., проблем с тем, чтобы собрать согласованные на один момент времени данные, проблем не будет, верно?
Здравствуйте, gandjustas, Вы писали:
E>>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса G>Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью?
Не надо бредить. У большинства NoSQL есть гарантия атомарности и durability для отдельной записи (хотя она часто тоже отключаема) на отдельном узле.
Ты путаешь с гарантией глобальной атомарности и консистентности.
E>>Ну по вопросу скорости ты уже раз сфейлился. G>В смыссе сфейлился? MS SQL Express без оптимизаций выдал примерно столько же сколько mongodb.
да ну? такой же результат выдало при сериализации объектов на сторону .NET. без него результат 2-3ms. это на стороне сервера.
у тебя в сиквеле результат исключительно на стороне сервера замерялся. и он более 250ms.
сиквел слил.
G>А ты не привел скрипт для воспроизведения.
да ну? внимательней ответы смотри. во-вторых, не ясно что в данном контексте подразумевается под скриптом.
E>>Теперь поставим тест на запись? что бы ты уже окончательно сфейлился. G>Давай, нивопрос. Предлагай сценарий.
мне зачем? я уверен в скорости. тебе ж нужны доказательства.
E>>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса G>Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью? И как бороться в случае если это произойдет? Выгодно в этом плане только raven отличается, у него честный acid есть.
а если в датацентр ядерная бомба попадет, то ваще капец.
G>Взять например сценарий бухгалтерского\складского учета. За день до 10000 проводок. Одна потеряется — жопа, баланс не сойдется, как потом найти какая потерялась или как восстановить?
и чо, таки теряются? не верю. жалобы есть?
G>А если все это еще сложить с отсутствием механизмов конкурентного доступа, то целостность данных можно обеспечить только когда связанные данные помещаются в один документ, а это крайне сложно в том же учете.
конкуретный доступ реализуется по сути так же как в сиквеле.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
E>>>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса G>>Ты не в курсе? Большинство NoSQL баз возвращают управление ДО того как результаты реально попали на диск. Механизмов журналирования у них нет, так что где гарантия что программный или аппаратный сбой не произойдет в момент между отправкой команды и реальной записью? C>Не надо бредить. У большинства NoSQL есть гарантия атомарности и durability для отдельной записи (хотя она часто тоже отключаема) на отдельном узле.
MongoDB — только появилось в 2.0 в x64, raven — чуть раньше, redis до сих пор не durable, cassandra вроде поддерживает durable, то там проблемы с consistency возникают.
C>Ты путаешь с гарантией глобальной атомарности и консистентности.
Нет, как раз не путаю.
Здравствуйте, 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 делается и как в любом движке на твое усмотрение.
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 делается и как в любом движке на твое усмотрение.
Здравствуйте, 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, так что рекомендую сначала изучать, а потом писать.
Здравствуйте, 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, так что снаружи не видно
Здравствуйте, 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 ?
Здравствуйте, Дельгядо Филипп, Вы писали: ДФ>Хм, для весьма заметной части приложений этого достаточно. Собственно, не так уж и много реальных систем, где не хватит бесплатного Оракла или, тем более, DB2 UDB (где нет ограничений на объем БД).
Не соглашусь. К сожалению, в моем случае всегда "не хватало". Впрочем, опыт у каждого разный
ДФ>Э, и почему это у самой лучшей из бесплатных СУБД нет перспектив? Почему у какого-нибудь mongo есть, а у от Postgre — нет? На основании чего сделан такой вывод?
Работал с ней в ранние годы, если очень коротко — медленная с vldb, слабый оптимизатор, мало enterprise-фич, саппорт стоит конских денег.
Здравствуйте, a_g_99, Вы писали:
__>Не соглашусь. К сожалению, в моем случае всегда "не хватало". Впрочем, опыт у каждого разный
С какими работали и на каких сценариях?
__>Работал с ней в ранние годы, если очень коротко — медленная с vldb, слабый оптимизатор, мало enterprise-фич, саппорт стоит конских денег.
С какими версиями?
Р>О... А в чем он вообще имеет преимущества, кроме [полу]объектной модели?
Например Google Megastore. Репликация между географически распределёнными датацентрами с приемлимой скоростью работы. Можно сравнить с возможностями того, что начал продавать амазон для mysql после полного даунтайма одного своего датацентра.
Кстати, на этот счет есть статейка: Life beyond Distributed Transactions — там вывод, если вам нужны гарантии целостности внутри определённой группы данных (т.е. обеспечить ACID), то, вам прийдётся сделать так, что эта группа влазила на один инстанс БД (одна машина или что-то a-la RAC) потому, что обеспечивать синхронизацию между разными удалёнными инстансами дорого. По-этому оптимальная стратегия — определить группу в рамках которой acid гарантируется. В то же время между групами консистентность не обеспечивается. Именно по такой схеме и работает Google Megastore.
Здравствуйте, _ABC_, Вы писали:
_AB>Для приложений, которые не испытывают высокой нагрузки. Скажем, простенький сайт типа блога с кол-вом посещений до 10 000 в сутки с пиком в 1 500 в час Express редакция вполне себе потянет. _AB>Ну, или для простых конфигураций 1С с небольшим количеством клиентов. _AB>Для небольших, но высоконагруженных проектов с размером БД не выше 50 ГБ вполне себе неплохое решение, ИМХО.
При том если даже лимита производительности нет, то всё равно возникает куча проблем, экспертиза по решению которых уже давно наработана (потому многие их вообще проблемами не считают). Но "механичность" их решения делает эти проблемы еще более идиотскими по сути.
Здравствуйте, Дельгядо Филипп, Вы писали:
M>>О да, графы любого типа — это отдельная песня, что стону подобна. Только вот graph-базами данных мало кто занимается ДФ>Ну, на практике графов, не влезающих в память довольно мало, делать для них движки смысла нет, проще писать конкретное решение. А если влезают — то и не шибко важно, как его хранить в persistance ДФ>Ну, может, что-нибудь из решений для хранения социальных графов для сетей — и выйдет в open-source...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Всё так. В теории. А на практике приходится людям какие-то `tag engine` городить. Это к слову о SO, как примеру pure RDBMS.
А нельзя ли не давать ссылок на сомнительные ресурсы, требующие регистрации? Тем более, что насколько я понимаю, этот ресурс насквозь вторичен и найти первоисточник не будет проблемой.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Всё так. В теории. А на практике приходится людям какие-то `tag engine` городить. Это к слову о SO, как примеру pure RDBMS. _AB>А нельзя ли не давать ссылок на сомнительные ресурсы, требующие регистрации? Тем более, что насколько я понимаю, этот ресурс насквозь вторичен и найти первоисточник не будет проблемой.
Здравствуйте, 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 ?
Если есть цель сделать самостоятельно, то можно сделать. Если такой цели нет, то использовать что дают.
Здравствуйте, Enomay, Вы писали: E>Ну по вопросу скорости ты уже раз сфейлился. Теперь поставим тест на запись? что бы ты уже окончательно сфейлился. E>Да, про отсутствие гарантии при записи это как? типа записали в базу а оно пропало? чудеса
Вот эти две фразы — они как одновременно работают?
Я к тому, что БД упирается в IOPS дисковой системы. Вот у нас, допустим, есть RDBMS. Что она делает при commit, мы хорошо знаем — в redo log выполняется flush. Поэтому делать коммитов в секунду больше, чем диск умеет IOPS, принципиально не получится. И это RDBMS ещё экономит на записи, т.к. откладывает запись собственно изменений данных. Если во время коммита не произошёл Flush на диск, то ни о какой durability говорить смысла нет.
А теперь расскажите мне, благодаря какой магии NoSQL обойдут это ограничение?
Я лично вижу только один способ — отказаться от flush при commit, в надежде, что между commit и следующим flush всё будет хорошо. Т.е. как раз отсутствие гарантии при записи.
Если вы знаете какой-то другой способ — молю, поделитесь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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.
Опционально 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 вообще.
1. Stack Overflow совсем не небольшой, хотя и высоконагруженный проект.
2. А чем не pure? Данные хранятся в RDBMS, просто кешируются для производительности. Насколько я понял, кэш обновляется раз в минуту как раз данными из БД. Вполне себе нормальное явление, совсем не редкое в 3-х звенной архитектуре.
ANS>При том если даже лимита производительности нет, то всё равно возникает куча проблем, экспертиза по решению которых уже давно наработана (потому многие их вообще проблемами не считают). Но "механичность" их решения делает эти проблемы еще более идиотскими по сути.
С каких пор наличие отработанных и известных решений известных проблем делает проблемы идиотскими? Примерчик можно такой идиотской проблемы, чтобы понять о чем речь?
Здравствуйте, Cyberax, Вы писали:
C>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать.
А они все по умолчанию не-durable случайно не потому, что иначе начнут проигрывать в производительности РСУБД? Есть какое-нибудь сравнение на эту тему? Заранее спасибо, если есть.
Здравствуйте, _ABC_, Вы писали:
_AB>2. А чем не pure? Данные хранятся в RDBMS, просто кешируются для производительности. Насколько я понял, кэш обновляется раз в минуту как раз данными из БД. Вполне себе нормальное явление, совсем не редкое в 3-х звенной архитектуре.
тогда и к тебе вопрос. FlockDB ( https://github.com/twitter/flockdb ) работает поверх MySql. Это как SQL или noSql?
ANS>>При том если даже лимита производительности нет, то всё равно возникает куча проблем, экспертиза по решению которых уже давно наработана (потому многие их вообще проблемами не считают). Но "механичность" их решения делает эти проблемы еще более идиотскими по сути.
_AB>С каких пор наличие отработанных и известных решений известных проблем делает проблемы идиотскими? Примерчик можно такой идиотской проблемы, чтобы понять о чем речь?
И это только один из многих 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 делает масштабирование гораздо выгоднее.
Сферовакуумный разговор без перехода к конкретной задаче и конкретным хостерам/облакам. И не вижу смысла вообще это обсуждать здесь, т.к. достаточно чуть поменяться ценам на рынке и всё переиграется.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>тогда и к тебе вопрос. FlockDB ( https://github.com/twitter/flockdb ) работает поверх MySql. Это как SQL или noSql?
Вопрос не в этом. Вопрос в том, СУБД это, или нет?
ANS>дедлок.
Можно раскрыть тему? В том смысле, что наличие решения делает эту проблему "еще более идиотской".
Здравствуйте, 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 и поддержку обычно цены тоже приличные. )
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>P.S. Практически все прелести mongo (включая шардинг) делаются где-то за день-два на любой реляционной базе (оставляя в живых ACID, но прощаясь с гарантиями целостности, разумеется).
Ну не за день-два, но действительно делаются. Если использовать sql базу в режиме ключ-значение. Однако быстродействие будет несравнимо.
Здравствуйте, _ABC_, Вы писали:
C>>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать. _AB>А они все по умолчанию не-durable случайно не потому, что иначе начнут проигрывать в производительности РСУБД? Есть какое-нибудь сравнение на эту тему? Заранее спасибо, если есть.
Зависит. Обычно NoSQL всё равно быстрее.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Более того, требования у TokyoCabinet жестче, так как требуется *nix, а Oracle можно запустить и под Windows.
TokyoCabinet — это старая реализация. Kyoto Cabinet работает лучше и на windows в том числе.
Однако я не вижу смысла обсуждать такие решения вообще. На встраиваемых базах преимущества nosql увидеть очень трудно. Более того, для простых задач (где sql не нужен) и в рамках встроенной базы проще вообще делать свой формат файла и не думать о каких-то nosql движках.
ДФ>Ну и, конечно, есть и opensource РСУБД и встраиваемые РСУБД — на любой вкус.
Здравствуйте, gandjustas, Вы писали:
G>Это верно. Область применения SQL — простые проекты, где нет конкурентного доступа и большого объема данных , типа embed или десктоп приложения.
Бред какой. Как раз в этой области увидеть преимущества nosql практически невозможно. Тут логичнее использовать sqlite или вообще просто свой формат файла.
Здравствуйте, _ABC_, Вы писали:
_AB>Т.е. я могу уложить биллинг, бухгалтерию, или другую задачу финансового учета в NoSQL и он будет работать так же надежно как с СУБД, но быстрее?
P.S. Кидаю эту ссылку уже наверное 3-ий раз. Так же как и до этого приходилось повторять мысли по несколько раз. Сколько у нас тут вообще писателей-не-читателей? )
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);
}
G>>>Эпично слил, нет слов. E>>ты и правда болван G>Яж говорю, отойди от зеркала.
то есть ты таки слил? ок.
G>>>Жалоб нет, потому что в здравом уме никто бухгалтерию на nosql не делает. А вообще потери случаются, может интернеты почитать. E>>как говорил мой хороший друг, Станиславский — не верю! G>Нивопрос, покажи кто пишет.
тебе приводили аргументы, ты их игноришь.
G>>>Ну давай расскажи как конкурентный доступ в SQL делается и как в любом движке на твое усмотрение. E>>мне это зачем? G>См выделенное. Есть подозрение что ты не понимаешь как разруливается конкурентный доступ.
ну давай ты рапишешь что ты хочешь получить, а мы потом подумаем как это можно сделать. а главное, нужно ли.
S>Если вы знаете какой-то другой способ — молю, поделитесь.
я не знаю как в какой бд оно реализовано.
сиквел помимо записи диск грузит еще кучей тасков. в nosql их как правило нет. потому оно и быстрее, что проще.
Здравствуйте, gandjustas, Вы писали:
__>>А чем по вашему индексы noSQL отличаются от индексов RDBMS ? G>Как минимум тем что: G>1) РСУБД имеет регулярную структуру. Например нет множественных значений. G>2) Индекс РСУБД оптимизирован по размеру. G>3) Операции в СУБД отличаются, поэтому и индексы отличаются.
Я понял, индексы в рсубд волшебные.
Только почему тогда наши совместные измерения показали прямо противоположный результат? )
G>Ручное управление блокировками — жопа, 100% дедлоки и тормоза. Кайф РСУБД, что тебе достаточно указать уровень изоляции и остальное база делает сама очень эффективным способом. G>Ручным управлением можно сделать и быстрее, но только в теории.
Я согласен, что всяким недопрограммерам к nosql лучше не подходить. Хотя конечно современные инструменты типа mongodb сглаживают ситуацию, но всё же лучше не стоит. Пускай лучше sql запросы мастерят — умная база частенько исправляет их кривизну.
Но наличие плохих специалистов в мире не означает что не нужно развивать инструменты для профессионалов.
_>Я там по ссылкам на Dell PowerEdge515 не смотрел... Но в эти $8511 входит оплата места в дата-центре с оплатой трафика и саппорта по серверу? А то там на colocation и поддержку обычно цены тоже приличные. )
Нет, не входит — это я в магазине смотрел. Но цены на colocation для него, очевидно, будут раз в 10 ниже, чем для для 12 коробок. Это же 2U. Поймите, чудес не бывает. Да, наверное, реально топовый сервер (это, скажем, 40 ядер, 2TB памяти, секси дисковая подсистема) стоит не в 40 раз дороже этих унылых фуджитсу. Но до него типичному веб-проекту придётся расти лет десять.
А в целом, раздать, скажем, 48GB памяти, 16 ядер, и 16 винтов по 16 машинам никак не выйдет дешевле, чем поставить их все в одно шасси.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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-ий раз. Так же как и до этого приходилось повторять мысли по несколько раз. Сколько у нас тут вообще писателей-не-читателей? )
Толку-то от того, что ты её кидаешь, если кинуто не в тему и не отвечает на поставленный вопрос? Хотя... Отвечает, но отрицательно.
Здравствуйте, alex_public, Вы писали:
_>Я согласен, что всяким недопрограммерам к nosql лучше не подходить. Хотя конечно современные инструменты типа mongodb сглаживают ситуацию, но всё же лучше не стоит. Пускай лучше sql запросы мастерят — умная база частенько исправляет их кривизну.
Только вот в статьях, хвалящих nosql я часто вижу запросы типа "смотрите, я всего то десяток cross join'ов на таблицы в 100500 записей накидал, чтобы выбрать одну запись и изменить её, а она тупит. И это при том, что я на каждую таблицу по 300 индексов создал. А если бы их не было, я бы вообще состарился к моменту завершения запроса...".
Умная база часто исправляет кривизну. Но когда не справляется, виноватой почему-то объявляется СУБД, а не "перепрограммер", неспособный понять простейших вещей.
_>Но наличие плохих специалистов в мире не означает что не нужно развивать инструменты для профессионалов.
Согласен. Пусть РСУБД развиваются.
Здравствуйте, Cyberax, Вы писали:
G>>redis до сих пор не durable C>Опционально durable c давних времён.
Append-only это не то что можно в конфиге включить, это требует переделки приложения.
C>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать.
Ну да, только если включить durable начинаются проблемы похлеще, чем у SQL решений.
G>>то там проблемы с consistency возникают. C>Ну так. NoSQL типично не имеет гарантий глобальной consistency вообще.
Дык, я про глобальные вещи и не говорю, даже в локальных случаях проблемы возникают.
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 делает масштабирование гораздо выгоднее.
_>Сферовакуумный разговор без перехода к конкретной задаче и конкретным хостерам/облакам. И не вижу смысла вообще это обсуждать здесь, т.к. достаточно чуть поменяться ценам на рынке и всё переиграется.
Есть устойчивая тенденция снижения цены за единицу ресурса.
Здравствуйте, gandjustas, Вы писали:
G>>>redis до сих пор не durable C>>Опционально durable c давних времён. G>Append-only это не то что можно в конфиге включить, это требует переделки приложения.
Неа.
C>>В общем, не-durable (хотя бы и опционально) БД надо ещё поискать. G>Ну да, только если включить durable начинаются проблемы похлеще, чем у SQL решений.
Неа.
G>Сравни это с синхронным коммитом и DTC для SQL.
CAP-теорема.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Это верно. Область применения SQL — простые проекты, где нет конкурентного доступа и большого объема данных , типа embed или десктоп приложения.
_>Бред какой. Как раз в этой области увидеть преимущества nosql практически невозможно. Тут логичнее использовать sqlite или вообще просто свой формат файла.
Почему же, преимущества на лице:
1) работа в терминах объектной модели, на надо знать sql
2) высокая скорость работы
3) надежность не ниже надежности самого устройства
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
__>>>А чем по вашему индексы noSQL отличаются от индексов RDBMS ? G>>Как минимум тем что: G>>1) РСУБД имеет регулярную структуру. Например нет множественных значений. G>>2) Индекс РСУБД оптимизирован по размеру. G>>3) Операции в СУБД отличаются, поэтому и индексы отличаются.
_>Я понял, индексы в рсубд волшебные.
В чем волшебство то? Сценарии использования разные.
_>Только почему тогда наши совместные измерения показали прямо противоположный результат? )
В чем он противоположный? Время работы почти одинаковое, при том что у меня работала версия Express у которой ограничение в 1гб памяти.
Напомню что изначально апологеты заявляли что SQL сольет. Вот не слил. Хотя такая задача поиска по тегам — крайне тяжелая для sql. Посмотри статьи как этот поиск сделан в stackoverflow, там один большой жосткий хак. В sql server 2012 вроде докрутили FTS и теперь он нормально работает на таких сценариях.
Здравствуйте, Sinclair, Вы писали:
S>Нет, не входит — это я в магазине смотрел. Но цены на colocation для него, очевидно, будут раз в 10 ниже, чем для для 12 коробок. Это же 2U. Поймите, чудес не бывает. Да, наверное, реально топовый сервер (это, скажем, 40 ядер, 2TB памяти, секси дисковая подсистема) стоит не в 40 раз дороже этих унылых фуджитсу. Но до него типичному веб-проекту придётся расти лет десять. S>А в целом, раздать, скажем, 48GB памяти, 16 ядер, и 16 винтов по 16 машинам никак не выйдет дешевле, чем поставить их все в одно шасси.
Угу, чудес не бывает. Как раз поэтому актуальны оба вида решений. И нам (клиентам) это только хорошо — пускай конкурируют между собой, снижая цены.
Но если смотреть глобально, то я всё же вижу большую перспективу у распределённых систем.
Здравствуйте, _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. "
Здравствуйте, _ABC_, Вы писали:
_AB>Только вот в статьях, хвалящих nosql я часто вижу запросы типа "смотрите, я всего то десяток cross join'ов на таблицы в 100500 записей накидал, чтобы выбрать одну запись и изменить её, а она тупит. И это при том, что я на каждую таблицу по 300 индексов создал. А если бы их не было, я бы вообще состарился к моменту завершения запроса...". _AB>Умная база часто исправляет кривизну. Но когда не справляется, виноватой почему-то объявляется СУБД, а не "перепрограммер", неспособный понять простейших вещей.
Таких к nosql тем более нельзя подпускать. ) Даже страшно представить себе результат. )))
_>>Но наличие плохих специалистов в мире не означает что не нужно развивать инструменты для профессионалов. _AB>Согласен. Пусть РСУБД развиваются.
Ну в целом когда-то так и было) Однако сейчас php+mysql+apache — это уже фирменный набор технологий недопрограммера (что не означает что только они используют этот набор). Так что... )))
Здравствуйте, gandjustas, Вы писали:
G>Как раз по ссылке видно что это так. Там business critical приложений меньше трети, почитай внимательно.
А я разве спорю что их больше трети? ) Меня тут вроде как убеждали что их нет вообще, потому как на nosql они в принципе не возможны. Бредовость чего я и показал.
G>И это самая популярная NoSQL БД. То есть реально меньше 1% рынка, это и есть "в микроскоп не видно".
Ну во-первых я не понял откуда взялась цифра в 1%... Хотя я с ней и не спорю. Просто интересно...
А во-вторых я же вроде не раз тут говорил что современные nosql решения только начинают подниматься — вполне не плохие результаты уже за такие короткие сроки.
G>Я вообще с трудом представляю автоматический шардинг в SQL.
Вот вот. )
G>Я его также с трудом представляю как делать rollup по всем документам в распределенном nosql. G>Например получить список всех тегов по частоте использования в этой самой базе со статьями. G>Расскажешь как это делается?
Здравствуйте, gandjustas, Вы писали:
_>>Бред какой. Как раз в этой области увидеть преимущества nosql практически невозможно. Тут логичнее использовать sqlite или вообще просто свой формат файла.
G>Почему же, преимущества на лице: G>1) работа в терминах объектной модели, на надо знать sql G>2) высокая скорость работы G>3) надежность не ниже надежности самого устройства
Возможно если бы были встраиваемые документо-ориентированные (типа mongodb) решения, то они были бы удобнее всего — перешли бы на них. Но пока такого нет. Среди встраиваемых nosql только чистые ключ-значение, практически не отличающиеся от древнего берклидб. Для определённого узкого класса задач конечно подходит, но в общем не удобно. Мы предпочитаем использовать sqlite.
Здравствуйте, gandjustas, Вы писали:
_>>Только почему тогда наши совместные измерения показали прямо противоположный результат? ) G>В чем он противоположный? Время работы почти одинаковое, при том что у меня работала версия Express у которой ограничение в 1гб памяти.
В этот 1Гб уложится мноого таких баз, на которых мы тестировали. )))
G>Напомню что изначально апологеты заявляли что SQL сольет. Вот не слил. Хотя такая задача поиска по тегам — крайне тяжелая для sql. Посмотри статьи как этот поиск сделан в stackoverflow, там один большой жосткий хак. В sql server 2012 вроде докрутили FTS и теперь он нормально работает на таких сценариях.
1. Я лично ничего такого не утверждал. Я всегда говорил что неоспоримые преимущества возникают в другой ситуации.
2. Я не видел результата с sql в реальном приложение (как у меня), а не на сервере. Как тут уже указывали, возможно будут совсем другие результаты. )))
3. Мы тут сейчас обсуждали уже не тот результат с запросом, а построение индексов. И тут уже без сомнений было видно что mongodb заметно выигрывает.
_>"Yabblr uses MongoDB for everything, including inventory management and orders. Yabblr is an E-Commerce platform which..."
Ну, тут вообще никакого биллинга или коммерческих операций нет. По крайней мере в Mongo. Может, в третьих системах, о которых упоминается.
_>"OpenSky uses MongoDB for just about everything (not just analytics). "
Э, вранье написано на сайте Монго. Собственно биллинг у OpenSky написан на нормальной РСУБД, в Mongo только описание товаров и вся неважная информация (см. их презентации).
_>"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. "
Э, тут просто склад документов, вспомогательная система, ни биллинга, ни order processing, ни прочих существенных операций
_>"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. "
А тут, судя по тексту, тоже только статистика на монго
_>Или это типа тоже не то? )
Угу. Сплошные справочники, статистика и кэши, никаких финансов.
Впрочем, это и правильно, монго и нужна как способ работы со свалкой "грязной" информации и в этом качестве вполне эффективно.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, _ABC_, Вы писали:
_AB>>И где там использование noSQL в "биллинге, бухгалтерии или другой задаче финансового учета"?
_>Ох... Просто пролистал начало списка (и это при том, что конкретная область применения указана только у части):
Просто пролистать мало, надо копнуть поглубже.
_>"Yabblr uses MongoDB for everything, including inventory management and orders. Yabblr is an E-Commerce platform which..."
Yabblr — нет деталей реализации, поэтому говорить они могу что угодно. Учитывая, что это купонный сайт, управления денежными потоками у них может и не быть вообще.
_>"OpenSky uses MongoDB for just about everything (not just analytics). "
И вот то, что как раз не входит в 'just about everything' — это работа с деньгами. Это из их презентации фраза "we do not trust values in Mongo" в разрезе управления остатками и деньгами.
Вообще, мне эти ребята понравились. У них сдвиг по фазе на опен-сорсе. Поэтому выбор Монго перед мускулем оправдан и они четко понимают, что где рулит и где лежит граница применимости.
_>"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. "
Бета продукта, которая еще не вышла на рынок? Ты это серьезно?
_>Или это типа тоже не то? )
Не то. Читать-то будешь сам, или других только обвинять способен?
Здравствуйте, alex_public, Вы писали:
_>Угу, чудес не бывает. Как раз поэтому актуальны оба вида решений. И нам (клиентам) это только хорошо — пускай конкурируют между собой, снижая цены.
_>Но если смотреть глобально, то я всё же вижу большую перспективу у распределённых систем.
С этим я согласен, просто не нужно их переоценивать. А то статьи на хабре явно пишут люди, которые сервер за 8K никогда в жизни не видели, и полагают, что два миллиона пользователей — это уже копееееееец как много, и надо покупать топовые решения из tpc-c.
А тем временем проекты типа твиттера генерят от силы десяток записей на пользователя в (рабочий) день; если у вас два миллиона пользователей, то это 20 миллионов транзакций в день или 40 000 в минуту. Это не очень много для RDBMS. Актуальные решения на tpc-c начинаются от примерно двухсот тысяч tpmC, а их транзакции посложнее твиттерных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А тем временем проекты типа твиттера генерят от силы десяток записей на пользователя в (рабочий) день; если у вас два миллиона пользователей, то это 20 миллионов транзакций в день или 40 000 в минуту. Это не очень много для RDBMS. Актуальные решения на tpc-c начинаются от примерно двухсот тысяч tpmC, а их транзакции посложнее твиттерных.
Основная нагрузка в твиттере это все-таки не запись твитов, а раскидывание их по фоллоуэрам да всякие поиски по тегам.
И там цифры совсем другие будут.
Здравствуйте, alex_public, Вы писали:
_>Таких к nosql тем более нельзя подпускать. ) Даже страшно представить себе результат. )))
Тем не менее, таких апологетов nosql и слышно громче всего в интернете.
_>Ну в целом когда-то так и было) Однако сейчас php+mysql+apache — это уже фирменный набор технологий недопрограммера (что не означает что только они используют этот набор). Так что... )))
Ну а сейчас таким набором будет apache+ror+mongo и вся разница.
Сам же говоришь, что никаких чудес от этого не произойдет и недопрограммеры не станут программистами. Посмотри на посты Фукермана в db, яркий образчик будущего апологета nosql, ИМХО. Никакого желания понять, что же он делает, ему просто нужен запрос, чтобы платформа за него сама обернула его в ОРМ. Таким и нужен nosql.
Здравствуйте, alex_public, Вы писали:
_>Ну не за день-два, но действительно делаются. Если использовать sql базу в режиме ключ-значение. Однако быстродействие будет несравнимо.
Не вполне понимаю, что мешает использовать настоящий шардинг? Делаем view, построенное на union all, делаем констреинты на нижележащие таблицы, делаем instead of триггер, раскидывающий вставки по серверам — вуаля.
Прозрачным для приложения образом имеем шардинг полноценных реляционных данных.
Единственное, что мне не нравится — это ручная процедура добавления нового сервера. Но это можно улучшить при помощи деплоймент-скриптов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали:
E>я не знаю как в какой бд оно реализовано. E>сиквел помимо записи диск грузит еще кучей тасков. в nosql их как правило нет. потому оно и быстрее, что проще.
А можно поимённо перечислить хотя бы часть из этой "кучи тасков"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ДФ>Угу. Сплошные справочники, статистика и кэши, никаких финансов. ДФ>Впрочем, это и правильно, монго и нужна как способ работы со свалкой "грязной" информации и в этом качестве вполне эффективно.
Согласен, для таких применений RDBMS — это оверкилл.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали:
L>Основная нагрузка в твиттере это все-таки не запись твитов, а раскидывание их по фоллоуэрам да всякие поиски по тегам. L>И там цифры совсем другие будут.
Это понятно. Просто тут некоторые рассказывают про чудеса перформанса на запись, достигаемые NoSQL на настольных дисковых системах.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Основная нагрузка в твиттере это все-таки не запись твитов, а раскидывание их по фоллоуэрам да всякие поиски по тегам. L>>И там цифры совсем другие будут. S>Это понятно. Просто тут некоторые рассказывают про чудеса перформанса на запись, достигаемые NoSQL на настольных дисковых системах.
Имхо, использовать невалидные доказательства — не очень красиво даже в том случае, если оппонент неправ.
Здравствуйте, Lloyd, Вы писали:
L>Имхо, использовать невалидные доказательства — не очень красиво даже в том случае, если оппонент неправ.
Не очень понимаю, что вы имеете в виду под "невалидностью". Поведение системы на запись мы обсудили. Поведение при поиске по тегам обсуждается в соседней ветке.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не очень понимаю, что вы имеете в виду под "невалидностью".
Невалидным является утверждение
проекты типа твиттера генерят от силы десяток записей на пользователя в (рабочий) день
По факту это не так, т.к. генерится не только сам твит, но и добавляется информация всем фолловерам, а это (учитывая размеры твита) даже для скромных пользователей может весьма существенно увеличить объем записываемых данных.
Здравствуйте, Lloyd, Вы писали:
L>По факту это не так, т.к. генерится не только сам твит, но и добавляется информация всем фолловерам, а это (учитывая размеры твита) даже для скромных пользователей может весьма существенно увеличить объем записываемых данных.
Для интересу посмотрите, что происходит во время т.н. "транзакции" в tpc-c. Там тоже не 80 байт в табличку уезжают. Т.е. операций записи там гораздо больше. Как и в твиттере на один твит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>По факту это не так, т.к. генерится не только сам твит, но и добавляется информация всем фолловерам, а это (учитывая размеры твита) даже для скромных пользователей может весьма существенно увеличить объем записываемых данных. S>Для интересу посмотрите, что происходит во время т.н. "транзакции" в tpc-c. Там тоже не 80 байт в табличку уезжают. Т.е. операций записи там гораздо больше. Как и в твиттере на один твит.
Да я ж не против.
Но это никак не отменяет того факта, что утверждение про "от силы десяток записей" несколько не соответствует действительности.
Здравствуйте, Lloyd, Вы писали:
L>Да я ж не против. L>Но это никак не отменяет того факта, что утверждение про "от силы десяток записей" несколько не соответствует действительности.
Под "записями" имелись в виду "атомарные твиты", а не "одиночные операции ввода-вывода". Так же, как и под "транзакциями" TPC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Но это никак не отменяет того факта, что утверждение про "от силы десяток записей" несколько не соответствует действительности. S>Под "записями" имелись в виду "атомарные твиты", а не "одиночные операции ввода-вывода". Так же, как и под "транзакциями" TPC.
Сорри, неправильно тебя понял. Думал под записями ты подразумеваешь то, что обычно называют записями в базах данных, а не "бизнес"-транзакции.
Здравствуйте, Lloyd, Вы писали:
L>Сорри, неправильно тебя понял. Думал под записями ты подразумеваешь то, что обычно называют записями в базах данных, а не "бизнес"-транзакции.
В некотором смысле — да. С точки зрения реляционной модели, запись в таблицу добавляется ровно одна. Всё остальное — разнообразные индексы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Сорри, неправильно тебя понял. Думал под записями ты подразумеваешь то, что обычно называют записями в базах данных, а не "бизнес"-транзакции. S>В некотором смысле — да. С точки зрения реляционной модели, запись в таблицу добавляется ровно одна. Всё остальное — разнообразные индексы.
Можешь примерно набросать схему данных и соответствующие индексы чтобы при добавлении твита обновившиеся индексы хоть как-то помогали фолловерам отобрать добавленые твиты?
L>Можешь примерно набросать схему данных и соответствующие индексы чтобы при добавлении твита обновившиеся индексы хоть как-то помогали фолловерам отобрать добавленые твиты? L>
Я так думаю именно такая схема была в твитере в самом начале. Они же довольно долго на одном сервере работатали.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
L>>Можешь примерно набросать схему данных и соответствующие индексы чтобы при добавлении твита обновившиеся индексы хоть как-то помогали фолловерам отобрать добавленые твиты? L>>
ANS>Я так думаю именно такая схема была в твитере в самом начале. Они же довольно долго на одном сервере работатали.
E>>я не знаю как в какой бд оно реализовано. E>>сиквел помимо записи диск грузит еще кучей тасков. в nosql их как правило нет. потому оно и быстрее, что проще. S>А можно поимённо перечислить хотя бы часть из этой "кучи тасков"?
ок, поставлю вопрос иначе. возьмем чисто 10. запись его в текстовый файл или в бд. что будет быстрее?
Здравствуйте, Lloyd, Вы писали:
L>Можешь примерно набросать схему данных и соответствующие индексы чтобы при добавлении твита обновившиеся индексы хоть как-то помогали фолловерам отобрать добавленые твиты? L>
Ну, это как бы не rocket science.
create table tweets (
id int identity not null primary key non clustered,
author int not null foreign key references authors(ID),
stamp datetime not null,
tweet varchar(80) not null
)
GO
create table followers (
followed int not null foreign key references authors(ID),
follower int not null foreign key references authors(ID),
unique clustered constraint followKey (follower, followed)
)
GO
create unique clustered index followindex on tweets(author, stamp, tweet)
далее имеем:
select author, stamp, tweet from tweets where author in (select followed from followers where follower = @currentUser)
План запроса понятен, или надо объяснять, почему тут не будет ни table, ни index scan?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали:
E>ок, поставлю вопрос иначе. возьмем чисто 10. запись его в текстовый файл или в бд. что будет быстрее?
В первом приближении — одинаково. А вы как думаете?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Ну, это как бы не rocket science.
Скрытый текст
S>
S>create table tweets (
S>id int identity not null primary key non clustered,
S>author int not null foreign key references authors(ID),
S>stamp datetime not null,
S>tweet varchar(80) not null
S>)
S>GO
S>create table followers (
S> followed int not null foreign key references authors(ID),
S> follower int not null foreign key references authors(ID),
S> unique clustered constraint followKey (follower, followed)
S>)
S>GO
S>create unique clustered index followindex on tweets(author, stamp, tweet)
S>далее имеем: S>
S>select author, stamp, tweet from tweets where author in (select followed from followers where follower = @currentUser)
S>
S>План запроса понятен, или надо объяснять, почему тут не будет ни table, ни index scan?
Если я не ошибаюсь, прием называется "ложная альтернатива", да?
Сопоставь это по эффективности со случаем, когда при добавлении твита добавляются соответствущие связки "твит-фоловер". И не забудь при этом, что твиттер читают больше чем пишут.
И приди к выводу, что единственным приемлемым вариантом будет именно вариант с добавлением связок.
После того, как придешь к такому выводу, взгляни открывшимися глазами на свою фразу про "от силы десяток записей".
Здравствуйте, Sinclair, Вы писали:
S>Не вполне понимаю, что мешает использовать настоящий шардинг? Делаем view, построенное на union all, делаем констреинты на нижележащие таблицы, делаем instead of триггер, раскидывающий вставки по серверам — вуаля. S>Прозрачным для приложения образом имеем шардинг полноценных реляционных данных. S>Единственное, что мне не нравится — это ручная процедура добавления нового сервера. Но это можно улучшить при помощи деплоймент-скриптов.
Во-первых, что там будет с транзакциями?
Во-вторых, у тебя будет два варианта — ты работаешь с прилинкованными серверами последовательно. Селект с первого, со второго, третьего; проапдейтил первый, второй третий. С т.зрения производительности такое нафиг не нужно. Если же ты извернёшся и будешь обращаться к серверам параллельно у тебя полезут "межсерверверные" дедлоки, которые можно разрулить только таймаутом. Что тоже не сахар.
Плюс, с точки зрения стабильности — выпадение любого сервера делает нерабочим весь кластер. Смысла в таком немного.
btw, если бы так всё было просто, то Oracle RAC не стоил бы столько сколько он стоит.
Здравствуйте, _ABC_, Вы писали:
ANS>>тогда и к тебе вопрос. FlockDB ( https://github.com/twitter/flockdb ) работает поверх MySql. Это как SQL или noSql? _AB>Вопрос не в этом. Вопрос в том, СУБД это, или нет?
Если СУБД это то, что создаёт, и удаляет отдельные БД — то не знаю. Но то, что это сервер управляющий данными — это однозначно.
И всё же не съезжай. Назови это "решение". Это решение SQL потому, что там где-то внизу mysql, noSql — потому, что api не разу не sql и гарантии другие?
ANS>>дедлок. _AB>Можно раскрыть тему? В том смысле, что наличие решения делает эту проблему "еще более идиотской".
есть проблема, есть решение, которое подразумевает исключительно индивидуальный подход в каждому случае. ну не идиотизм ли?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Andrei N.Sobchuck, Вы писали:
L>>>Можешь примерно набросать схему данных и соответствующие индексы чтобы при добавлении твита обновившиеся индексы хоть как-то помогали фолловерам отобрать добавленые твиты? L>>>
ANS>>Я так думаю именно такая схема была в твитере в самом начале. Они же довольно долго на одном сервере работатали.
L>Какая "такая"?
в одном сервере с индексами, которые всему помогают.
Здравствуйте, Lloyd, Вы писали:
L>Сопоставь это по эффективности со случаем, когда при добавлении твита добавляются соответствущие связки "твит-фоловер". И не забудь при этом, что твиттер читают больше чем пишут.
Ну, давайте сопоставим. Вы мне объясните, что вы называете "связками". Что в них входит? ID твита или сам твит? L>И приди к выводу, что единственным приемлемым вариантом будет именно вариант с добавлением связок.
Не забегайте впердё. Сначала надо таки сопоставить.
L>После того, как придешь к такому выводу, взгляни открывшимися глазами на свою фразу про "от силы десяток записей".
Ещё раз поясню для тех, кто медленно читает: записей там ровно столько, сколько раз пользователь твитнул. Всё остальное, ненаблюдаемое пользователем — это индексы, т.е. денормализация данных, прикрученная для ускорения определённого типа запросов.
Вы думаете, что вы умнее меня, и у вас есть в запасе более эффективная схема индексов, чем я придумал. Даже если это и так (в чём у меня есть обоснованные сомнения), это никак не противоречит моему изначальному высказыванию. С большой-большой вероятностью мы и придуманную вами схему, какова бы она ни была, положим в RDBMS в виде ещё какого-то индекса, и insert into останется одиноким.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Во-первых, что там будет с транзакциями?
Ну, во-первых, большинство транзакций таки попадают внутрь одного сервера (или шардинг сделан неудачно).
Во-вторых, если таки нет, то из коробки есть 2-phase commit. А что у нас есть для этого случая на стороне NoSQL?
ANS>Во-вторых, у тебя будет два варианта — ты работаешь с прилинкованными серверами последовательно. Селект с первого, со второго, третьего; проапдейтил первый, второй третий. С т.зрения производительности такое нафиг не нужно. Если же ты извернёшся и будешь обращаться к серверам параллельно у тебя полезут "межсерверверные" дедлоки, которые можно разрулить только таймаутом.
С чего это вдруг у меня полезут межсерверные дедлоки? Поясните.
Предположим, я делаю
select * from sharded_table where secondary_attribute = @value
Это выливается в N параллельных селектов, которые отправляются на N серверов. Результат затем сливается, и всё это прозрачно для клиента.
Какие тут требуются "извороты"?
ANS>Плюс, с точки зрения стабильности — выпадение любого сервера делает нерабочим весь кластер. Смысла в таком немного.
Ну, это прелести шардинга по-любому. В NoSQL вы получите то же самое. Для стабильности имеем другой тип решений, который никак шардингу не противоречит — скажем, Aсtive-Passive схема на каждой "ноде". ANS>btw, если бы так всё было просто, то Oracle RAC не стоил бы столько сколько он стоит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Сопоставь это по эффективности со случаем, когда при добавлении твита добавляются соответствущие связки "твит-фоловер". И не забудь при этом, что твиттер читают больше чем пишут. S>Ну, давайте сопоставим. Вы мне объясните, что вы называете "связками". Что в них входит? ID твита или сам твит?
В идеале, конечно сам твит, благо размер позволяет.
L>>И приди к выводу, что единственным приемлемым вариантом будет именно вариант с добавлением связок. S>Не забегайте впердё. Сначала надо таки сопоставить.
Да я не забегаю, приходить-то тебе, не мне. Я уже тут стою, жду когда подойдешь.
L>>После того, как придешь к такому выводу, взгляни открывшимися глазами на свою фразу про "от силы десяток записей". S>Ещё раз поясню для тех, кто медленно читает: записей там ровно столько, сколько раз пользователь твитнул. Всё остальное, ненаблюдаемое пользователем — это индексы, т.е. денормализация данных, прикрученная для ускорения определённого типа запросов.
Ой-йо, у вас еще и для индекса свое определение? Не, с такими фокусниками я не играю.
S>Вы думаете, что вы умнее меня, и у вас есть в запасе более эффективная схема индексов, чем я придумал.
Опа, опять подтасовка. То, что возможна более эффективная схема вовсе не значит, что я умнее.
Если не сложно, воздержитесь впредь от подобного рода переходов, ок? Давайте обсуждать задачу, а не участников.
S>Даже если это и так (в чём у меня есть обоснованные сомнения), это никак не противоречит моему изначальному высказыванию.
А по-моему, все-таки противоречит. Если мы трактует понятие записи и индекса так, как это принято в СУБД, то эффективная схема — это все-таки схема с ручной денормализацией, а это означает, что записей-таки будет далеко не десяток, а гораздо больше.
S>С большой-большой вероятностью мы и придуманную вами схему, какова бы она ни была, положим в RDBMS в виде ещё какого-то индекса, и insert into останется одиноким.
Да что же это такое, опять. То свое определение "записи", потом свое определение "индекса", а теперь уже наличие единственно записи приравняли к кол-ву insert-ов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, _ABC_, Вы писали:
ANS>Если СУБД это то, что создаёт, и удаляет отдельные БД — то не знаю. Но то, что это сервер управляющий данными — это однозначно.
Есть определения термина СУБД. Мне известно следующее, например:
СУБД — программное обеспечение, контролирующее организацию, хранение, целостность, внесение изменений, чтение и безопасность информации в базе данных СУБД
Если flockDB соответствует этому определению, то это СУБД с моей точки зрения. Но по твоему описанию, оно СУБД не является и близко, т.к. не обеспечивает как минимум хранение данных, их чтение, изменение и безопасность, а перекладывает эти функции на РСУБД.
ANS>И всё же не съезжай. Назови это "решение". Это решение SQL потому, что там где-то внизу mysql, noSql — потому, что api не разу не sql и гарантии другие?
Это "решение" по твоему описанию суть банальный клиент к РСУБД. Это может быть часть клиентского решения, это может быть часть сервера приложений и т.д. Но по отношению к РСУБД это просто клиент, работающий с РСУБД и отдающий данные в своем формате.
_AB>>Можно раскрыть тему? В том смысле, что наличие решения делает эту проблему "еще более идиотской".
ANS>есть проблема, есть решение, которое подразумевает исключительно индивидуальный подход в каждому случае. ну не идиотизм ли?
По-моему, нет. Есть куча ошибок и проблем в ИТ, исправление и решение которых подразумевает исключительно индивидуальный подход в каждом случае. Это не идиотизм — это реальный мир.
E>>ок, поставлю вопрос иначе. возьмем чисто 10. запись его в текстовый файл или в бд. что будет быстрее? S>В первом приближении — одинаково. А вы как думаете?
То есть, сиквел положит число в файл? Ничего не будет индексировать? Не будет проверять и увеличивать размер файла базы данных при необходимости? Не будет писать лог? То есть сиквел, когда кладет запись в базу, ничего больше не делает? правильно?
что ж, тогда да. сиквел работает на запись так же быстро как и обычная запись в файл.
А вы не подскажите, почему, например, MySQL справляется с записью 4-5к строк в секунду, а MS SQL нет? ведь он же ничего не делает, а просто пишет в файл
Здравствуйте, Lloyd, Вы писали: S>>Ну, давайте сопоставим. Вы мне объясните, что вы называете "связками". Что в них входит? ID твита или сам твит? L>В идеале, конечно сам твит, благо размер позволяет.
Отлично. Давайте сопоставлять.
То есть в вашей схеме мы имеем фактически
create table followedtweets(
follower int not null foreign key references authors,
stamp datetime not null
author int not null foreign key references authors,
tweet varchar(80)
)
Предположим также, что мы на неё навернули clustered index по всем полям в перечисленном порядке, благо это не увеличивает размеры.
Что же мы имеем? Мы имеем при выполнении упомянутого выше запроса index seek, который быстро находит все нужные нам записи.
Количество чтений у нас = <количество найденных твитов>*(sizeof(int)+sizeof(int)+sizeof(datetime)+80)/NetPageSize.
Давайте сопоставим его с количеством чтений в "моём" варианте.
Там читается два места:
1. followKey — index seek. Количество чтений = <количествоТехКогоФолловим>*(sizeof(int)+sizeof(int))/NetPageSize.
2. followIndex — index seek. Количество чтений = <количество найденных твитов>*(sizeof(int)+sizeof(datetime)+80)/NetPageSize
Давайте зададим какие-нибудь разумные оценки для наших переменных. Предположим, что NetPageSize = 8000 байт. количествоТехКогоФолловим зададим, скажем, 500. Получится, что followKey справится за 1 чтение. Дальше у нас поедут сравнение <количества найденных твитов> * 92 с <количества найденных твитов> * 96, т.е. 4 байта на твит. Итого, количество чтений followIndex будет таким же, как для вашей "оптимизированной" схемы, пока у нас количество твитов в пределах пары тысяч.
Итого, в оптимистичном (для вас) сценарии, получаем разницу в 1 операцию чтения. L>>>И приди к выводу, что единственным приемлемым вариантом будет именно вариант с добавлением связок.
Пока не вижу никакой неприемлемости у моего варианта.
L>Да я не забегаю, приходить-то тебе, не мне. Я уже тут стою, жду когда подойдешь.
Всё-таки забежали, раз "уже тут".
L>Ой-йо, у вас еще и для индекса свое определение? Не, с такими фокусниками я не играю.
Почти в точности совпадает с create index.
L>Опа, опять подтасовка. То, что возможна более эффективная схема вовсе не значит, что я умнее.
Ну, я вам польстил.
L>А по-моему, все-таки противоречит. Если мы трактует понятие записи и индекса так, как это принято в СУБД, то эффективная схема — это все-таки схема с ручной денормализацией, а это означает, что записей-таки будет далеко не десяток, а гораздо больше.
Давайте вы уже нарисуете вашу схему. А то что-то многовато бисера получается.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали: E>То есть, сиквел положит число в файл? Ничего не будет индексировать? Не будет проверять и увеличивать размер файла базы данных при необходимости? Не будет писать лог?
1. Сиквел запишет лог. Там, помимо этого числа, будут ещё служебные данные, но на скорость это никак не повлияет. Потому что стоимость flush в пределах одного блока (обычно — около 64к) строго одинакова.
2. "Индексировать" сиквел будет только если ему об этом сказать. В NoSQL случае вы получите то же самое — только индекс вы будете поддерживать руками.
3. Проверять и увеличивать размер файла придётся хоть FileWrite, хоть сиквелу. Увы.
4. Само число в файл данных уедет ещё не скоро. Только когда грязных страниц станет слишком много, и сиквел решит, что пора бы их записать. В одну страничку таких чисел влазит примерно 2000, т.е. стоимостью операции сброса кеша на диск в контексте добавления чисел можно пренебречь.
E>А вы не подскажите, почему, например, MySQL справляется с записью 4-5к строк в секунду, а MS SQL нет? ведь он же ничего не делает, а просто пишет в файл
Потому, что вы не умеете готовить MS SQL, а MySQL вас обманывает. Он не может делать 5000 коммитов в секунду, если только вы не используете SSD диск.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали:
L>Сопоставь это по эффективности со случаем, когда при добавлении твита добавляются соответствущие связки "твит-фоловер". И не забудь при этом, что твиттер читают больше чем пишут. L>И приди к выводу, что единственным приемлемым вариантом будет именно вариант с добавлением связок.
Э, а ты посчитай в IOPSах.
Вообще, Твиттер — не так уж и нагружен. 6000 простых пишущих транзакций в секунду в пике, 70000 читающих в секунду, транзакции очень маленькие, данные фиксированной длины. При этом все операции можно делать в режиме dirty read, чтения все хорошо укладываются в кэш сервера.
Интересно, сколько из 1000 серверов Твиттера работают собственно с твитами? Решение на 1M tpmC стоит где-то 500K$, т.е. примерно как 300 серверов.
Впрочем, это бы обеспечивало совершенно излишние гарантии и QoS, так что можно было бы обойтись десятком относительно дешевых машинок и Q-replication или вообще HADR. При таких небольших нагрузках на запись это вполне достаточно, а стоило бы где-то 100K$ со всеми лицензиями. Главное — не MySQL
E>>А вы не подскажите, почему, например, MySQL справляется с записью 4-5к строк в секунду, а MS SQL нет? ведь он же ничего не делает, а просто пишет в файл S>Потому, что вы не умеете готовить MS SQL, а MySQL вас обманывает. Он не может делать 5000 коммитов в секунду, если только вы не используете SSD диск.
нет, mysql нас не обманывает. а ms sql просто постоянно увеличивает размер страницы, на что уходит дофига времени, которое он не может принимать запросы.
а SSD не нужен. достаточно 10го рейда.
Здравствуйте, Sinclair, Вы писали:
S>Предположим также, что мы на неё навернули clustered index по всем полям в перечисленном порядке, благо это не увеличивает размеры. S>Что же мы имеем? Мы имеем при выполнении упомянутого выше запроса index seek, который быстро находит все нужные нам записи. S>Количество чтений у нас = <количество найденных твитов>*(sizeof(int)+sizeof(int)+sizeof(datetime)+80)/NetPageSize. S>Давайте сопоставим его с количеством чтений в "моём" варианте. S>Там читается два места: S>1. followKey — index seek. Количество чтений = <количествоТехКогоФолловим>*(sizeof(int)+sizeof(int))/NetPageSize. S>2. followIndex — index seek. Количество чтений = <количество найденных твитов>*(sizeof(int)+sizeof(datetime)+80)/NetPageSize
Забыл учесть количество просмотров индексов = кол-ву количествоТехКогоФолловим, в итоге твиты оказываются разбросанными по нескольким "сегментам".
S>Давайте зададим какие-нибудь разумные оценки для наших переменных. Предположим, что NetPageSize = 8000 байт. количествоТехКогоФолловим зададим, скажем, 500. Получится, что followKey справится за 1 чтение. Дальше у нас поедут сравнение <количества найденных твитов> * 92 с <количества найденных твитов> * 96, т.е. 4 байта на твит. Итого, количество чтений followIndex будет таким же, как для вашей "оптимизированной" схемы, пока у нас количество твитов в пределах пары тысяч.
Ты не то считаешь, надо смотреть не общий объем данных, считанных с диска, а количество обращений к нему.
В варианте с денормализацией все твиты будут лежать рядышком, в твоем варианте они будут разбросаны по диску в произвольном порядке. А при твоем предположении, что фоловеров — 500, это означает, что вы будет считывать в среднем случае 500 страниц, не считая того, что придется считывать при просмотре индекса.
S>Итого, в оптимистичном (для вас) сценарии, получаем разницу в 1 операцию чтения. L>>>>И приди к выводу, что единственным приемлемым вариантом будет именно вариант с добавлением связок. S>Пока не вижу никакой неприемлемости у моего варианта.
Для этого надо глаза открыть, и посмотреть.
L>>А по-моему, все-таки противоречит. Если мы трактует понятие записи и индекса так, как это принято в СУБД, то эффективная схема — это все-таки схема с ручной денормализацией, а это означает, что записей-таки будет далеко не десяток, а гораздо больше. S>Давайте вы уже нарисуете вашу схему. А то что-то многовато бисера получается.
Здравствуйте, Дельгядо Филипп, Вы писали:
L>>Сопоставь это по эффективности со случаем, когда при добавлении твита добавляются соответствущие связки "твит-фоловер". И не забудь при этом, что твиттер читают больше чем пишут. L>И приди к выводу, что единственным приемлемым вариантом будет именно вариант с добавлением связок.
ДФ>Э, а ты посчитай в IOPSах.
Здравствуйте, Enomay, Вы писали:
E>нет, mysql нас не обманывает. а ms sql просто постоянно увеличивает размер страницы, на что уходит дофига времени, которое он не может принимать запросы.
Впервые слышу, чтобы MS SQL увеличивал размер страницы, который в нём с версии 7.0 фиксирован на 8K.
Но я не претендую на исчерпывающие знания его поведения, тем более что моя работа с ним стала значительно менее ежедневной, начиная года примерно с 2003го. E>а SSD не нужен. достаточно 10го рейда.
А сколько у вас дисков в рейде? 80?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали:
E>нет, mysql нас не обманывает. а ms sql просто постоянно увеличивает размер страницы, на что уходит дофига времени, которое он не может принимать запросы. E>а SSD не нужен. достаточно 10го рейда.
Размер какой страницы постоянно увеличивает MS SQL Server?
E>>нет, mysql нас не обманывает. а ms sql просто постоянно увеличивает размер страницы, на что уходит дофига времени, которое он не может принимать запросы. S>Впервые слышу, чтобы MS SQL увеличивал размер страницы, который в нём с версии 7.0 фиксирован на 8K. S>Но я не претендую на исчерпывающие знания его поведения, тем более что моя работа с ним стала значительно менее ежедневной, начиная года примерно с 2003го.
я вероятно ошибся, не страницу, а размер файла базы. или как-то так. я деталей не помню.
E>>а SSD не нужен. достаточно 10го рейда. S>А сколько у вас дисков в рейде? 80?
4. стандарт.
тип базы в мускуле стоит наверное MyISAM, или что-то в этом роде. без поддержки транзакций.
Здравствуйте, Lloyd, Вы писали:
L>Забыл учесть количество просмотров индексов = кол-ву количествоТехКогоФолловим, в итоге твиты оказываются разбросанными по нескольким "сегментам". L>Ты не то считаешь, надо смотреть не общий объем данных, считанных с диска, а количество обращений к нему. L>В варианте с денормализацией все твиты будут лежать рядышком, в твоем варианте они будут разбросаны по диску в произвольном порядке. А при твоем предположении, что фоловеров — 500, это означает, что вы будет считывать в среднем случае 500 страниц, не считая того, что придется считывать при просмотре индекса.
Ок, принято. Да, видать старею.
L>Судя по поведению, свинья тут все-таки ты.
Ну, вы могли бы не выделываться, а сразу показать результат. Ок, вернёмся к исходной теме про "индексы и записи".
Чтобы реализовать волшебную схему, нам достаточно сделать следующее:
1. create view по джойну двух таблиц
2. create clustered index по этому view, включив в него все нужные поля.
Без изменения схемы, мы получаем тот же результат. Записей на каждый твит будет ровно одна; денормализацию (при помощи индексов, как я и обещал) станет выполнять движок. У этого подхода есть некоторое преимущество — в лог при коммите уезжает 1 изменение, а не 500. С учётом маленького размера твитов это не катастрофическая разница, но для больших количеств фолловеров и она может оказаться существенной.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали: E>я вероятно ошибся, не страницу, а размер файла базы. или как-то так. я деталей не помню.
Ну, с этим бороться легко — достаточно заранее увеличить размер базы.
E>>>а SSD не нужен. достаточно 10го рейда. S>>А сколько у вас дисков в рейде? 80? E>4. стандарт.
Тогда у вас при всём желании не будет больше 400 IOPS, что в десять раз меньше заявленного количества записей в секунду.
E>тип базы в мускуле стоит наверное MyISAM, или что-то в этом роде. без поддержки транзакций.
А, ну так я же говорю — он вас обманывает. Транзакций нет — значит нет и коммитов. Т.е. никаких гарантий durability у вас нет, и отказ сервера будет означать кирдык вашей базе. Сравнивать с MS SQL смысла нет, делаются разные вещи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Забыл учесть количество просмотров индексов = кол-ву количествоТехКогоФолловим, в итоге твиты оказываются разбросанными по нескольким "сегментам". L>>Ты не то считаешь, надо смотреть не общий объем данных, считанных с диска, а количество обращений к нему. L>>В варианте с денормализацией все твиты будут лежать рядышком, в твоем варианте они будут разбросаны по диску в произвольном порядке. А при твоем предположении, что фоловеров — 500, это означает, что вы будет считывать в среднем случае 500 страниц, не считая того, что придется считывать при просмотре индекса. S>Ок, принято. Да, видать старею.
Все там будем.
L>>Судя по поведению, свинья тут все-таки ты. S>Ну, вы могли бы не выделываться, а сразу показать результат.
Извини, но судя по рейтингу, я не ожидал, что такая банальность будет неочевидной метателю бисера.
S>Ок, вернёмся к исходной теме про "индексы и записи". S>Чтобы реализовать волшебную схему, нам достаточно сделать следующее: S>1. create view по джойну двух таблиц S>2. create clustered index по этому view, включив в него все нужные поля.
S>Без изменения схемы, мы получаем тот же результат. Записей на каждый твит будет ровно одна; денормализацию (при помощи индексов, как я и обещал) станет выполнять движок.
Не совсем тот же. Если я зафоловил кого-то, то с какой стати у меня окажутся старые посты? А если расфоловил, то куда пропали те, что были в ленте?
S>У этого подхода есть некоторое преимущество — в лог при коммите уезжает 1 изменение, а не 500.
Уверен?
S>С учётом маленького размера твитов это не катастрофическая разница, но для больших количеств фолловеров и она может оказаться существенной.
Здравствуйте, Lloyd, Вы писали:
S>>Без изменения схемы, мы получаем тот же результат. Записей на каждый твит будет ровно одна; денормализацию (при помощи индексов, как я и обещал) станет выполнять движок.
L>Не совсем тот же. Если я зафоловил кого-то, то с какой стати у меня окажутся старые посты? А если расфоловил, то куда пропали те, что были в ленте?
Результат — строго тот же, что в описанной схеме. Сам запрос я намеренно упростил. Но главное — в том, что что бы мы ни делали, у нас будет ровно 1 view, построенный так, чтобы по нему эффективно выполнялся запрос. И не более 1 кластерного индекса по этому view. Который мы добавим тогда, когда увидим в том реальную нужду.
Ну, то есть если будут другие запросы, для которых захочется денормализации, мы добавим индексированные view и для них.
S>>У этого подхода есть некоторое преимущество — в лог при коммите уезжает 1 изменение, а не 500.
L>Уверен?
Отож. РСУБД тоже не дураки пишут; зачем им в логе записывать изменения в индексах — они однозначно восстанавливаются по изменениям в таблицах.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>Без изменения схемы, мы получаем тот же результат. Записей на каждый твит будет ровно одна; денормализацию (при помощи индексов, как я и обещал) станет выполнять движок.
L>>Не совсем тот же. Если я зафоловил кого-то, то с какой стати у меня окажутся старые посты? А если расфоловил, то куда пропали те, что были в ленте? S>Результат — строго тот же, что в описанной схеме.
Значит и описаная схема страдает этим недостатоком, в отличии от ручной денормализации.
S>Здравствуйте, Enomay, Вы писали: E>>я вероятно ошибся, не страницу, а размер файла базы. или как-то так. я деталей не помню. S>Ну, с этим бороться легко — достаточно заранее увеличить размер базы.
А на сколько? на 20 гигов? 80? 200? это база для сырых данных. но они хранятся вечно. на сколько увеличить базу? на макс размер свободного места?
E>>>>а SSD не нужен. достаточно 10го рейда. S>>>А сколько у вас дисков в рейде? 80? E>>4. стандарт. S>Тогда у вас при всём желании не будет больше 400 IOPS, что в десять раз меньше заявленного количества записей в секунду.
ну пишет же.
E>>тип базы в мускуле стоит наверное MyISAM, или что-то в этом роде. без поддержки транзакций. S>А, ну так я же говорю — он вас обманывает. Транзакций нет — значит нет и коммитов. Т.е. никаких гарантий durability у вас нет, и отказ сервера будет означать кирдык вашей базе. Сравнивать с MS SQL смысла нет, делаются разные вещи.
так и не нужны там транзакции. это статистические данные. небольшая их потеря не катастрофична. зато скорость.
Здравствуйте, Enomay, Вы писали:
E>А на сколько? на 20 гигов? 80? 200? это база для сырых данных. но они хранятся вечно. на сколько увеличить базу? на макс размер свободного места?
Настолько, насколько вам нужно. У вас же есть информация о том, сколько гигов в день вы добавляете?
Умножьте на количество дней, в течение которых вы не хотите заморачиваться с resize database, и получите нужное значение. Укажите его в качестве auto-growth.
E>ну пишет же.
Вы не понимаете, что такое "пишет". Он не пишет, а буферизует. А пишет по-прежнему 400 раз в секунду (а то и меньше, в зависимости от соотношения размера записи к размеру страницы).
S>>А, ну так я же говорю — он вас обманывает. Транзакций нет — значит нет и коммитов. Т.е. никаких гарантий durability у вас нет, и отказ сервера будет означать кирдык вашей базе. Сравнивать с MS SQL смысла нет, делаются разные вещи. E>так и не нужны там транзакции. это статистические данные. небольшая их потеря не катастрофична. зато скорость.
Если потеря не катастрофична, то вам, действительно, не нужна никакая база данных. Пишите в текст, потом будете BULK IMPORT при низкой нагрузке
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали:
L>Значит и описаная схема страдает этим недостатоком, в отличии от ручной денормализации.
Вы не стесняйтесь, опишите схему "ручной денормализации". А я гляну, будет ли она ложиться на индексы, или нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Значит и описаная схема страдает этим недостатоком, в отличии от ручной денормализации. S>Вы не стесняйтесь, опишите схему "ручной денормализации". А я гляну, будет ли она ложиться на индексы, или нет.
Ты ее сам описал несколькими постами выше и сам же рассмотрел, что там с индексами.
Здравствуйте, Enomay, Вы писали:
S>>Здравствуйте, Enomay, Вы писали: E>>>я вероятно ошибся, не страницу, а размер файла базы. или как-то так. я деталей не помню. S>>Ну, с этим бороться легко — достаточно заранее увеличить размер базы.
E>А на сколько? на 20 гигов? 80? 200? это база для сырых данных. но они хранятся вечно. на сколько увеличить базу? на макс размер свободного места?
Ну, вообще обычно просто вешают отправку SMS на момент, когда пустого места осталось мало. Или указывают стратегию роста "автоматом". Ресурсов БД это не требует.
S>>Тогда у вас при всём желании не будет больше 400 IOPS, что в десять раз меньше заявленного количества записей в секунду. E>ну пишет же.
Если в MS SQL включить один коммит на 10000 записей, он и больше запишет. И поставить table lock (т.е. реализовать MyISAM).
А атомарных коммитов по одной записи что у MyISAM, что у MS SQL будет примерно одинаково (у MS побольше при правильной настройке).
А еще можно включить кэширование на рейде, так еще больше будет )
Вообще, прежде чем сравнивать разные БД — почитали бы хоть что-нибудь...
Здравствуйте, _ABC_, Вы писали:
_AB>Есть определения термина СУБД. Мне известно следующее, например: _AB>
_AB>СУБД — программное обеспечение, контролирующее организацию, хранение, целостность, внесение изменений, чтение и безопасность информации в базе данных СУБД
_AB>Если flockDB соответствует этому определению, то это СУБД с моей точки зрения. Но по твоему описанию, оно СУБД не является и близко, т.к. не обеспечивает как минимум хранение данных, их чтение, изменение и безопасность, а перекладывает эти функции на РСУБД.
Как раз наоборот. Этому определению соответствует на все 100. Потому, что в твоём определении написано не "обеспечивает", а "контроллирует". В том что оно контроллирует "организацию, хранение, целостность, внесение изменений, чтение" сомневаться не приходится.
ANS>>И всё же не съезжай. Назови это "решение". Это решение SQL потому, что там где-то внизу mysql, noSql — потому, что api не разу не sql и гарантии другие? _AB>Это "решение" по твоему описанию суть банальный клиент к РСУБД. Это может быть часть клиентского решения, это может быть часть сервера приложений и т.д. Но по отношению к РСУБД это просто клиент, работающий с РСУБД и отдающий данные в своем формате.
Т.е., по-твоему, если в этот "банальный клиент" втулить библиотеку для работы с InnoDB, то это превратится в СУБД, а пока — мордой не вышел? идея интересная, но таким философствованием я не хочу заниматься.
Здравствуйте, Enomay, Вы писали:
E>я вероятно ошибся, не страницу, а размер файла базы. или как-то так. я деталей не помню.
Не "не помню", а "не знаю".
Размер файла данных для того же MS SQL Server давным давно (с версии 2005, ЕМНИП) увеличивается мгновенно. Это раз.
Два — для того, чтобы увеличение размера файла стало системной проблемой, нужно чтобы администратор системы занимался не сопровождением, а целенаправленным вредительством.
ANS>>Во-первых, что там будет с транзакциями? S>Ну, во-первых, большинство транзакций таки попадают внутрь одного сервера (или шардинг сделан неудачно). S>Во-вторых, если таки нет, то из коробки есть 2-phase commit.
Это проблема, а не решение
S>А что у нас есть для этого случая на стороне NoSQL?
eventual consistency
S>С чего это вдруг у меня полезут межсерверные дедлоки? Поясните. S>Это выливается в N параллельных селектов, которые отправляются на N серверов. Результат затем сливается, и всё это прозрачно для клиента.
Т.к. зачастую данные из БД не только читают, но еще и пишут, то блокировки возможны. Наличие не одного сервера, а даже двух усложняет ситуацию.
ANS>>Плюс, с точки зрения стабильности — выпадение любого сервера делает нерабочим весь кластер. Смысла в таком немного. S>Ну, это прелести шардинга по-любому. В NoSQL вы получите то же самое. Для стабильности имеем другой тип решений, который никак шардингу не противоречит — скажем, Aсtive-Passive схема на каждой "ноде".
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Lloyd, Вы писали: S>Отлично. Давайте сопоставлять.
Вообще, дневной объем твитов — где-то 24гига, т.е. 99% твитов у нас точно в памяти сервера. Так что IOPS считать не нужно, скорее нужно думать, как бы оптимизировать поиск внутри закэшированных страниц, на производительность скорее будет сказываться именно он.
И тут общий объем информации в памяти начинает играть большую роль, нежели "последовательность хранения связанных твитов".
И если брать старшие сервера БД, то можно, например, партицировать данные по дате, с хранением свежих партиций на SSD и плавным их переносом на жесткие диски. Делается это вполне себе штатными средствами.
Ну и еще не надо забывать, что "все твиты в ленте" мне нафиг не нужны, нужно, обычно, последние 20-30. И запросы со структурой нужно оптимизировать на такие задачи
Но вот сколько процессоров нужно, что бы просто отдавать 70000 простых join в секунду — мне слабо посчитать, IOPS тут уже не помогают Впрочем, судя по количеству процессоров даже в топовых конфигуруциях на TPC-C — не так уж и много, 4-8 процессорной современной коробки должно хватить, а стоит это копейки
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Как раз наоборот. Этому определению соответствует на все 100. Потому, что в твоём определении написано не "обеспечивает", а "контроллирует". В том что оно контроллирует "организацию, хранение, целостность, внесение изменений, чтение" сомневаться не приходится.
Даже в официальной документации "это" именуется исключительно как "database". Никаких DBMS и прочего.Учитывая, что под "database" англоговорящие зачастую подразумевают что угодно от сайта-каталога до csv-файла, я могу согласиться с таким определением. FlockDB is a database but not a database management system.
А твое толкование делает любой клиент СУБД. Потому что клиент в значительной степени определяет что хранится в БД.
ANS>Т.е., по-твоему, если в этот "банальный клиент" втулить библиотеку для работы с InnoDB, то это превратится в СУБД, а пока — мордой не вышел?
Если еще при этом будет обеспечиваться контроль целостности, безопасности, то почему нет?
ANS>идея интересная, но таким философствованием я не хочу заниматься.
Еще бы, потому что тебе возразить нечего.
Здравствуйте, gandjustas, Вы писали: G>Это как раз мелочи, потому что планы кешируются.
По парсингу SQL:
Еще раз рекомендую просмотреть статью самурая на тему использования MySQL as NoSQL (там сделан упор на прямые PK_lookup-выборки из таблиц, но сути это не меняет). Японец пишет:
"MYSQLparse() and MYSQLlex() are called during SQL parsing phase. make_join_statistics() and JOIN::optimize() are called during query optimization phase. These are "SQL" overhead. It's obvious that performance drops were caused by mostly SQL layer, not by "InnoDB(storage)" layer. MySQL has to do a lot of things like below while memcached/NoSQL do not neeed to do.". Результат который они приводит, семикратное увеличение производительности за счет обхлда SQL layer (и связанных с ним операций на res locking, exec plans).
Конечно в статье есть определенная хитрость (какой "гений" будет выполнять 100k запросов в секунду, когда рекомендуемая эффективная стратегия для РСУБД отправлять запросы в более длинные временные интервалы), но цифры показывают что при не "очень удачной" реализации SQL layer разница может быть существенной. Опять же мейджорах процент времени разбора от общего времени выполнения составляет в среднем 3-5% для сложных запросов (думаю за счет реализации собственных оптимизированных процессоров запросов, а не стандартных парсеров на lex — но это моя теория ), что по сути очень круто для конечно пользователя.
По планам которые кэшируются:
Кэшируются и отлично. Но фанатичный noSQL-щик скажет, что это полумера (я считаю очень эффективная). Напр. для mssql есть LRU, прогон по статистике, опять же всегда найдется боец который жестко закодирует параметры запроса (sql server не всегда может решить эту проблему)
G>>>Индексы в NoSQL зачастую крайне неэффективны, у того же couchDB используется lucene куда помещается ВСЕ, объем индекса иногда превосходит объем данных в несколько раз. __>>А чем по вашему индексы noSQL отличаются от индексов RDBMS ? G>Как минимум тем что: G>1) РСУБД имеет регулярную структуру. Например нет множественных значений. G>2) Индекс РСУБД оптимизирован по размеру. G>3) Операции в СУБД отличаются, поэтому и индексы отличаются. G>Не, там еще есть индексы. Причем зачастую индексы довольно "тяжелые", то есть пересчет их в реальном времени сильно затратен. Поэтому индексы считаются асинхронно в большинстве случаев.
По индексам я отдельно напишу, если время будет. Тема уж слишком тяжелая и многословная
G>Действительно что мешает? Но пока в mongodb (самая массовая nosql на сегодня) — writelock на сервер. G>Так что "неверно" это только теоретически.
Почему вы уперлись в эту злосчастную монго_дб? Может это косяк разработчиков конкретно этой системы? Это сравнение mssql и mongo db? На самом деле есть взрослые noSQL от мейджора, напр. IBM IMS, если сравнивать то с подобными
G>Кстати я вообще сомневаюсь что в распределенной среде управление блокировками будет хоть как-то работать (когда много серверов с БД и много frontend серверов).
Тут вам стоит раскрыть, я не понял. А есть примеры когда это круто работает в распределенной среде RDBMS? Это проблема скорее общая для всех СУБД, напр. в Dynamo ее пытаются решать.
__>>Такие фичи как (качественная система журналирования) правило продаются за деньги . Не уровень open source noSQL. G> G>Во всех взрослых РСУБД оно есть, в том числе в бесплатных версиях.
Я в других постах уже доказывал, что все взрослые РСУБД имеют не "бесплатные" версии а "бесплатные с ограничениям" версии. Неужели вы всерьез думаете что мейджор вам что-то даст бесплатно? У русских есть пословица — бесплатный сыр бывает только в мышеловке.
G>Это бредятина, которую сторонники опенсорса рассказывают. vendor lock-in в первую очередь происходит от приложений, а не от БД. Как ни крути ты не заставишь 1С работать на nosql. G>В банках вообще поголовно MS SQL \ oracle, за такие бабки, что не снилось и никто не думает о "избежать vendor lock-in". Vendor lock in происходит тогда, когда ты вдруг утром просыпаешься, а у тебя трусы с логотипом Oracle, а других и нет. Или включаешь новости а там сопливый 18-летний евангелист из MS вещает о преимуществах очередного ObjectSpaces .Net 2013 (но надо срочно внедрять бету2, а то отстанешь от рынка!!!) и тебе уже сильно хочется в Unix, ан нет будешь внедрять. Т.е. отходя от шуток когда весь enterprise, на котором строится бизнес вдруг принадлежит одной компании. Я напр. много раз видел как MS мягко "навязывала" тем же банкам свои "обновленные продукты" и лицензии. Печальное зрелище.
А сторонникам опенсорса здесь разгул — им нет нужды жрать это маркетинговое дерьмо. Но и делать все приходится самим (а жизнь как известно коротка ).
G>А то что многие по веб-протоколам работают, а IIS имеет хороший пайплайн по обработке запросов, авторизации, кешированию и прочим радостям. Да и не-веб протоколы тоже поддерживаются.
Теперь я понял, о чем вы. Тут я не эксперт, но использование подобных "веб-протоколов" в СУБД для меня огромный жирный минус. Впрочем это дело вкуса.
Здравствуйте, a_g_99, Вы писали:
__>Почему вы уперлись в эту злосчастную монго_дб? Может это косяк разработчиков конкретно этой системы? Это сравнение mssql и mongo db? На самом деле есть взрослые noSQL от мейджора, напр. IBM IMS, если сравнивать то с подобными
И это говорят люди, которые приводят ссылки исключительно на mySQL?
__>Я в других постах уже доказывал, что все взрослые РСУБД имеют не "бесплатные" версии а "бесплатные с ограничениям" версии. Неужели вы всерьез думаете что мейджор вам что-то даст бесплатно? У русских есть пословица — бесплатный сыр бывает только в мышеловке.
Ничего ты не доказывал. Были голословные утверждения типа "мне неподошло" и все на этом.
То, что бесплатные версии имеют ограничения — известно и без тебя. Только вот ты утверждаешь, что ни для чего кроме демонстрации технологии и презентации они не подходят, хотя это далеко не так.
Здравствуйте, a_g_99, Вы писали:
__>Еще раз рекомендую просмотреть статью самурая на тему использования MySQL as NoSQL (там сделан упор на прямые PK_lookup-выборки из таблиц, но сути это не меняет). Японец пишет:
Ну, гм, MySQL — очень сомнительный пример для сравнения с РСУБД. Т.е. я охотно верю, что там все плохо. Но для взрослых БД таких проблем, насколько я знаю, нет.
А если еще работать с нормальными библиотеками и prepared statment, то парсинга запроса вообще не происходит, никакого.
G>>Так что "неверно" это только теоретически. __>Почему вы уперлись в эту злосчастную монго_дб? Может это косяк разработчиков конкретно этой системы? Это сравнение mssql и mongo db? На самом деле есть взрослые noSQL от мейджора, напр. IBM IMS, если сравнивать то с подобными
Так, вроде бы, против специализированных NoSQL решений, используемых для конкретных задач — никто не выступает.
Проблема с малообразованными фанатиками, считающими, что сомнительные поделки типа mongo — наше будущее. Тот же IMS — очень хорошее, хотя и очень нишевое (и очень дорогое) решение.
G>>Во всех взрослых РСУБД оно есть, в том числе в бесплатных версиях. __>Я в других постах уже доказывал, что все взрослые РСУБД имеют не "бесплатные" версии а "бесплатные с ограничениям" версии. Неужели вы всерьез думаете что мейджор вам что-то даст бесплатно? У русских есть пословица — бесплатный сыр бывает только в мышеловке.
Есть еще Postgres. Да и в ограничения DB2 Express C надо еще упереться
Вообще, всякие поделки типа mongo или mysql действительно удобны для стартапов, когда важность проекта и данных на первом этапе равна нулю, а вот когда вырастает — тогда выростает.
Не думаю, что создатели больших систем на любой из этих БД, если бы проектировали их с нуля, выбрали бы такие же решения.
Широкое использование php, mysql, mongo и т.п. — в основном legacy (ну и мода...)
Здравствуйте, _ABC_, Вы писали:
ANS>>Как раз наоборот. Этому определению соответствует на все 100. Потому, что в твоём определении написано не "обеспечивает", а "контроллирует". В том что оно контроллирует "организацию, хранение, целостность, внесение изменений, чтение" сомневаться не приходится. _AB>Даже в официальной документации "это" именуется исключительно как "database". Никаких DBMS и прочего.Учитывая, что под "database" англоговорящие зачастую подразумевают что угодно от сайта-каталога до csv-файла, я могу согласиться с таким определением. FlockDB is a database but not a database management system. _AB>А твое толкование делает любой клиент СУБД. Потому что клиент в значительной степени определяет что хранится в БД.
Не любой. Эта штука фиксирует интерфейс. Клиент не работает с нижележащими структурами в обход этого интерфейса.
ANS>>Т.е., по-твоему, если в этот "банальный клиент" втулить библиотеку для работы с InnoDB, то это превратится в СУБД, а пока — мордой не вышел? _AB>Если еще при этом будет обеспечиваться контроль целостности, безопасности, то почему нет?
Занятно. То есть замена in-proc call на RPC превращает СУБД в клиента? А то, что сама РСУБД хранение данных не обеспечивает, а это обеспечивает NAS случайно не превращает РСУБД в не-СУБД?
Это всё словоблудие. По сути ты считаешь, что РДБ самоценны, и двигаться дальше не нужно. Хотя сейчас уже очевидно, что на их основе можно строить системы которые добавляют ценности к РБД. Эти новая система обладают характеристиками отличными от РБД, используя РБД как проверенное временем хранилище с известными возможностями. NoSql — not only sql. И это в сто тысяч раз лучше, чем реализация этих механизмов программерами в каждой программе по новому. Не хочешь называть это СУБД — как угодно, но обычно у этих систем есть свой протокол, свои механизмы контроля целостности, своя организация данных и чтобы этими системами пользоваться нужны знания отличные от SQL. Т.е. чтобы пользоваться FlockDB не нужны знания sql. И это хорошо.
ANS>>идея интересная, но таким философствованием я не хочу заниматься. _AB>Еще бы, потому что тебе возразить нечего.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Ну, гм, MySQL — очень сомнительный пример для сравнения с РСУБД. Т.е. я охотно верю, что там все плохо. Но для взрослых БД таких проблем, насколько я знаю, нет.
Вот постоянно вижу подобные забавные фразы про mysql и "взрослые бд". ))) Особенно смешит это если оно ещё и в контексте быстродействия, т.к. даже sql спецы признают что mysql очень часто уделывает все "взрослые бд", а претензии к ней идут в основном по функциональности, администрированию и т.п. Хотя вообще то и там не всё так однозначно, иначе не появлялись бы такие http://alex-at.ru/it/mssql темки (особенно забавно там в комментариях).
В общем если уж вы говорите о быстродействие, то лучше не смешите нас подобными заявлениями. Т.к. если я увижу где-то результаты тестирования что какая-то nosql база обошла mysql по скорости, то скорее всего это будет автоматом означать что она тем более обойдёт все "взрослые sql бд".
ДФ>Широкое использование php, mysql, mongo и т.п. — в основном legacy (ну и мода...)
Эээ, какая-то каша в этом списке.
php — действительно legacy.
mysql — текущая рабочая лошадка.
mongo — только зародилось (какое уж тут legacy?) и подаёт очень большие надежды.
Здравствуйте, a_g_99, Вы писали:
_AB>>Кроме того, PosеgreSQL, Firebird бесплатны со всех сторон, например. __>Про PostgreSQL я писал (Ingres) — не вижу перспектив данной системы
Ну мало ли что ты там не видишь. На практике — на редкость качественная для open source БД, существенно лучше того же FB или совсем коммерческой Sybase. Для энтерпрайза такой продукт и нужен, а не модные и сырые nosql.
... << RSDN@Home 1.2.0 alpha 5 rev. 33 on Windows 7 6.1.7601.65536>>
Здравствуйте, Lloyd, Вы писали:
L>Ты ее сам описал несколькими постами выше и сам же рассмотрел, что там с индексами.
И там всё прекрасно легло на индексы, но вас эта схема чем-то не устроила.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Т.к. зачастую данные из БД не только читают, но еще и пишут, то блокировки возможны. Наличие не одного сервера, а даже двух усложняет ситуацию.
Это не проблема, а решение. Что нам предложит NoSQL?
S>>Ну, это прелести шардинга по-любому. В NoSQL вы получите то же самое. Для стабильности имеем другой тип решений, который никак шардингу не противоречит — скажем, Aсtive-Passive схема на каждой "ноде". ANS>А что будет если slave упадёт?
Очевидно, повод поднять другой slave и реплицироваться на него
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Ты ее сам описал несколькими постами выше и сам же рассмотрел, что там с индексами. S>И там всё прекрасно легло на индексы, но вас эта схема чем-то не устроила.
Схема с "ручной денормализацией" — да, легла, я с этим и не спорил.
Здравствуйте, Lloyd, Вы писали:
L>Схема с "ручной денормализацией" — да, легла, я с этим и не спорил.
Я не понимаю, что вы называете "ручной денормализацией".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Схема с "ручной денормализацией" — да, легла, я с этим и не спорил. S>Я не понимаю, что вы называете "ручной денормализацией".
А 5 постов назад понимали:
Отлично. Давайте сопоставлять.
То есть в вашей схеме мы имеем фактически
...
Здравствуйте, Lloyd, Вы писали:
L>Видать, да, стареете.
А на три поста ниже я вам подробно расписал аналог этой схемы, организованный чисто декларативно, с view и index.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Видать, да, стареете. S>А на три поста ниже я вам подробно расписал аналог этой схемы, организованный чисто декларативно, с view и index.
И ровно постом ниже я ответил, что расписанная схема не является аналогом, т.к. при такой схеме не реализовать twitter-like функционал.
Настолько увлекся метанием бисера, что не хватает времени на чтение?
Здравствуйте, Lloyd, Вы писали:
L>И ровно постом ниже я ответил, что расписанная схема не является аналогом, т.к. при такой схеме не реализовать twitter-like функционал.
Я не настолько знаком с твиттером, чтобы понять по вашим скупым намёкам, где именно теряется аналог при замене table на view.
Если вам лень писать подробнее — прекратите меня троллить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>И ровно постом ниже я ответил, что расписанная схема не является аналогом, т.к. при такой схеме не реализовать twitter-like функционал. S>Я не настолько знаком с твиттером, чтобы понять по вашим скупым намёкам, где именно теряется аналог при замене table на view.
А это я для кого писал?
Не совсем тот же. Если я зафоловил кого-то, то с какой стати у меня окажутся старые посты? А если расфоловил, то куда пропали те, что были в ленте?
S>Если вам лень писать подробнее — прекратите меня троллить.
Если вам что-то было непонятно в том объяснении, вы могли бы и спросить. Я бы объяснил, мне не жалко.
Даже полу-намеками свиньей не стал бы вас называть, как это делали вы. Честно.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Ну, гм, MySQL — очень сомнительный пример для сравнения с РСУБД.
MySQL и есть РСУБД (причем от мейджора). И noSQL в тоже время с применением плагина HandlerSocket
>Т.е. я охотно верю, что там все плохо. Но для взрослых БД таких проблем, насколько я знаю, нет.
Просто нет исходного кода "взрослых" РСУБД для анализа. А тут есть.
И кстати там не так уж все плохо, иначе бы Facebook не использовала 12k MySQL-серверов в качестве основы своей платформы. Плюс есть бесплатная Percona (правда саппорт этой поделки стоит реально конских денег), которая обеспечивает неплохие возможности для вертикального масштабирования.
ДФ>А если еще работать с нормальными библиотеками и prepared statment, то парсинга запроса вообще не происходит, никакого.
Здесь вы о повторном использовании query/sp. Повторюсь — если для запроса уже есть план в кэше планов и контрольная сумма запроса совпадает, ок — проходит этап soft parse of query. Если нет — тогда все по взрослому.
ДФ>Так, вроде бы, против специализированных NoSQL решений, используемых для конкретных задач — никто не выступает. ДФ>Проблема с малообразованными фанатиками, считающими, что сомнительные поделки типа mongo — наше будущее. Тот же IMS — очень хорошее, хотя и очень нишевое (и очень дорогое) решение.
IMS действительно крут . Проблема в том, что фанатики с обеих сторон баррикад .
ДФ>Есть еще Postgres. Да и в ограничения DB2 Express C надо еще упереться
Про Postgres я спорить не хочу, думаю тема сравнения Postgres с другими бд отдельная. По поводу DB2 C exp — ну а куда там упираться ? С такими требованиями можно реализовать бэкэнд для блога домохозяйки или магазинчика хозтоваров . Я специально с сайта IBM вырезал ограничения для этой "прокаченной" версии :
"Тех. ограничения: используется максимум 2 ядра и 1 процессор, 2 Гб ОЗУ. Нет поддержки репликации и кластеризации, нет гарантии и возможности приобретения доп. пакетов ПО для расширения возможностей СУБД. Версии выпускаются без пакетов обновлений.". Как вообще тут масштабироваться (это в принципе невозможно)? И это самая "свободная по требованиям" express версия РСУБД от большой тройки. Подставляйте бокалы, кто пьет такое
Здравствуйте, Lloyd, Вы писали:
L>А это я для кого писал? L>
L>Не совсем тот же. Если я зафоловил кого-то, то с какой стати у меня окажутся старые посты? А если расфоловил, то куда пропали те, что были в ленте?
А почему вы думаете, что это поведение как-то будет отличаться от "табличной" реализации? Вы какую-то конкретную схему императивной логики додумали, да? Вот её я и просил вас описать. На вопросы "с какой стати" и "куда пропали" я вам ответить не могу иначе как "by design". Из той же оперы вопросы "почему у меня из исходящих в отправленные письма перемещаются автоматически, а из входящих в принятые — нет".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _ABC_, Вы писали:
_AB>И это говорят люди, которые приводят ссылки исключительно на mySQL?
А что вас так повеселило? Я уже приводил пример Facebook — mySQL основа их платформы, а у них 900 млн. пользователей. Я привел ссылку на mySQL, потому что это открытая для анализа платформа и вы можете воспроизвести результаты сравнения SQL и noSQL на ней.
_AB>Ничего ты не доказывал. Были голословные утверждения типа "мне неподошло" и все на этом.
См. другой мой пост
_AB>То, что бесплатные версии имеют ограничения — известно и без тебя. Только вот ты утверждаешь, что ни для чего кроме демонстрации технологии и презентации они не подходят, хотя это далеко не так.
Спасибо кэп. А я думал, что первый кто раскрыл всем глаза . Ну тогда go ahead, примеры в студию. И не вроде — "Сенсация! Пупкин_софт внедрил Sql Express на сайте шаурмы дяди Ашота! MongoDB в нокауте!!!", а чтобы все было по взрослому. Чтобы в портфолио были голдманиты, морган стэнли, банки шотландии, твиттеры, амазоны.
Даже всякий трэш типа 1С не рекомендует использовать express-ы.
Здравствуйте, Sinclair, Вы писали:
L>>А это я для кого писал? L>>
L>>Не совсем тот же. Если я зафоловил кого-то, то с какой стати у меня окажутся старые посты? А если расфоловил, то куда пропали те, что были в ленте?
S>А почему вы думаете, что это поведение как-то будет отличаться от "табличной" реализации?
Потому что на материализованых вьюхах "по джойну двух таблиц" вы не сделаете вариант, который бы не отличался по поведению от твитера.
S>Вы какую-то конкретную схему императивной логики додумали, да? Вот её я и просил вас описать.
Здравый смысл — вот название этой схемы: при посылке твита сообщение разбрасывается по лентам фоллоуеров.
Вот и вся логика.
S>На вопросы "с какой стати" и "куда пропали" я вам ответить не могу иначе как "by design".
Отсылка к "by design" тут тут вообще ни к месту, т.к. речь идет о реализации твитера, и следовательно "design" зафиксирован тем функционалом, что наблюдается в твитере.
Если реализация не удовлетворяет этому дизайну, то это уже не твитер, а что-то другое.
S>Из той же оперы вопросы "почему у меня из исходящих в отправленные письма перемещаются автоматически, а из входящих в принятые — нет".
Здравствуйте, Sinclair, Вы писали:
S>Это не проблема, а решение. Что нам предложит NoSQL?
я всё написал.
S>>>Ну, это прелести шардинга по-любому. В NoSQL вы получите то же самое. Для стабильности имеем другой тип решений, который никак шардингу не противоречит — скажем, Aсtive-Passive схема на каждой "ноде". ANS>>А что будет если slave упадёт? S>Очевидно, повод поднять другой slave и реплицироваться на него
хм. чтобы работал failover у тебя должна быть синхронная репликация. Это значит после падения реплики должен отключится мастер. Такая штука будет работать только в одном случае — если вероятность падения реплики намного меньше чем мастера. но с чего бы?
Здравствуйте, AndrewVK, Вы писали:
__>>Про PostgreSQL я писал (Ingres) — не вижу перспектив данной системы
AVK>Ну мало ли что ты там не видишь. На практике — на редкость качественная для open source БД, существенно лучше того же FB или совсем коммерческой Sybase. Для энтерпрайза такой продукт и нужен, а не модные и сырые nosql.
btw, изначально postgresql именовался постреляционной БД. Только я не помню почему Из-за наследования, что ли.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>хм. чтобы работал failover у тебя должна быть синхронная репликация. Это значит после падения реплики должен отключится мастер. Такая штука будет работать только в одном случае — если вероятность падения реплики намного меньше чем мастера. но с чего бы?
Имхо, вы не вполне верно трактуете сущность фейловера. Весь его смысл — в том, чтобы при одиночном отказе мы продолжили работу.
Нужно понимать, что одиночный отказ переведёт систему в "тревожное" состояние, при котором, очевидно, её избыточность уменьшится.
Неважно, кто нагнётся — мастер или слейв. После этого останется 1 мастер. Дальнейшие действия совершенно одинаковы: нужно восстановить слейва и подключить его к мастеру для репликации. Через некоторое время T, не зависящее от того, где был отказ, мы вернёмся к мастер-слейв схеме.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали:
L>Здравый смысл — вот название этой схемы: при посылке твита сообщение разбрасывается по лентам фоллоуеров. L>Вот и вся логика.
Ну, лично мой здравый смысл подсказывает, что здравых смыслов может быть много.
L>Отсылка к "by design" тут тут вообще ни к месту, т.к. речь идет о реализации твитера, и следовательно "design" зафиксирован тем функционалом, что наблюдается в твитере.
Повторно намекаю, что я не настолько глубоко знаком с твиттером, чтобы точно знать, что там происходит при смене списка фолловеров. Лично меня бы устроил и тот вариант, при котором я получаю доступ к ресентам того, кого фолловлю, в том числе и до момента включения. И наоборот — если я хочу кого-то отправить в игнор, то я не против исчезновения недавних постов.
Тем более, что персистентную копию ленты я, естественно, буду держать локально, синхронизуя по RSS.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ANS>>хм. чтобы работал failover у тебя должна быть синхронная репликация. Это значит после падения реплики должен отключится мастер. Такая штука будет работать только в одном случае — если вероятность падения реплики намного меньше чем мастера. но с чего бы? S>Имхо, вы не вполне верно трактуете сущность фейловера. Весь его смысл — в том, чтобы при одиночном отказе мы продолжили работу. S>Нужно понимать, что одиночный отказ переведёт систему в "тревожное" состояние, при котором, очевидно, её избыточность уменьшится. S>Неважно, кто нагнётся — мастер или слейв. После этого останется 1 мастер. Дальнейшие действия совершенно одинаковы: нужно восстановить слейва и подключить его к мастеру для репликации. Через некоторое время T, не зависящее от того, где был отказ, мы вернёмся к мастер-слейв схеме.
Не совсем понятно как, если учитывать возможность partitioning. Вот в SQL Azure мастер, две реплики и кворум при комите. Это мне понятно. А в твоей схеме без админа живущего в соседнем с серверами ящике не обойтись.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да, из-за него. Только де-факто там внутри чистая реляционка. У нас такое наследование прекрасно реализуется на любой поддерживаемой БД.
имхо явно "университеская" фича. Нафига её тянут не понятно.
ДФ>>Ну, гм, MySQL — очень сомнительный пример для сравнения с РСУБД. __>MySQL и есть РСУБД (причем от мейджора). И noSQL в тоже время с применением плагина HandlerSocket
Хм. Собственно, MySQL — это и есть NoSQL, только с SQL синтаксисом
Так как MySQL, как и прочие NoSQL, ориентирован на быстрое исполнение некоторого числа простых запросов.
__>Просто нет исходного кода "взрослых" РСУБД для анализа. А тут есть. __>И кстати там не так уж все плохо, иначе бы Facebook не использовала 12k MySQL-серверов в качестве основы своей платформы. Плюс есть бесплатная Percona (правда саппорт этой поделки стоит реально конских денег), которая обеспечивает неплохие возможности для вертикального масштабирования.
У Facebook это вполне себе legacy. И, насколько я знаю, используется именно как специфическая NoSQL база.
Просто если сравнивать NoSQL и РСУБД, то MySQL брать не всегда стоит.
ДФ>>А если еще работать с нормальными библиотеками и prepared statment, то парсинга запроса вообще не происходит, никакого. __>Здесь вы о повторном использовании query/sp. Повторюсь — если для запроса уже есть план в кэше планов и контрольная сумма запроса совпадает, ок — проходит этап soft parse of query. Если нет — тогда все по взрослому.
Я не про построение плана, я вообще про любые действия с запросом (типа парсинга его текста и т.п.).
Т.е. накладные расходы на исполнение — вообще нулевые.
ДФ>>Есть еще Postgres. Да и в ограничения DB2 Express C надо еще упереться __>По поводу DB2 C exp — ну а куда там упираться ? С такими требованиями можно реализовать бэкэнд для блога домохозяйки или магазинчика хозтоваров . Я специально с сайта IBM вырезал ограничения для этой "прокаченной" версии : __>"Тех. ограничения: используется максимум 2 ядра и 1 процессор, 2 Гб ОЗУ. Нет поддержки репликации и кластеризации, нет гарантии и возможности приобретения доп. пакетов ПО для расширения возможностей СУБД. Версии выпускаются без пакетов обновлений.". Как вообще тут масштабироваться (это в принципе невозможно)? И это самая "свободная по требованиям" express версия РСУБД от большой тройки. Подставляйте бокалы, кто пьет такое
Тут все хитрее.
Во-первых, указаны ресурсы самой БД, не ограничения на сервер.
Во-вторых, в Рунете сайтов, которым этого не хватит — единицы. В мире — тоже не много. При правильном приготовлении DB2 офигительно крут
В-третьих, за 2K$ можно получить произвольное количество реплик с одного мастера (как через репликацию, так и через HADR).
Собственно, третье позволяет делать очень нагруженные системы.
Ну и если не нужны фенечки самой последней редакции, то можно использовать версию 9.1, где ограничения были 4+4.
Здравствуйте, alex_public, Вы писали:
_>Вот постоянно вижу подобные забавные фразы про mysql и "взрослые бд". ))) Особенно смешит это если оно ещё и в контексте быстродействия, т.к. даже sql спецы признают что mysql очень часто уделывает все "взрослые бд", а претензии к ней идут в основном по функциональности, администрированию и т.п.
Один вопрос — где результаты TPC для mySQL? Мне бы хотелось объективного сравнения, а не признания мифических "sql спецов". Те спецы, которых знаю я, такого не только не признают, но весьма резко отрицают.
_>Хотя вообще то и там не всё так однозначно, иначе не появлялись бы такие http://alex-at.ru/it/mssql темки (особенно забавно там в комментариях).
Отличный пример того, как искалеченный mySQL-ем пришел в мир нормальных РСУБД. Я бы удивился, если бы MS SQL Server у него работал быстро с такими-то знаниями SQL и подходами к решению задач.
_>В общем если уж вы говорите о быстродействие, то лучше не смешите нас подобными заявлениями. Т.к. если я увижу где-то результаты тестирования что какая-то nosql база обошла mysql по скорости, то скорее всего это будет автоматом означать что она тем более обойдёт все "взрослые sql бд".
Нет, не будет.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Хм. Собственно, MySQL — это и есть NoSQL, только с SQL синтаксисом ДФ>Так как MySQL, как и прочие NoSQL, ориентирован на быстрое исполнение некоторого числа простых запросов.
Это спорный вопрос, который может перерасти в очередной холивар, так что я это оставлю.
ДФ>Я не про построение плана, я вообще про любые действия с запросом (типа парсинга его текста и т.п.). ДФ>Т.е. накладные расходы на исполнение — вообще нулевые.
Тут я не понял. Вообще всегда нулевые? Если вы это подразумевали — то, конечно, это неверно.
ДФ>Во-вторых, в Рунете сайтов, которым этого не хватит — единицы. В мире — тоже не много.
Я насчет Рунета полный профан. Что там и как, вообще не представляю . В мире — много, могу навскидку перечислять конторы пару часов подряд
ДФ>В-третьих, за 2K$ можно получить произвольное количество реплик с одного мастера (как через репликацию, так и через HADR).
Вот эта фраза +миллион (как раз и описывает представления мейджора о том как должна дистрибутиться express-система). Ну мы можем вам дать сильно ограниченную поделку без нормальных фич, обновлений и саппорта, но вот если вы захотите большего — +Nk баксов. А хитрый русский все их пытается надуть и что-то получить нахаляву . Только не получится в enterprise этого сделать
Здравствуйте, Sinclair, Вы писали:
L>>Отсылка к "by design" тут тут вообще ни к месту, т.к. речь идет о реализации твитера, и следовательно "design" зафиксирован тем функционалом, что наблюдается в твитере. S>Повторно намекаю, что я не настолько глубоко знаком с твиттером, чтобы точно знать, что там происходит при смене списка фолловеров. Лично меня бы устроил и тот вариант, при котором я получаю доступ к ресентам того, кого фолловлю, в том числе и до момента включения. И наоборот — если я хочу кого-то отправить в игнор, то я не против исчезновения недавних постов.
Ок, проехали. Не знаком, так не знаком. Я исходил из того, что ты знаком, но похоже ошибся.
Здравствуйте, _ABC_, Вы писали:
_AB>Один вопрос — где результаты TPC для mySQL? Мне бы хотелось объективного сравнения, а не признания мифических "sql спецов". Те спецы, которых знаю я, такого не только не признают, но весьма резко отрицают.
... _>>В общем если уж вы говорите о быстродействие, то лучше не смешите нас подобными заявлениями. Т.к. если я увижу где-то результаты тестирования что какая-то nosql база обошла mysql по скорости, то скорее всего это будет автоматом означать что она тем более обойдёт все "взрослые sql бд". _AB>Нет, не будет.
Так в чём проблема? ) Мы тут безрукие что ли? Так давайте и проверим. Возьмём для примера mysql и mssql последних версий. Возьмём какой-нибудь запрос. Что бы не было спекуляций (запросов более подходящих под какую-то базу), возьмём например один из популярных веб-фреймворков (работающих и с mysql и с mssql) и выдерем из кода самый часто используемый запрос. И протестируем на нём скорость работы. Как предложение? ) В принципе это не должно потребовать каких-то особых затрат времени.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>хм. чтобы работал failover у тебя должна быть синхронная репликация. Это значит после падения реплики должен отключится мастер. Такая штука будет работать только в одном случае — если вероятность падения реплики намного меньше чем мастера. но с чего бы? S>>Имхо, вы не вполне верно трактуете сущность фейловера. Весь его смысл — в том, чтобы при одиночном отказе мы продолжили работу. S>>Нужно понимать, что одиночный отказ переведёт систему в "тревожное" состояние, при котором, очевидно, её избыточность уменьшится. S>>Неважно, кто нагнётся — мастер или слейв. После этого останется 1 мастер. Дальнейшие действия совершенно одинаковы: нужно восстановить слейва и подключить его к мастеру для репликации. Через некоторое время T, не зависящее от того, где был отказ, мы вернёмся к мастер-слейв схеме.
ANS>Не совсем понятно как, если учитывать возможность partitioning. Вот в SQL Azure мастер, две реплики и кворум при комите. Это мне понятно. А в твоей схеме без админа живущего в соседнем с серверами ящике не обойтись.
Кстати, тут ниже по треду hadr как панацею рекламируют. Вот пример. Таки без админа спящего на коврике возле серверов не обойтись. Или круглые глаза делать от фразы "ожидаемое поведение". В то время как в RAC кворумы и fencing. Но RAC разнесённый по разным датацентрам я себе не представляю.
ANS>Кстати, тут ниже по треду hadr как панацею рекламируют. Вот пример. Таки без админа спящего на коврике возле серверов не обойтись. Или круглые глаза делать от фразы "ожидаемое поведение". В то время как в RAC кворумы и fencing. Но RAC разнесённый по разным датацентрам я себе не представляю.
Хм. Ну, вообще я HADR как способ распределения нагрузки предлагал. Впрочем, для HA он, разумеется, тоже пригоден — но, увы, решение о переключении "мастера" должен принимать или человек или софт "вне" БД (на что в указанной выше статье и указывается). Как именно — не суть важно, вариантов много, у того же IBM и не только.
А RAC — это, вообще-то, решение не для надежности, а для производительности. И может работать только в одном датацентре (еще-бы, там же sharing all схема и обновление кэшей внутри кластера). И, кстати, его стоит использовать только понимая, зачем. Для HA у Oracle есть DataGuard.
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>>Хм. Собственно, MySQL — это и есть NoSQL, только с SQL синтаксисом ДФ>>Так как MySQL, как и прочие NoSQL, ориентирован на быстрое исполнение некоторого числа простых запросов. __>Это спорный вопрос, который может перерасти в очередной холивар, так что я это оставлю.
Договорились
ДФ>>Я не про построение плана, я вообще про любые действия с запросом (типа парсинга его текста и т.п.). ДФ>>Т.е. накладные расходы на исполнение — вообще нулевые. __>Тут я не понял. Вообще всегда нулевые? Если вы это подразумевали — то, конечно, это неверно.
Если использовать prepared statment, то ни парсинга запроса, ни создания плана — не происходит. Есть драйвера, умеющие использовать один prepared statment в разных коннекциях
Вообще, по рассказу о TimesTen, можно заметно ускорить работу, если вообще отказаться от любой работы с диском (даже по сравнению с ситуацией, где вся информация помещается в кэшах и ничего не пишется на диск), но это уже специфическая ситуация.
ДФ>>Во-вторых, в Рунете сайтов, которым этого не хватит — единицы. В мире — тоже не много. __>Я насчет Рунета полный профан. Что там и как, вообще не представляю . В мире — много, могу навскидку перечислять конторы пару часов подряд
Ну, может быть. Но вообще ExpressC вполне достаточно для, например, сайта с несколькими млн. показов страниц в сутки. А уже если с такого сайта не удается собрать прибыль — то проблема не в SQL.
Да и тот же HADR (вернее, log-shipping+heartbeat) можно сделать "ручками" и на сайте ibm даже есть подробная инструкция по этому поводу. Но тут уж точно проще заплатить 2K$, а то на зарплату уйдет больше.
ДФ>>В-третьих, за 2K$ можно получить произвольное количество реплик с одного мастера (как через репликацию, так и через HADR). __>Вот эта фраза +миллион (как раз и описывает представления мейджора о том как должна дистрибутиться express-система). Ну мы можем вам дать сильно ограниченную поделку без нормальных фич, обновлений и саппорта, но вот если вы захотите большего — +Nk баксов. А хитрый русский все их пытается надуть и что-то получить нахаляву . Только не получится в enterprise этого сделать
Ну, заметим, бесплатную поддержку вообще никто не предлагает, это всегда платная штука. И по фичам в том же ExpressC нет только совсем уж enterprise фенечек. Ну, разве что Q-replication была бы полезна.
А сэкономить на стоимости лицензий — угу, вполне себе получается.
Но правильно ли я понимаю, что у NoSQL есть только одно достоинство — бесплатность? И поэтому мы их сравниваем именно с MySQL (и тут я может даже и соглашусь, что разница между каким-нибудь mongo и mysql несущественна).
Здравствуйте, Дельгядо Филипп, Вы писали:
ANS>>Кстати, тут ниже по треду hadr как панацею рекламируют. Вот пример. Таки без админа спящего на коврике возле серверов не обойтись. Или круглые глаза делать от фразы "ожидаемое поведение". В то время как в RAC кворумы и fencing. Но RAC разнесённый по разным датацентрам я себе не представляю. ДФ>Хм. Ну, вообще я HADR как способ распределения нагрузки предлагал.
Так с большой долей вероятности это сведётся к "eventual consistency" (Т.е. тот же nosql) который у многих вызывает неприятие.
ДФ>Впрочем, для HA он, разумеется, тоже пригоден — но, увы, решение о переключении "мастера" должен принимать или человек или софт "вне" БД (на что в указанной выше статье и указывается). Как именно — не суть важно, вариантов много, у того же IBM и не только.
Мне всё же интересно, а этот самый софт вне БД из двух нод как живую может выбрать? я вижу один сценарий — третья нода для поддержания кворума. я просто не в курсе есть ли еще варианты.
Вот и получается — в большинстве случаев падение сервера рассматривается как полное полное и безвременное крушение оного. А ведь сейчас, когда многие хостятся на чужих площадках, проблемы со связностью между нодами (и кашу в данных) можно получить на раз-два. И тут мы возвращаемся к начальному моему меседжу — всем пофиг и не нужно из себя невинность строить — типа я о пользователях забочусь и пр.
ДФ>использовать только понимая, зачем
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не совсем понятно как, если учитывать возможность partitioning. Вот в SQL Azure мастер, две реплики и кворум при комите. Это мне понятно. А в твоей схеме без админа живущего в соседнем с серверами ящике не обойтись.
Давайте сначала без partitioning. Расскажите мне, что, по-вашему, должно происходить в master-slave моде при падении мастера, и чем это должно отличаться от обработки падения слейва.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Мне всё же интересно, а этот самый софт вне БД из двух нод как живую может выбрать? я вижу один сценарий — третья нода для поддержания кворума. я просто не в курсе есть ли еще варианты.
А почему просто не иметь heartbeat?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ANS>>Не совсем понятно как, если учитывать возможность partitioning. Вот в SQL Azure мастер, две реплики и кворум при комите. Это мне понятно. А в твоей схеме без админа живущего в соседнем с серверами ящике не обойтись. S>Давайте сначала без partitioning. Расскажите мне, что, по-вашему, должно происходить в master-slave моде при падении мастера, и чем это должно отличаться от обработки падения слейва.
Давай сначала определи критерий, по которому видно, что сервер упал.
ANS>>Мне всё же интересно, а этот самый софт вне БД из двух нод как живую может выбрать? я вижу один сценарий — третья нода для поддержания кворума. я просто не в курсе есть ли еще варианты. S>А почему просто не иметь heartbeat?
Что при этом происходит подробно описано по ссылке постом выше.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Что при этом происходит подробно описано по ссылке постом выше.
А, я понял, в чём дело. Я просто под partitioning подразумевал шардинг — в соответствии с терминологией МС.
А вы имеете в виду split brain при georedundancy, да?
Ну так вот: механика с кворумом, на мой ограниченный взгляд, никакого отношения к georedundancy не имеет. Там всё происходит локально.
А в локальном случае нам split brain не грозит: грубо говоря, монитор состояния пользуется тем же "входом", что и клиентский поток данных. То есть promotion slave to master выполняется согласованно. Коммиты внезапно начинают приезжать на нового мастера, и что там думает о себе слейв, у которого, вполне возможно, всего лишь сдохла сетевая карточка, никого не интересует. Его тупо станут репайрить. А уж делается это при помощи админа, спящего в соседней комнате, или автоматического запускальщика клонирующих скриптов — вопрос вторичный.
Кворум в Azure используется не для детектирования сбоя. Сбои детектируются при помощи специального мониторинга, который, собсно, и есть некоторый продвинутый аналог heartbeat.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
S>Ну так вот: механика с кворумом, на мой ограниченный взгляд, никакого отношения к georedundancy не имеет. Там всё происходит локально.
Такое мнение действительно существует. Типа, с CAP проблем нет так мы берём CA, а на P забиваем, т.к. его никогда случится не может.
Мне такой подход кажется сомнительным. Потому, как если случится потеря связности, то ты этого даже не заметишь (в этом собственно вся суть "P" — заметишь ты его или нет). А когда и как вылезут битые данные — х.з.
Тем более, что есть отягчяющие моменты:
сбой это не только физический отказ оборудования, тут может быть ошибка конфигурирования. Плюс все эти колокойшены, клауды и прочие современные реалии только добавляют вероятности этому событию. Плюс желания добавить избыточности (для надёжности, понятное дело ).
Кстати, вспомнилось. В истории-по-ссылке речь шла об отдельном датацентре. Пару лет назад, читал историю, как какие-то кадры локальный кластер строили. Поставили два сервера рядом, взяли DRBD — работает. А через месяц р-раз — ФС в клочки и восстановлению не подлежит. Они списали всё на глюки особо не разбираясь (DRBD убрали). Но я так подозреваю, что глюков не было, а было то самое "задокументированное поведение".
S>Кворум в Azure используется не для детектирования сбоя. Сбои детектируются при помощи специального мониторинга, который, собсно, и есть некоторый продвинутый аналог heartbeat.
Я не говорил, что кворум в ажуре для детектирования сбоев. Кворум там для гарантии целостности.
На самом деле я ж не настаиваю. Хотите мастер-слейв реплику с автоматическим Failover-ом — ради бога. Эти отсылки к ажуру, rac — это чтобы мне на слово не доверяли, а посмотрели как эксперты в этой области делают. Уж они то, что-то знают...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Мне такой подход кажется сомнительным. Потому, как если случится потеря связности, то ты этого даже не заметишь (в этом собственно вся суть "P" — заметишь ты его или нет). А когда и как вылезут битые данные — х.з.
Ещё раз: потеря связности играет роль только в определённой топологии. Случай про HADR по вашей ссылке описывает ровно такую топологию, а SQL Azure — ровно другую. Понимаете? Если у вас все клиенты роутятся через координатора, который и принимает решение о том, кто сейчас мастер, то ситуация с "потерянным слейвом" невозможна. Именно так это работает в Azure. И если бы чуваки с HADR заставили бы "Content Managers" работать через то же подключение, что и всех остальных, то у них бы не было проблемы при потере связности.
ANS>сбой это не только физический отказ оборудования, тут может быть ошибка конфигурирования. Плюс все эти колокойшены, клауды и прочие современные реалии только добавляют вероятности этому событию. Плюс желания добавить избыточности (для надёжности, понятное дело ).
Непонятно, какое отношение это имеет к теме. ANS>Я не говорил, что кворум в ажуре для детектирования сбоев. Кворум там для гарантии целостности.
Значит, мне показалось:
Мне всё же интересно, а этот самый софт вне БД из двух нод как живую может выбрать? я вижу один сценарий — третья нода для поддержания кворума. я просто не в курсе есть ли еще варианты.
ANS>На самом деле я ж не настаиваю. Хотите мастер-слейв реплику с автоматическим Failover-ом — ради бога. Эти отсылки к ажуру, rac — это чтобы мне на слово не доверяли, а посмотрели как эксперты в этой области делают. Уж они то, что-то знают...
Я не настаиваю на мастер-слейве с автофейловером. Я всего лишь проясняю некоторые непонятные мне ваши высказывания — типа того, что в мастер-слейве отказ слейва чем-то хуже отказа мастера.
А вообще, если вернуться в контекст, речь шла о том, что такого предлагают РСУБД в контексте масштабирования и отказоустойчивости.
Ну так вот из коробки там доступен партишнинг таблиц (=шардинг) для масштабирования, и HA в активно-пассивной схеме. Что тут такого передового могут предложить NoSQL, лично мне непонятно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ещё раз: потеря связности играет роль только в определённой топологии.
И эта топология возникает сразу, как только одни данные попадают в два места.
S>Случай про HADR по вашей ссылке описывает ровно такую топологию, а SQL Azure — ровно другую. Понимаете? Если у вас все клиенты роутятся через координатора, который и принимает решение о том, кто сейчас мастер, то ситуация с "потерянным слейвом" невозможна. Именно так это работает в Azure. И если бы чуваки с HADR заставили бы "Content Managers" работать через то же подключение, что и всех остальных, то у них бы не было проблемы при потере связности.
Ок. Будем считать кворум в ажуре просто чудачеством. Но, всё же обращу твоё внимание, что ситуация, когда координатор видит и мастера и слейва, но между слейвом и мастером нет конекта это типичный "split-brain", который требует разрешения. Поскольку с организацей кворума из двух компов будут сложности, то остаётся два варианта: запрещать комиты при пропадании слейва (тогда будет автофейловер при падении мастера, но вероятность сбоя минимум в двое больше), запрещать автофейловер и при проблемах с мастером всё ручками (для сервиса a-la azure не подходит, но внутри компании — самое оно). Именно по-этому я не понимаюкак работает Amazon Multi-AZ.
S>Ну так вот из коробки там доступен партишнинг таблиц (=шардинг) для масштабирования, и HA в активно-пассивной схеме.
Шардинг это уже noSql. SQL — это Oracle RAC, например.
S>Что тут такого передового могут предложить NoSQL, лично мне непонятно.
eventual consistency явно описанный в документации, чтобы до любого дошла суть выбора который он должен сделать — либо строгая консистентность между чтениями и записями либо availability.
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>И эта топология возникает сразу, как только одни данные попадают в два места.
Не, не сразу. Только если эти два места могут принимать данные одновременно. ANS>Ок. Будем считать кворум в ажуре просто чудачеством. Но, всё же обращу твоё внимание, что ситуация, когда координатор видит и мастера и слейва, но между слейвом и мастером нет конекта это типичный "split-brain", который требует разрешения.
Координатор не только "видит" мастера и слейва. Это совсем-совсем примитивный уровень.
Координатор также должен трекать статусы клиентских запросов, приходящих на мастера, а также состояние очереди синхронизации.
Есть некоторая допустимая задержка log shipping, при превышении которой мы считаем slave упавшим. ANS>Поскольку с организацей кворума из двух компов будут сложности, то остаётся два варианта: запрещать комиты при пропадании слейва (тогда будет автофейловер при падении мастера, но вероятность сбоя минимум в двое больше), ANS>запрещать автофейловер и при проблемах с мастером всё ручками (для сервиса a-la azure не подходит, но внутри компании — самое оно).
Я по-прежнему не понимаю, при чём тут кворум. При пропадании слейва мы имеем ситуацию partial failure, которую нужно обработать неким стандарнтным образом. При пропадании мастера мы имеем _строго такую же_ ситуацию partial failure, которую нужно обрабатывать точно так же — потому что после promotion одного из слейвов у вас одного слейва не хватает. Прочитайте внимательно статью про Azure — там подробно описывается, что происходит при падении реплики. И там явно рассказано, почему нет разницы между падением primary реплики и secondary реплики. А кворум там не из чудачества, а для того, чтобы иметь гарантию сохранности данных (durability). Если этого не делать, то необратимая смерть мастера может привести к потере данных, о которых уже получено подтверждение коммита. Эта проблема ортогональна собственно availability. Если упадут две реплики из трёх, база перестанет быть available — чтобы не давать ложных гарантий. На чистой master-slave схеме я могу получить ровно то же самое, поставив в качестве критерия подтверждения commit ожидание log shipping на моего единственного слейва. Просто в этой схеме availability будет ниже — из за того, что нам придётся отказывать в запросах на запись уже при сбое любого из серверов. ANS>eventual consistency явно описанный в документации, чтобы до любого дошла суть выбора который он должен сделать — либо строгая консистентность между чтениями и записями либо availability.
По-моему, eventual consistency в RDBMS — это, например, те самые log shipping, и они там уже очень давно. Зачем ставить новую СУБД, когда можно просто прочитать документацию на старую?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Если использовать prepared statment, то ни парсинга запроса, ни создания плана — не происходит. Есть драйвера, умеющие использовать один prepared statment в разных коннекциях
Но первый раз (в процессе подготовки) запрос все-таки пройдет фазу hard-разбора ? Ну а иначе зачем там SQL ? А потом по нисходящей -> запрос/контекст (в зависимости от БД) -> контрольная сумма -> кэш планов/кэш данных. А если план уже вылетел (напр. по LRU), то промах кэша и снова hard-разбор. ДФ>Вообще, по рассказу о TimesTen, можно заметно ускорить работу, если вообще отказаться от любой работы с диском (даже по сравнению с ситуацией, где вся информация помещается в кэшах и ничего не пишется на диск), но это уже специфическая ситуация.
Вот если бы вы написали Memchached (стандартный/не_тюненый на практике сливает по скорости/удобству и TimesTen и solidDB) — возразить было бы нечего. Но там внутри вариация на тему PL/SQL
ДФ>Но правильно ли я понимаю, что у NoSQL есть только одно достоинство — бесплатность? И поэтому мы их сравниваем именно с MySQL (и тут я может даже и соглашусь, что разница между каким-нибудь mongo и mysql несущественна).
Отчего же. Вот вам пара практических примеров:
VSAM(IMS) более масштабируем на HALDB чем RDBMS. На практике MS SQL имеет ограничение БД в каких-то жалких полпетабайта тогда как IMS можно расширять дальше без явной потери производительности (представляю сейчас праведный огонь гнева в глазах юных микрософт-мальчиков ).
Опять же sequential traversing для parent-child relationships в VSAM будет явно более эффективным (специально же заточен под DL)
Другой пример — в боковой ветке ведется небольшая войнушка про шардинг с применением грязных ругательств типа свинья, идиот, линурас и т.д. . Т.е. + возможности горизонтального масштабирования/кластеризации, которые чужды DL SQL
ох-ох. я написал длинный пост, но при запощивании что-то сбойнуло так что этот будет короче
ANS>>И эта топология возникает сразу, как только одни данные попадают в два места. S>Не, не сразу. Только если эти два места могут принимать данные одновременно.
вообще-то сразу. тебе же данные не только писать нужно, но иногда и читать.
S>Если этого не делать, то необратимая смерть мастера может привести к потере данных, о которых уже получено подтверждение коммита. Эта проблема ортогональна собственно availability.
ситуация, когда мы не видим закомиченных данных — в терминах cap-теоремы это отсутствие консистентности. В cap — теореме консистентность и доступность связаны.
S>Просто в этой схеме availability будет ниже — из за того, что нам придётся отказывать в запросах на запись уже при сбое любого из серверов.
Я как бы об этом и написал. вероятность сбоя одной из двух машин больше, чем одной. Дальше имеем либо гарантии консистентности либо availability. acid — гарантии консистентности.
ANS>>eventual consistency явно описанный в документации, чтобы до любого дошла суть выбора который он должен сделать — либо строгая консистентность между чтениями и записями либо availability. S>По-моему, eventual consistency в RDBMS — это, например, те самые log shipping, и они там уже очень давно. Зачем ставить новую СУБД, когда можно просто прочитать документацию на старую?
"eventual consistency" это гарантия того, что данные в перспективе станут консистентными (т.е. приедут все сделанные комиты). В твоей схеме есть вероятность необратимой потери данных (ты сам написал) — т.е. необратимая утрата.консистентности). Очевидно это уровень слабее, чем "eventual consistency".
В любом случае, я же сразу написал, что ACID это проблема. И шардинг и /асинхронная/ репликация призваны эту проблему обойти. А не-ACID это уже noSql.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>вообще-то сразу. тебе же данные не только писать нужно, но иногда и читать.
Нет. В мастер-слейв схеме мы читаем всегда только из мастера, где всё up-to-date. Не путайте load balancing и high availability.
Поэтому отсутствие связи между мастером и слейвом == выходу слейва из строя. Точка.
ANS>ситуация, когда мы не видим закомиченных данных — в терминах cap-теоремы это отсутствие консистентности. В cap — теореме консистентность и доступность связаны.
Возможно. В терминах ACID это durability. А consistency — это непротиворечивость.
ANS>Я как бы об этом и написал. вероятность сбоя одной из двух машин больше, чем одной. Дальше имеем либо гарантии консистентности либо availability. acid — гарантии консистентности.
Во-первых, непонятно, зачем вы рассматриваете сбой мастера и сбой слейва так, как будто это два разных сценария. Это один и тот же сценарий.
Во-вторых, 100% гарантий "консисистентности" в терминах CAP не даст вообще никакая схема — всегда есть шанс, что нагнутся ровно все ноды кластера. Речь идёт всего лишь о вероятности таких вещей. И наличие двух up-to-date реплик всего лишь уменьшает вероятность необратимой потери на порядок по сравнению с одним сервером. Я по-прежнему не понимаю, почему вы упоминаете кворум в контексте детектирования сбоев, а не в контексте восстановления после сбоев.
ANS>"eventual consistency" это гарантия того, что данные в перспективе станут консистентными (т.е. приедут все сделанные комиты). В твоей схеме есть вероятность необратимой потери данных (ты сам написал) — т.е. необратимая утрата.консистентности). Очевидно это уровень слабее, чем "eventual consistency".
Мне непонятно, откуда в NoSQL внезапно возьмётся такая "гарантия", и почему, если она есть, её нельзя получить в "SQL".
ANS>В любом случае, я же сразу написал, что ACID это проблема. И шардинг и /асинхронная/ репликация призваны эту проблему обойти. А не-ACID это уже noSql.
Ну, можно и так сказать. Хотя на мой взгляд, ACID ортогонально реляционности (SQL-ности). Можно иметь SQL и не иметь ACID — например, тот же MyISAM в MySQL. Его тут уже как "NoSQL" упоминали.
Можно иметь ACID и не иметь SQL. Пример из головы я не приведу, но все требования ACID ровно ничего не говорят про SQL или реляционность — они совершенно абстрактны.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ANS>>Я как бы об этом и написал. вероятность сбоя одной из двух машин больше, чем одной. Дальше имеем либо гарантии консистентности либо availability. acid — гарантии консистентности. S>Во-первых, непонятно, зачем вы рассматриваете сбой мастера и сбой слейва так, как будто это два разных сценария. Это один и тот же сценарий. S>Во-вторых, 100% гарантий "консисистентности" в терминах CAP не даст вообще никакая схема — всегда есть шанс, что нагнутся ровно все ноды кластера. Речь идёт всего лишь о вероятности таких вещей. И наличие двух up-to-date реплик всего лишь уменьшает вероятность необратимой потери на порядок по сравнению с одним сервером. Я по-прежнему не понимаю, почему вы упоминаете кворум в контексте детектирования сбоев, а не в контексте восстановления после сбоев.
Проблема в том, что единственно безопасная стретегия — это убить весь кластер при сбое одного узла (получаем буквы C и P). Но это мало кому интересно (кроме, быть может, банковских приложений).
Потому нужны схемы работы в режиме с отказывающими узлами. Тут и начинаются workaround'ы с кворумом и прочим.
Здравствуйте, Cyberax, Вы писали: C>Проблема в том, что единственно безопасная стретегия — это убить весь кластер при сбое одного узла (получаем буквы C и P). Но это мало кому интересно (кроме, быть может, банковских приложений).
Непонятно, в чём эаключается эта "безопасность". Предполагается, что выключенный кластер сбоям не подвержен?
Я к тому, что 100% гарантии того, что после обратного включения поднимется хотя бы одна машина, в общем случае нет.
То есть если мы растим кластер от 1 машины до N, мы всего лишь в N раз уменьшаем вероятность безвозвратной потери данных.
В итоге мы не то чтобы получали "буквы" C и P. Мы "улучшаем" букву C. При этом A у нас, что характерно, быстро падает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Проблема в том, что единственно безопасная стретегия — это убить весь кластер при сбое одного узла (получаем буквы C и P). Но это мало кому интересно (кроме, быть может, банковских приложений). S>Непонятно, в чём эаключается эта "безопасность". Предполагается, что выключенный кластер сбоям не подвержен?
Ага. Если кластер не работает, то возможности получить несогласованные данные нет.
S>Я к тому, что 100% гарантии того, что после обратного включения поднимется хотя бы одна машина, в общем случае нет.
Конечно. Но это проблемы уже availability.
S>То есть если мы растим кластер от 1 машины до N, мы всего лишь в N раз уменьшаем вероятность безвозвратной потери данных. S>В итоге мы не то чтобы получали "буквы" C и P. Мы "улучшаем" букву C. При этом A у нас, что характерно, быстро падает.
Ага, о том и речь.
Здравствуйте, Cyberax, Вы писали:
S>>Я к тому, что 100% гарантии того, что после обратного включения поднимется хотя бы одна машина, в общем случае нет. C>Конечно. Но это проблемы уже availability.
Брр. Ничего не понимаю. Какое определение мы имеем у термина Consistency?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Брр. Ничего не понимаю. Какое определение мы имеем у термина Consistency?
total order между чтениями и записями. Если сделал insert и select1, а вставленных данных не видно, а следующий select2 — и видно, то это отсутсвие Consistency. Потму, что данный эффект равнозначен переупорядочиванию между чтениями и записями. Т.е. select1 эффективно выполнился до insert. Т.к. поддержка total order дорогая, то придумали разные схемы ослабления консистентности с которыми всё еще можно удобно работать. A-la read-your-writes etc.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>total order между чтениями и записями. Если сделал insert и select1, а вставленных данных не видно, а следующий select2 — и видно, то это отсутсвие Consistency. Потму, что данный эффект равнозначен переупорядочиванию между чтениями и записями. Т.е. select1 эффективно выполнился до insert.
Не очень понятно, кто сделал. Если речь об одном клиенте, который выполняет последовательность транзакций, то да — с его точки зрения полезно иметь упорядоченность транзакций. Хотя необходимости в этом нет.
Если у нас есть много клиентов, то не очень понятна суть эффекта, с учётом размывания понятий порядка и одновременности в распределённой среде.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>вообще-то сразу. тебе же данные не только писать нужно, но иногда и читать. S>Нет. В мастер-слейв схеме мы читаем всегда только из мастера, где всё up-to-date. Не путайте load balancing и high availability.
если ты "всегда" читаешь только из мастера, то слейв как бы вообще не нужен. Слейв ты же ставишь для того, что бы когда-то начать из него читать. Это "когда-то" может наступить в любой момент.
S>Поэтому отсутствие связи между мастером и слейвом == выходу слейва из строя. Точка.
Так это смотря для кого. Тот кто выбирает, кого опрашивать видит живыми и мастер и слейв. Вот и получается, если ты заинтересован при сбое мастера видеть все комиты, то нужно при потере связи мастера со слейвом отвергать все комиты на мастере. Мне показалось, что ты это понимаешь. О чем тогда разговор?
ANS>>ситуация, когда мы не видим закомиченных данных — в терминах cap-теоремы это отсутствие консистентности. В cap — теореме консистентность и доступность связаны. S>Возможно. В терминах ACID это durability. А consistency — это непротиворечивость.
(не совсем, потому что термин "eventual durability" звучит странно).
ANS>>Я как бы об этом и написал. вероятность сбоя одной из двух машин больше, чем одной. Дальше имеем либо гарантии консистентности либо availability. acid — гарантии консистентности. S>Во-первых, непонятно, зачем вы рассматриваете сбой мастера и сбой слейва так, как будто это два разных сценария. Это один и тот же сценарий.
так я об этом и пишу. слейв ставят для защиты от сбоя мастера. зачем, если сбой слейва == сбою мастера. Т.е. вероятность проблемы вырастает более чем в два раза, а не уменьшается. (это верно при схеме с автофейловером, если предполагается переключение "вручную" неким экспертом, то расклад, понятно, меняется. Ибо, "дюрабилити" нужно такому малому проценту пользователей, что можно сказать "никому").
S>Во-вторых, 100% гарантий "консисистентности" в терминах CAP не даст вообще никакая схема — всегда есть шанс, что нагнутся ровно все ноды кластера. Речь идёт всего лишь о вероятности таких вещей. И наличие двух up-to-date реплик всего лишь уменьшает вероятность необратимой потери на порядок по сравнению с одним сервером. Я по-прежнему не понимаю, почему вы упоминаете кворум в контексте детектирования сбоев, а не в контексте восстановления после сбоев.
Ну, CAP вещь вполне практичная. Она рассматривает ситуации, когда жив хоть кто-то. Например, термин "availability" это не абсолютная возможность получить ответ, а возможность получить ответ от "живой" ноды. И, пока есть хоть кто-то живой, CAP теорема даёт тебе на выбор три варианта а) потерять A — не давать ответов с "живой" машины (fencing, quorum commit); б) потерять C — давать ответы с "живой" машины, приложение понимает, что его запросы на чтение и запись могут быть переупорядочены; в) потерять P — я так понимаю, это игнорить все факты с непредсказуемыми последствиями, просто работать будь-то сеть всегда есть и всегда работает (это тот случай, что ты сказал, что между датацентрами проблема связности есть, а внутри датацентра — нет ).
ANS>>"eventual consistency" это гарантия того, что данные в перспективе станут консистентными (т.е. приедут все сделанные комиты). В твоей схеме есть вероятность необратимой потери данных (ты сам написал) — т.е. необратимая утрата.консистентности). Очевидно это уровень слабее, чем "eventual consistency". S>Мне непонятно, откуда в NoSQL внезапно возьмётся такая "гарантия", и почему, если она есть, её нельзя получить в "SQL".
Потому, что "eventual consistency" это не ACID. Нет ACID — нет этого самого "SQL". Собственно чуть ниже ты сам написал "можно и так сказать".
ANS>>В любом случае, я же сразу написал, что ACID это проблема. И шардинг и /асинхронная/ репликация призваны эту проблему обойти. А не-ACID это уже noSql. S>Ну, можно и так сказать. Хотя на мой взгляд, ACID ортогонально реляционности (SQL-ности). Можно иметь SQL и не иметь ACID — например, тот же MyISAM в MySQL. Его тут уже как "NoSQL" упоминали. S>Можно иметь ACID и не иметь SQL. Пример из головы я не приведу, но все требования ACID ровно ничего не говорят про SQL или реляционность — они совершенно абстрактны.
С этим я согласен. То же Gemstone пример ООБД с ACID. Я потому /для себя/ и определил, что "SQL" это и ACID и язык SQL.
Здравствуйте, Sinclair, Вы писали:
ANS>>total order между чтениями и записями. Если сделал insert и select1, а вставленных данных не видно, а следующий select2 — и видно, то это отсутсвие Consistency. Потму, что данный эффект равнозначен переупорядочиванию между чтениями и записями. Т.е. select1 эффективно выполнился до insert. S>Не очень понятно, кто сделал. Если речь об одном клиенте, который выполняет последовательность транзакций, то да — с его точки зрения полезно иметь упорядоченность транзакций. Хотя необходимости в этом нет.
Формально нет, на практике писать при отсутствии даже частичного порядка сложно. И сделать хотя бы частичный порядок "на коленке" тоже сложно. Проще взять систему с такой гарантией.
S>Если у нас есть много клиентов, то не очень понятна суть эффекта, с учётом размывания понятий порядка и одновременности в распределённой среде.
в acid СУБД порядок задаётся инстансом БД. И конфликтующие транзакции просто не закомитятся.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>если ты "всегда" читаешь только из мастера, то слейв как бы вообще не нужен. Слейв ты же ставишь для того, что бы когда-то начать из него читать. Это "когда-то" может наступить в любой момент. S>>Поэтому отсутствие связи между мастером и слейвом == выходу слейва из строя. Точка.
ANS>Так это смотря для кого. Тот кто выбирает, кого опрашивать видит живыми и мастер и слейв.
Зачем он так смотрит?
ANS> Вот и получается, если ты заинтересован при сбое мастера видеть все комиты, то нужно при потере связи мастера со слейвом отвергать все комиты на мастере. Мне показалось, что ты это понимаешь.
Если заинтересован видеть все коммиты — да, нужно так и делать. Н ANS>О чем тогда разговор?
О том, что вы зачем-то считаете сбои мастера и сбои слейва чем-то различным. Независимо от того, считаем ли мы допустимыми потери недавних коммитов или нет.
Почему вы избегаете ответов на простые вопросы?
Давайте ещё раз:
1. Вот у нас вышел из строя мастер. Что должно происходить?
2. Вот у нас вышел из строя слейв. (или нет связи со слейвом)
ANS>Угу. Я уже писал, что в первом приближении D в ACID == C в CAP
(не совсем, потому что термин "eventual durability" звучит странно).
Ну вот поэтому и странно, что консистентностью называют какую-то странную, непонятную хрень, которая неясно, для чего нужна.
ANS>>>Я как бы об этом и написал. вероятность сбоя одной из двух машин больше, чем одной. Дальше имеем либо гарантии консистентности либо availability. acid — гарантии консистентности. S>>Во-первых, непонятно, зачем вы рассматриваете сбой мастера и сбой слейва так, как будто это два разных сценария. Это один и тот же сценарий. ANS>так я об этом и пишу. слейв ставят для защиты от сбоя мастера. зачем, если сбой слейва == сбою мастера. Т.е. вероятность проблемы вырастает более чем в два раза, а не уменьшается.
Это зависит от того, что считать проблемой.
ANS>Ну, CAP вещь вполне практичная. Она рассматривает ситуации, когда жив хоть кто-то. Например, термин "availability" это не абсолютная возможность получить ответ, а возможность получить ответ от "живой" ноды.
Получается какая-то ерунда. Вот смотрите. Допустим, существует некоторое минимальное N, такое, что при N нод в кластере вас устраивает уровень избыточности с точки зрения consistency и availability. Очевидно, N не может быть равно 0. Единице оно тоже не может быть равно, т.к. при выходе из строя единственной ноды мы теряем нужные нам гарантии.
Двойке N тоже не может быть равно, т.к. при выходе из строя любой ноды мы возвращаемся в ситуацию с одной нодой, а она, как мы уже доказали, нас не устраивает.
И вообще, если N — минимально, то (N-1) нод нас точно не устроят. Значит, N нас тоже не устраивают, т.к. при одиночном отказе мы возвращаемся к N-1.
Вот так доказывается, что с вашим подходом к требованиям надёжности никакой кворум, и никакие приседания не спасут в принципе. Зачем тогда всё? Значит, надо отказываться от такого бескомпромиссного подхода, и вводить честные вероятностные метрики.
И вот с ними всё хорошо. Потому, что помимо отказов нужно вводить в рассмотрение также и восстановление повреждений. В SQL Azure так и сделано — они знают, что погибшая реплика восстанавливается за 2 часа. Поэтому у них есть возможность рассчитать вероятности того, что за это время помрут сразу две оставшиеся реплики.
ANS>Потому, что "eventual consistency" это не ACID. Нет ACID — нет этого самого "SQL". Собственно чуть ниже ты сам написал "можно и так сказать".
На мой взгляд, то, что называется eventual consistency, никак не противоречит ACID. То, что называется consistency в CAP, явно не относится ни к C ни к D в ACID. В ACID вообще вопросов упорядочивания за пределами транзакций не ставится. Требованию сериализуемости удовлетворяет любой порядок транзакций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Sinclair, Вы писали:
ANS>>>total order между чтениями и записями. Если сделал insert и select1, а вставленных данных не видно, а следующий select2 — и видно, то это отсутсвие Consistency. Потму, что данный эффект равнозначен переупорядочиванию между чтениями и записями. Т.е. select1 эффективно выполнился до insert. S>>Не очень понятно, кто сделал. Если речь об одном клиенте, который выполняет последовательность транзакций, то да — с его точки зрения полезно иметь упорядоченность транзакций. Хотя необходимости в этом нет.
ANS>Формально нет, на практике писать при отсутствии даже частичного порядка сложно. И сделать хотя бы частичный порядок "на коленке" тоже сложно. Проще взять систему с такой гарантией.
Что вы называете частичным порядком?
ANS>в acid СУБД порядок задаётся инстансом БД. И конфликтующие транзакции просто не закомитятся.
Непонятно, что вы называете "конфликтующими транзакциями".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот поэтому и странно, что консистентностью называют какую-то странную, непонятную хрень, которая неясно, для чего нужна. S>На мой взгляд, то, что называется eventual consistency, никак не противоречит ACID. То, что называется consistency в CAP, явно не относится ни к C ни к D в ACID. В ACID вообще вопросов упорядочивания за пределами транзакций не ставится.
. Ты хочешь сказать, что после комита в RDBMS изменения не обязаны быть видимы новым транзакциям?
То durability это возможность быстро стартовать после сбоев, не смотря на потерю дынных, то в acid БД закомиченные изменения не обязаны быть видимы никому. Так мы договоримся до того, что РСУБД на любой запрос может "Ок" говорить и больше ничего не делать.
Здравствуйте, Sinclair, Вы писали:
S>Что вы называете частичным порядком?
Например в пределах сессии.
ANS>>в acid СУБД порядок задаётся инстансом БД. И конфликтующие транзакции просто не закомитятся. S>Непонятно, что вы называете "конфликтующими транзакциями".
ORA-08177 "can't serialize access for this transaction"
"could not serialize access due to read/write dependencies among transactions"
Error: 3960 Snapshot isolation transaction aborted due to update conflict
И дедлоки.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Например в пределах сессии.
ANS>>>в acid СУБД порядок задаётся инстансом БД. И конфликтующие транзакции просто не закомитятся. S>>Непонятно, что вы называете "конфликтующими транзакциями".
ANS>ORA-08177 "can't serialize access for this transaction" ANS>"could not serialize access due to read/write dependencies among transactions" ANS>Error: 3960 Snapshot isolation transaction aborted due to update conflict ANS>И дедлоки.
Это артефакты шедулеров и конкретной реализации языка команд SQL. В ACID Isolation означает бескомпромиссную сериализуемость. Вы показываете случаи, когда транзакции неизолированы. Это не ACID.
Далее, в ACID нет ничего про конкретный порядок транзакций. Поэтому "инстанс БД" ничего вам не задаёт. То, что в конкретных СУБД есть некоторые гарантии полного порядка между различными транзакциями — это, можно сказать, случайность. Она очень редко является существенно важной.
Ну, то есть к примеру, ничего нет страшного в том, что я наблюдаю курс акций с задержкой — если только я не начинаю принимать решения на основе этого курса, для которых важен тайминг. С точки зрения ACID, я обязан всё выполнять в одной транзакции:
// язык воображаемый
BEGIN TRAN
c = ReadСurrentPrice(AMX) // 1.
if (c < @threshold)
PlacePurchaseOrder(AMX, @amount); //2. неявно корректирует курс
COMMIT TRAN
Если система, с которой я работаю, удовлетворяет свойству ACID, то у меня есть определённые гарантии. Например, у меня есть гарантия, что курс не изменится внезапно между 1 и 2. Но у меня нет никаких гарантий, что если я начал свою транзакцию в 8:00 вечера, то моя сделка пройдёт вперёд Васиной, которую он начал в 8:01. Про это ACID говорит только то, что результат всегда будет эквивалентен какому-то последовательному выполнению.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Ты хочешь сказать, что после комита в RDBMS изменения не обязаны быть видимы новым транзакциям?
Конечно. Покажите мне то место в ACID, которое этого требует. В распределённой среде вопросы "до" и "после" вообще являются интересными.
ANS>То durability это возможность быстро стартовать после сбоев, не смотря на потерю дынных, то в acid БД закомиченные изменения не обязаны быть видимы никому. Так мы договоримся до того, что РСУБД на любой запрос может "Ок" говорить и больше ничего не делать.
C точки зрения ACID, СУБД обязана для любого набора входных транзакций предоставлять некоторое упорядочивание. При этом формально никто ей не запрещает размещать все читающие транзакции "в начало времён". А вот если у вас есть смешанная транзакция, вроде set a= a+1, select a, то произвола гораздо меньше. РСУБД обязана отдать не просто "Ok", а конкретное число. Какое оно будет — в распределённой среде сказать невозможно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Ты хочешь сказать, что после комита в RDBMS изменения не обязаны быть видимы новым транзакциям? S>Конечно. Покажите мне то место в ACID, которое этого требует. В распределённой среде вопросы "до" и "после" вообще являются интересными.
не знаю. Однако всегда и везде во всех текстах подразумевается, что acid == "strong consistency". Возможно она как memory model в ia32 процах — явно её не документировали, но она всегда была.
ANS>>То durability это возможность быстро стартовать после сбоев, не смотря на потерю дынных, то в acid БД закомиченные изменения не обязаны быть видимы никому. Так мы договоримся до того, что РСУБД на любой запрос может "Ок" говорить и больше ничего не делать. S>C точки зрения ACID, СУБД обязана для любого набора входных транзакций предоставлять некоторое упорядочивание. При этом формально никто ей не запрещает размещать все читающие транзакции "в начало времён". А вот если у вас есть смешанная транзакция, вроде set a= a+1, select a, то произвола гораздо меньше. РСУБД обязана отдать не просто "Ok", а конкретное число. Какое оно будет — в распределённой среде сказать невозможно.
Ок.
у нас есть "append only" таблица.
1. комитим INSERT. — ок.
2. делаем select добавленной записи. — её нет.
3. делаем select добавленной записи. — она нет.
И ты хочеш сказать, что твои программы всегда готовы к такой ситуации? Верится с трудом.
И еще, какие acid субд такое допускают?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>не знаю. Однако всегда и везде во всех текстах подразумевается, что acid == "strong consistency". Возможно она как memory model в ia32 процах — явно её не документировали, но она всегда была.
Как вы определяете, что подразумевается в текстах, а что нет? Я, конечно, Бернстайна читал давно и невнимательно. Но в целом вопросы consistency в ACID рассматриваются под совершенно другим углом, чем в этом новомодном CAP и noSQL. Там нет никаких strong или weak консистентностей, есть требование удовлетворять определённым предикатам. В частности, неконсистентность в ACID — это когда вы в одной транзакции наблюдаете приход на счёт без расхода с другого счёта. А про скорость распространения изменений, сделанных в разных транзакциях, в ACID просто ничего нет.
ANS>Ок. ANS>у нас есть "append only" таблица. ANS>1. комитим INSERT. — ок. ANS>2. делаем select добавленной записи. — её нет. ANS>3. делаем select добавленной записи. — она нет. ANS>И ты хочеш сказать, что твои программы всегда готовы к такой ситуации? Верится с трудом. ANS>И еще, какие acid субд такое допускают?
Ваш вопрос не имеет смысла без уточнения, кто именно делает эти шаги 1, 2, 3. Понимаете, в известном выражении "мужик сказал — мужик сделал" нет никаких упоминаний о том, что это один и тот же мужик.
У нас запросто может быть так, что
1. Маша делает beign; insert; commit.
2. Петя делает begin; select; сommit — результатов не видит
3. Маша делает begin; select; commit — результаты есть
Это ровно ничему из ACID не противоречит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Как вы определяете, что подразумевается в текстах, а что нет? Я, конечно, Бернстайна читал давно и невнимательно. Но в целом вопросы consistency в ACID рассматриваются под совершенно другим углом, чем в этом новомодном CAP и noSQL. Там нет никаких strong или weak консистентностей, есть требование удовлетворять определённым предикатам. В частности, неконсистентность в ACID — это когда вы в одной транзакции наблюдаете приход на счёт без расхода с другого счёта. А про скорость распространения изменений, сделанных в разных транзакциях, в ACID просто ничего нет.
Я имел ввиду, что все запросы сделаны из одного процесса.
Короче, я не преподаватель — давать дефиниции не умею, а "на пальцах" — пальцев не видно. Глянь на эту статью:
N = the number of nodes that store replicas of the data
W = the number of replicas that need to acknowledge the receipt of the update before the update completes
R = the number of replicas that are contacted when a data object is accessed through a read operation
If W+R > N, then the write set and the read set always overlap and one can guarantee strong consistency.
In the primary-backup RDBMS scenario, which implements synchronous replication, N=2, W=2, and R=1. No matter from which replica the client reads, it will always get a consistent answer.
In asynchronous replication with reading from the backup enabled, N=2, W=1, and R=1. In this case R+W=N, and consistency cannot be guaranteed.
S>Ваш вопрос не имеет смысла без уточнения, кто именно делает эти шаги 1, 2, 3. Понимаете, в известном выражении "мужик сказал — мужик сделал" нет никаких упоминаний о том, что это один и тот же мужик. S>У нас запросто может быть так, что S>1. Маша делает beign; insert; commit. S>2. Петя делает begin; select; сommit — результатов не видит S>3. Маша делает begin; select; commit — результаты есть S>Это ровно ничему из ACID не противоречит.
Здравствуйте, Enomay, Вы писали:
S>>Ваш вопрос не имеет смысла без уточнения, кто именно делает эти шаги 1, 2, 3. Понимаете, в известном выражении "мужик сказал — мужик сделал" нет никаких упоминаний о том, что это один и тот же мужик. S>>У нас запросто может быть так, что S>>1. Маша делает beign; insert; commit. S>>2. Петя делает begin; select; сommit — результатов не видит S>>3. Маша делает begin; select; commit — результаты есть S>>Это ровно ничему из ACID не противоречит.
E>Пропустите select Пети и Маше станет забавно )
1. Маша делает beign; insert; commit.
2. Маша делает begin; select; commit — результаты есть
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Enomay, Вы писали:
S>>>Ваш вопрос не имеет смысла без уточнения, кто именно делает эти шаги 1, 2, 3. Понимаете, в известном выражении "мужик сказал — мужик сделал" нет никаких упоминаний о том, что это один и тот же мужик. S>>>У нас запросто может быть так, что S>>>1. Маша делает beign; insert; commit. S>>>2. Петя делает begin; select; сommit — результатов не видит S>>>3. Маша делает begin; select; commit — результаты есть S>>>Это ровно ничему из ACID не противоречит.
E>>Пропустите select Пети и Маше станет забавно )
_AB>1. Маша делает beign; insert; commit. _AB>2. Маша делает begin; select; commit — результаты есть
_AB>Пропустил. Почему Маше стало забавно?
а почему в изначальном условии для Пети ничего нет?
Здравствуйте, Enomay, Вы писали:
E>У меня нет вариантов. Вы написали, что для Пети данных нет. Меня это смутило и я решил узнать у вас, почему.
Вы попросили следующее: E>Пропустите select Пети и Маше станет забавно )
Я пропустил его. Я не написал, что для Пети данных нет. Они может быть есть, может их нет (я же не знаю, что вернул ему тот пропущенный селект). Я просто пропустил этот запрос.
Теперь мой вопрос. Почему должно было стать забавно Маше?
_AB>Вы попросили следующее: E>>Пропустите select Пети и Маше станет забавно )
_AB>Я пропустил его. Я не написал, что для Пети данных нет. Они может быть есть, может их нет (я же не знаю, что вернул ему тот пропущенный селект). Я просто пропустил этот запрос.
S>>1. Маша делает beign; insert; commit. S>>2. Петя делает begin; select; сommit — результатов не видит S>>3. Маша делает begin; select; commit — результаты есть
Если для Пети данных нет, то, при отсутствии select'а с его стороны, вместо него выполнится select со стороны Маши, которая не увидит только что добавленные данные.
_AB>Теперь мой вопрос. Почему должно было стать забавно Маше?
Здравствуйте, Enomay, Вы писали:
E>Если для Пети данных нет, то, при отсутствии select'а с его стороны, вместо него выполнится select со стороны Маши, которая не увидит только что добавленные данные.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Enomay, Вы писали:
E>>Если для Пети данных нет, то, при отсутствии select'а с его стороны, вместо него выполнится select со стороны Маши, которая не увидит только что добавленные данные.
_AB>С чего вдруг-то?
С чего вдруг в вашем примере Петя может не увидеть данных?
Здравствуйте, Enomay, Вы писали:
E>С чего вдруг в вашем примере Петя может не увидеть данных?
Да мало ли с чего? Например, ему выдана версия данных, в которой еще нет данных, измененных Машей.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Sinclair, Вы писали:
ANS>http://en.wikipedia.org/wiki/Strong_consistency
Для ACID вполне достаточно sequential consistency. А strict consistency в распределенной среде все равно получить невозможно. ANS>>>Ок.
ANS>Я имел ввиду, что все запросы сделаны из одного процесса. ANS>Короче, я не преподаватель — давать дефиниции не умею, а "на пальцах" — пальцев не видно. ANS>Глянь на эту статью: ANS>[q]
Ну тут рядом в топике рассматривают ситуации, где потеря части записей нестрашна. А если страшна — то делаем синхронную репликацию и вперед.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
E>>С чего вдруг в вашем примере Петя может не увидеть данных? _AB>Да мало ли с чего? Например, ему выдана версия данных, в которой еще нет данных, измененных Машей.
Ну то есть гипотетически маша так же может не получить своих только что добавленных данных?
_AB>Что из ACID нарушается при этом? Почему?
Разве я где-то говорил что это нарушает ACID? Причем тут вообще ACID?
_>Ужасы какие. Это же переделка всего. В то время как в случае nosql мы вообще ничего не трогаем проекте. Только запускаем новые сервера, правим конфиг и всё.
Ложь. Нет в NoSQL, которые позволяют сделать это настолько легко. Практически у всех или закат солнца вручную (типа банальной репликации копированием) или потеря потеря каких-либо важных свойств (типа половины букв в ACID).
Если и так, то твоя схема с асинхронной репликой не даёт sequental гарантий.
S>А strict consistency в распределенной среде все равно получить невозможно.
ACID база как бы выступает теми самыми внешними часами относительно которых всё измеряется. Но тут я с тобой спорить не буду — вопрос strict или sequental гарантии в ACID — как для меня, то мутный.
S>Ну тут рядом в топике рассматривают ситуации, где потеря части записей нестрашна.
Воот. Я же сразу говорил, что durability нафиг никому не нужно. А вы ACID, ACID...
S>А если страшна — то делаем синхронную репликацию и вперед.
Это то, почему я обращаю внимание именно на падение реплики. При синхронной репликации, при падении реплики вся система должна остановить работу. Т.е. у нас проблема — при падении мастера всё останавливается, а нужно чтобы нет. Вводим синхронную реплику. Теперь у нас всё останавливается при падении реплики. Ну и зачем огород городить?
Базы в разных датацентрах синхронны, но при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.
/.../
Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления коннективити, данные в базах автоматически синхронизируются.
Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь траффик автоматически переключается в работающий датацентр.
Здравствуйте, Mamut, Вы писали:
M>Ложь. Нет в NoSQL, которые позволяют сделать это настолько легко. Практически у всех или закат солнца вручную (типа банальной репликации копированием) или потеря потеря каких-либо важных свойств (типа половины букв в ACID).
Я же уже кидал здесь эту ссылку http://gliffer.ru/articles/nosql--sharding-mongodb-na-paltsah/ — один из простейших примеров работы с nosql базой. Там в начале всякие общие слова, а вот ближе к концу реальные настройки показаны. Как мы видим всё сводится к нескольким административным командам. А теперь мне было бы очень интересно посмотреть на последовательность команд администратора sql базы, реализующую аналогичные возможности...
M>>Ложь. Нет в NoSQL, которые позволяют сделать это настолько легко. Практически у всех или закат солнца вручную (типа банальной репликации копированием) или потеря потеря каких-либо важных свойств (типа половины букв в ACID).
_>Я же уже кидал здесь эту ссылку http://gliffer.ru/articles/nosql--sharding-mongodb-na-paltsah/ — один из простейших примеров работы с nosql базой. Там в начале всякие общие слова, а вот ближе к концу реальные настройки показаны. Как мы видим всё сводится к нескольким административным командам.
_>А теперь мне было бы очень интересно посмотреть на последовательность команд администратора sql базы, реализующую аналогичные возможности...
mongos — это процесс, который крутится на одном или нескольких серверах, и выполняет функции доступа к нашему кластеру.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Если и так, то твоя схема с асинхронной репликой не даёт sequental гарантий.
Ещё как даёт.
ANS>ACID база как бы выступает теми самыми внешними часами относительно которых всё измеряется.
Только в том случае, если мы перед ней ставим такую задачу. S>>А если страшна — то делаем синхронную репликацию и вперед. ANS>Это то, почему я обращаю внимание именно на падение реплики. При синхронной репликации, при падении реплики вся система должна остановить работу.
С чего вы это взяли? Я же вам уже написал, что при таком подходе надо останавливать систему при падении вообще любой реплики, скольно бы их ни было.
ANS>Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления коннективити, данные в базах автоматически синхронизируются. ANS>Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь траффик автоматически переключается в работающий датацентр. ANS>И как оно работает?
Плохо работает, чего тут думать. Уменьшили латентность, получили потерю консистентности. На всякий случай: если отказаться от идеи пестовать split brain, то можно сохранить консистентность, ценой некоторого роста латентности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
_>>Я же уже кидал здесь эту ссылку http://gliffer.ru/articles/nosql--sharding-mongodb-na-paltsah/ — один из простейших примеров работы с nosql базой. Там в начале всякие общие слова, а вот ближе к концу реальные настройки показаны. Как мы видим всё сводится к нескольким административным командам. _>>А теперь мне было бы очень интересно посмотреть на последовательность команд администратора sql базы, реализующую аналогичные возможности...
M>Навскидку: http://www.pgpool.net/mediawiki/index.php/Main_Page M>А дальше — тупой шардинг по ключу. Вау, это ДОСТИЖЕНИЕ!!!!одинодинодин. Ну, и ACID мы не имеем.
Вот можно поподробнее про последнее? ) Т.е. я продемонстрировал набор команд реализующий нужное нам в nosql базе. А теперь можно увидеть набор команд реализующий "тупой шардинг по ключу" в sql случае? )
M>>Навскидку: http://www.pgpool.net/mediawiki/index.php/Main_Page M>>А дальше — тупой шардинг по ключу. Вау, это ДОСТИЖЕНИЕ!!!!одинодинодин. Ну, и ACID мы не имеем.
_>Вот можно поподробнее про последнее? ) Т.е. я продемонстрировал набор команд реализующий нужное нам в nosql базе. А теперь можно увидеть набор команд реализующий "тупой шардинг по ключу" в sql случае? )
В презентации выше все есть. Хотя да, я уже в курсе такого способа ведения спора. Если набор команд не будет в точности повторять такой же для монго, оппоненту будет засчитано поражение. И фигня, что
Практически у всех или закат солнца вручную (типа банальной репликации копированием) или потеря потеря каких-либо важных свойств (типа половины букв в ACID).
Здравствуйте, Mamut, Вы писали:
M>В презентации выше все есть. Хотя да, я уже в курсе такого способа ведения спора. Если набор команд не будет в точности повторять такой же для монго, оппоненту будет засчитано поражение.
Дело не в том что бы команды были такие же. И даже не в том что бы их было не намного больше по количеству, хотя это тоже не совсем ерунда. Главное в принципе: требуется ли нам для масштабирования проекта с одного сервера на несколько снова привлекать программистов, что бы они меняли код проекта, или же достаточно нескольких команд администратора...
M>>В презентации выше все есть. Хотя да, я уже в курсе такого способа ведения спора. Если набор команд не будет в точности повторять такой же для монго, оппоненту будет засчитано поражение.
_>Дело не в том что бы команды были такие же. И даже не в том что бы их было не намного больше по количеству, хотя это тоже не совсем ерунда. Главное в принципе: требуется ли нам для масштабирования проекта с одного сервера на несколько снова привлекать программистов, что бы они меняли код проекта, или же достаточно нескольких команд администратора...
Для масштабирования проекта желательно иметь не администратора. Потому что тому же монгодб для репликации на 10 шардов понадобится копировать 90% информации. Нахрена он такой нужен?
Но мне нравится, как ты продолжаешь акцентировать свое внимание на количестве команд, а не на том, что «решения» для масштабируемеости в NoSQL, как правило, от хреновых до очень хреновых. Но главное, чтобы мало команд было!!!!одинодинодинпыщьпыщьпыщь
Здравствуйте, Mamut, Вы писали:
M>Но мне нравится, как ты продолжаешь акцентировать свое внимание на количестве команд, а не на том, что «решения» для масштабируемеости в NoSQL, как правило, от хреновых до очень хреновых. Но главное, чтобы мало команд было!!!!одинодинодинпыщьпыщьпыщь
Зачем врать то? Тем более что каждый может посмотреть чуть выше мой текст и убедиться в этом. Я вроде бы абсолютно чётко акцентировал внимание на том, требуется ли для масштабирования переделка проекта программистами или не требуется. На мой взгляд это принципиальный момент.
M>>Но мне нравится, как ты продолжаешь акцентировать свое внимание на количестве команд, а не на том, что «решения» для масштабируемеости в NoSQL, как правило, от хреновых до очень хреновых. Но главное, чтобы мало команд было!!!!одинодинодинпыщьпыщьпыщь
_>Зачем врать то? Тем более что каждый может посмотреть чуть выше мой текст и убедиться в этом. Я вроде бы абсолютно чётко акцентировал внимание на том, требуется ли для масштабирования переделка проекта программистами или не требуется. На мой взгляд это принципиальный момент.
Именно. При том, что, повторю, ты игнорируешь гораздо более принципиальный момент о том, что масштабируются они исключительно хреново.
Здравствуйте, Mamut, Вы писали:
M> Для масштабирования проекта желательно иметь не администратора. Потому что тому же монгодб для репликации на 10 шардов понадобится копировать 90% информации. Нахрена он такой нужен?
Тут имеется ввиду немного другое. Был кластер из одного шарда, стало 10. В итоге 90% информации из 1-го шарда "размажется" по оставшимся 9 и на исходном шарде останется 1/10 информации, которая была до добавления шардов. Это поведение вполне логично, но и его можно контролировать при желании.
Здравствуйте, gandjustas, Вы писали:
G>1) Для надежности master-master репликация не нужна, она может понадобится для LB и\или локальности. G>Если программист неспособен осознать то что написано выше, то его нельзя подпускать к работе с данными и hiload.
Чтобы меня можно было подпустить, прошу разъяснить первый пункт. Из трёх содержащихся в нём утверждений понимаю только одно — про LB. Про master-master и что такое локальность можно поподробнее? Спасибо.
M>> Для масштабирования проекта желательно иметь не администратора. Потому что тому же монгодб для репликации на 10 шардов понадобится копировать 90% информации. Нахрена он такой нужен?
AB>Тут имеется ввиду немного другое. Был кластер из одного шарда, стало 10. В итоге 90% информации из 1-го шарда "размажется" по оставшимся 9 и на исходном шарде останется 1/10 информации, которая была до добавления шардов. Это поведение вполне логично, но и его можно контролировать при желании.
Цитирую:
When sharding an existing collection, please be aware that this process will take some time... it will take quite a while for the data to migrate/balance on a large collection. For example, on a system with ten shards, 90% of the data for the collection will need to transfer to elsewhere to attain balance. Note that only large collections rebalance. If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
Не говоря о том, что они считают большой коллекцией что-либо больше 400 MB. Держите меня семеро.
Здравствуйте, Mamut, Вы писали:
M>Именно. При том, что, повторю, ты игнорируешь гораздо более принципиальный момент о том, что масштабируются они исключительно хреново.
M>>Именно. При том, что, повторю, ты игнорируешь гораздо более принципиальный момент о том, что масштабируются они исключительно хреново.
_>Эээ, хреново в сравнение с чем?
С решениями, которые обкатаны и работают уже много лет. NoSQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!! (за очень редким исключением вроде Riak'а)
Здравствуйте, Mamut, Вы писали:
M>>>Именно. При том, что, повторю, ты игнорируешь гораздо более принципиальный момент о том, что масштабируются они исключительно хреново. _>>Эээ, хреново в сравнение с чем? M>С решениями, которые обкатаны и работают уже много лет. NoSQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!! (за очень редким исключением вроде Riak'а)
IBM IMS масштабируется хорошо, по крайней мере ФРС не жалуется (я где-то выше уже приводил ссылку, что с точки зрения масштабирования это "почти" чемпион). В этой же области у нее есть младшие братья (типа System2k) которые стоят меньших денег (хотя использовать их довольно рискованно при любом раскладе). Другой пример — GAE Datastorage; вполне себе хорошо масштабируется (у нее там другие проблемы, которые не позволяют сделать норм. продукт, но со scalability все ок) внутри Google.
Кстати вы не поверите (недавно прочел в databasejournal) — в эпоху расцвета isam-а и начала становления sql в местных научных журналах империалистических стран загнивающего запада можно было часто прочитать такую фразу — "SQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!!". Ничего не напоминает ?
M>When sharding an existing collection, please be aware that this process will take some time... it will take quite a while for the data to migrate/balance on a large collection. For example, on a system with ten shards, 90% of the data for the collection will need to transfer to elsewhere to attain balance. Note that only large collections rebalance. If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
M>Не говоря о том, что они считают большой коллекцией что-либо больше 400 MB. Держите меня семеро.
Не, ну уж если мы решили распилить данные — то их таки придётся двигать, независимо от технологии. Чудес ведь не бывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M> AB>Тут имеется ввиду немного другое. Был кластер из одного шарда, стало 10. В итоге 90% информации из 1-го шарда "размажется" по оставшимся 9 и на исходном шарде останется 1/10 информации, которая была до добавления шардов. Это поведение вполне логично, но и его можно контролировать при желании.
M> Цитирую: M> 90% of the data for the collection will need to transfer to elsewhere to attain balance.
Да, это как раз то, о чем я писал — мы пилим 100% коллекцию на 10 кусков-шардов. Естественно, что нам придется перегнать 90% данных между серверами (по 10% на каждый и 10% останется на месте).
M> Цитирую: M> If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
Тоже разумная рекомендация, т.к. монга очень скорострельна на стандартных кейсах и шардинг маленьких коллекций может не иметь практического смысла.
Здравствуйте, Mamut, Вы писали:
_>>Эээ, хреново в сравнение с чем? M>С решениями, которые обкатаны и работают уже много лет. NoSQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!! (за очень редким исключением вроде Riak'а)
Ну так можно конкретно по именам? ) Какие сейчас решения применяются для масштабирования базы данных на сеть из серверов?
Здравствуйте, Sinclair, Вы писали:
ANS>>Если и так, то твоя схема с асинхронной репликой не даёт sequental гарантий. S>Ещё как даёт.
Это ты так думаешь от того, что ты смотришь на сбой /мастера/ как на апокалипис, конец времени после которого уже не важно что там в БД за данные. Но при автофайловере такой сбой превращается в норму. И вот некая система видела данные, работала с ними, а потом трах-бах и не видит. Ну и какая это консистентность?
ANS>>ACID база как бы выступает теми самыми внешними часами относительно которых всё измеряется. S>Только в том случае, если мы перед ней ставим такую задачу.
Не важно ставим или нет. ACID система работает как единое целое, что повышает требования к коммуникационным каналам между нодами.
S>>>А если страшна — то делаем синхронную репликацию и вперед. ANS>>Это то, почему я обращаю внимание именно на падение реплики. При синхронной репликации, при падении реплики вся система должна остановить работу. S>С чего вы это взяли? Я же вам уже написал, что при таком подходе надо останавливать систему при падении вообще любой реплики, скольно бы их ни было.
Достаточно кворума. Т.е. получается при одном сервере его падение — катастрофа. При двух — падение слейва катастрофа. При трёх серверах для даунтайма нужно одновременное падение двух.
ANS>>Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления коннективити, данные в базах автоматически синхронизируются. ANS>>Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь траффик автоматически переключается в работающий датацентр. ANS>>И как оно работает? S>Плохо работает, чего тут думать. Уменьшили латентность, получили потерю консистентности. На всякий случай: если отказаться от идеи пестовать split brain, то можно сохранить консистентность, ценой некоторого роста латентности.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Это ты так думаешь от того, что ты смотришь на сбой /мастера/ как на апокалипис, конец времени после которого уже не важно что там в БД за данные. Но при автофайловере такой сбой превращается в норму. И вот некая система видела данные, работала с ними, а потом трах-бах и не видит. Ну и какая это консистентность?
И тем не менее, последовательность наблюдаемых изменений будет в такой системе одинаковой.
ANS>Не важно ставим или нет. ACID система работает как единое целое, что повышает требования к коммуникационным каналам между нодами.
Нет. Это вы себе придумали зачем-то. ACID построен на понятиях сериализуемости. Требования задавать общесистемные часы у ACID нету.
S>>С чего вы это взяли? Я же вам уже написал, что при таком подходе надо останавливать систему при падении вообще любой реплики, скольно бы их ни было.
ANS>Достаточно кворума. Т.е. получается при одном сервере его падение — катастрофа. При двух — падение слейва катастрофа. При трёх серверах для даунтайма нужно одновременное падение двух.
Вы опять сами себе противоречите. При двух серверах падение любого получается катастрофа — ведь останется только один сервер! Значит, система из двух серверов неотказоустойчива. Тогда и три сервера вам ничем не помогут — ведь при падении одного из них останется только два, а неотказоустойчивость этой комбинации уже доказана.
Я вам это уже в третий раз рассказываю, а вы игнорируете. Почему? Не совпадает с вашим шаблоном?
S>>Плохо работает, чего тут думать. Уменьшили латентность, получили потерю консистентности. На всякий случай: если отказаться от идеи пестовать split brain, то можно сохранить консистентность, ценой некоторого роста латентности. ANS>Чего?
Что конкретно вам непонятно? Вам непонятно, почему уменьшается латентность? Потому что европейским клиентам быстрее сбегать в европейский датацентр, чем в северную америку. Непонятно, почему возникает неконсистентность? Потому что мы разрешаем европейским клиентам работать со своей репликой, не извещая об этом американскую реплику. Непонятно, как сохранить консистентность? Элементарно — запрещать модификации при потере связи между датацентрами, или заставлять европейских клиентов ходить в американский датацентр. Непонятно, почему ухудшится латентность? Потому, что операции записи теперь будут стоить немножко больше.
Если вам кажется, что запрет модификаций — это отказ от availability, то это тоже иллюзия. Потому, что бескомпромиссная availabilty вообще невозможна в распределённой среде. Ведь канал между серверами гораздо надёжнее канала между сервером и клиентом; а в случае падения последнего никакая избыточность на серверной стороне вас не спасёт.
Вот поэтому-то CAP-теорема и является фуфлом: рассматриваемая ею модель слишком сферическая и слишком в вакууме.
Для того, чтобы осмысленно рассуждать о нарушениях консистентности, доступности и связности, надо вводить более продвинутые модели. И сравнивать не абсолютные величины типа "есть"/"нету", а вероятности тех или иных событий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Anton Batenev, Вы писали:
M>> Цитирую: M>> If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
AB>Тоже разумная рекомендация, т.к. монга очень скорострельна на стандартных кейсах и шардинг маленьких коллекций может не иметь практического смысла.
Как бы это сказать... В общем, для современных РСУБД 400МБ это не 'small', а 'tiny'. Рекомендация разносить данные на разные сервера, если их размер меньше десятков ГБ вызывает недоумение, особенно в разрезе песнопений об экономии на железе.
Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?
Здравствуйте, _ABC_, Вы писали:
_AB>Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?
Например, в случае, если вы выбрали стратегию in-memory database, но оперируете данными более 2Гб (напр. low-latency trading). В таком случае разнесение с точки зрения уменьшения стоимости входа в эту стратегию (и возможно стоимости владения, но не факт), вам эффективнее использовать горизонтальное масштабирование (то бишь шардинг по русски ), чем вертикальное. Мог бы привести еще парочку примеров
Здравствуйте, a_g_99, Вы писали:
__>Например, в случае, если вы выбрали стратегию in-memory database, но оперируете данными более 2Гб (напр. low-latency trading). В таком случае разнесение с точки зрения уменьшения стоимости входа в эту стратегию (и возможно стоимости владения, но не факт), вам эффективнее использовать горизонтальное масштабирование (то бишь шардинг по русски ), чем вертикальное. Мог бы привести еще парочку примеров
А пример такого уменьшения стоимости можно с актуальными ценами?
И точно мы в случае с low-latency trading оперируем данными более 2ГБ? Просто это не моя предметная область.
Здравствуйте, _ABC_, Вы писали:
_AB>А пример такого уменьшения стоимости можно с актуальными ценами?
Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен). Напр. я беру стандартный HP ProLiant DL385G7 с 16Гб памятью по умолчанию (+хорошие возможности наращивания), сам сервер, если очень скромно его конфигурить (по нищебродски) обойдется в 30k + базовый софт (напр. Windows) в 2.5k. Примерный уровень цен можете посмотреть в первоисточнике. Напр. парни из TPC насчитали там на 400k в комплексе — все оборудование + весь софт. В реальной жизни, в среднем, это вам обойдется где-то в 70k.
Либо вы берете 3 машинки типа IBM ExpSell x3400 (1.5-2k), каждая с 4 Гб памяти + 4k за noname-обкладку на первом этапе. + софта на 5-7k.
Итого — 70k > 15k. Если i-mdb собственная профит очевиден. Если от мейджора надо сильно-сильно думать и считать.
_AB>И точно мы в случае с low-latency trading оперируем данными более 2ГБ? Просто это не моя предметная область.
Напр. для современных взрослых систем арбитража это базовый порог входа. Меньше конечно можно, но уже как-то несолидно , только в Бангладеше или России банчить
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, _ABC_, Вы писали:
_AB>>А пример такого уменьшения стоимости можно с актуальными ценами? __>Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен).
Вопросы:
Что такое "отмасштабироваться по взрослому"? В цифрах и фактах, пожалуйста.
_AB>>И точно мы в случае с low-latency trading оперируем данными более 2ГБ? Просто это не моя предметная область. __>Напр. для современных взрослых систем арбитража это базовый порог входа. Меньше конечно можно, но уже как-то несолидно , только в Бангладеше или России банчить
И чем определяется этот "базовый порог входа"? Вообще, применительно к объему памяти "базовый порог входа" что призван означать?
Здравствуйте, a_g_99, Вы писали: __>Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен). Напр. я беру стандартный HP ProLiant DL385G7 с 16Гб памятью по умолчанию (+хорошие возможности наращивания), сам сервер, если очень скромно его конфигурить (по нищебродски) обойдется в 30k + базовый софт (напр. Windows) в 2.5k.
Мне кажется, что вы передёргиваете. "Вертиально отмасштабироваться", при стратегии In-memory database, означает иметь приличный CPU и RAM. Могучая дисковая подсистема, в которую уходят все деньги на TPC-C, вам не нужна.
16 ядер и 24GB памяти вам обойдутся в пределах 10K. На них всё будет просто летать, т.к. никакой "нонейм обкладки" между клиентами и сервером нету. А ваши четыре-пять говномашинок, которые совместно будут тянуть распиленную на куски базу того же размера, выйдут вам (по вашим же расчётам) в пару раз дороже. Увы, чудес не бывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, a_g_99, Вы писали:
__>Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен). Напр. я беру стандартный HP ProLiant DL385G7 с 16Гб памятью по умолчанию (+хорошие возможности наращивания), сам сервер, если очень скромно его конфигурить (по нищебродски) обойдется в 30k + базовый софт (напр. Windows) в 2.5k. Примерный уровень цен можете посмотреть в первоисточнике.
Поигрался с конфигуратором. С двумя топовыми процами (хотя Opteron'ы не мой выбор, но на этот сервер идут только они), 64 гигами оперативы, 4 SAS 15к 146GB и 8 SAS SSD MLC 200GB и всеми необходимыми довязками получил результат в 58 тысяч у.е.
Если совсем "по нищебродски" набивать этот сервер, то он мне обойдется не в 30к, а тысяч в 7.
__>Напр. парни из TPC насчитали там на 400k в комплексе — все оборудование + весь софт.
Парни чисто дисков накупили на 236 тысяч и стоимость владения посчитали за три года в 50 тысяч. Если стратегия выбрана in-memory db, то смысла в покупке стольки дисков немного.
Здравствуйте, _ABC_, Вы писали:
ABC> Как бы это сказать... В общем, для современных РСУБД 400МБ это не 'small', а 'tiny'.
Слушай, ну это уже придирки к словам. Tiny она или small — это исключительно зависит от наблюдателя, работающего с конкретной коллекцией, имеющегося оборудования и здравого смысла.
ABC> Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?
Зависит от конфигурации сервера(ов) и требуемой скорострельности. Поскольку mongo легко масштабируется, можно стартовать на достаточно слабых серверах (в т.ч. VPS) и легко расширяться или мигрировать на более мощное оборудование вместе с ростом нагрузки и/или финансов.
Здравствуйте, _ABC_, Вы писали:
Я попытаюсь ответить так чтобы не впадать в троллинги не цитировать кэптана Очевидность
_AB>Вопросы: _AB>Что такое "отмасштабироваться по взрослому"? В цифрах и фактах, пожалуйста.
Что такое масштабирование здесь. Я по крайней мере с тем что написано в wiki согласен.
По взрослому — это когда вам следует нарастить возможности системы выше, чем "средние" возможности подобных систем. А какие уж характеристики/цифры у средних систем, решать вам самому (количество/"вес" данных в Гб, transactions per sec, users ?). Напр. есть замечательный блогосайт highscalability там хорошо все изложено (а писать долго и лениво )
_AB>И чем определяется этот "базовый порог входа"?
Постановкой задачи или задачей в развитии. Напр. в применении к арбитражу вам ставят следующую задачу:
1) есть две разнесенные системы (два сайта, биржи, или игровые сервера — думаю не суть важно).
2) в каждой из этих систем есть идентичный по сути объект, который обладает разными характеристиками (напр ценная бумага с разной стоимостью, или книжка/диск на сайте)
3) Нужно получить данные объекта из двух систем, сравнить их и в зависимости от результата сравнения пары выполнить действие
Вы смотрите физику и видите что каждый объект весит напр. 50kb. Значит чтобы сформировать пару нужно мин. 100k (в реальности больше, т.к. там будут доп. очереди, буферы и т.д.). Итого 10 пар = 1Мб, 10k пар 1 Гб, 100k пар — 10Гб. Издержки обработки должны быть минимальны (у нас же low latency в теории ). Таким образом вы можете прикинуть мин. требования к памяти — напр. для моего примера в 20k пар потребуется минимум 4Гб памяти с учетом расходов на базовый софт. Пример конечно крайне простой и абстрактный, но думаю суть понятна. >Вообще, применительно к объему памяти "базовый порог входа" что призван означать?
Минимальный объем памяти для эффективного функционирования системы. Вы это хотели услышать ?
Здравствуйте, Anton Batenev, Вы писали:
AB>Слушай, ну это уже придирки к словам. Tiny она или small — это исключительно зависит от наблюдателя, работающего с конкретной коллекцией, имеющегося оборудования и здравого смысла.
Нет, это не придирки к словам. Это та граница, после которой по словам разработчиков имеет смысл горизонтально масштабироваться. Значит это именно та граница, которую в монго считают серьезной.
AB>Зависит от конфигурации сервера(ов) и требуемой скорострельности. Поскольку mongo легко масштабируется, можно стартовать на достаточно слабых серверах (в т.ч. VPS) и легко расширяться или мигрировать на более мощное оборудование вместе с ростом нагрузки и/или финансов.
РСУБД тоже позволяют легко мигрировать на более мощное оборудование. Единственное что, начальные требования у них побольше, чем у noSQL, но при росте они урв
Получается, что ниша монгодб — сверхмаленькие проекты, которые скорее всего не выстрелят? Чтобы целесообразно было запустить сотню мелких проектов на как можно более слабом железе с рассчетом на выстрел одного-двух, которые потом и масштабировать?
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, _ABC_, Вы писали: __>Я попытаюсь ответить так чтобы не впадать в троллинги не цитировать кэптана Очевидность
_AB>>Вопросы: _AB>>Что такое "отмасштабироваться по взрослому"? В цифрах и фактах, пожалуйста. __>Что такое масштабирование здесь. Я по крайней мере с тем что написано в wiki согласен. __>По взрослому — это когда вам следует нарастить возможности системы выше, чем "средние" возможности подобных систем. А какие уж характеристики/цифры у средних систем, решать вам самому (количество/"вес" данных в Гб, transactions per sec, users ?). Напр. есть замечательный блогосайт highscalability там хорошо все изложено (а писать долго и лениво )
Ну и почему у Вас тогда получается, что один сервер за 70 тысяч справляется хуже, чем три по пять?
_AB>>И чем определяется этот "базовый порог входа"? __>Постановкой задачи или задачей в развитии. Напр. в применении к арбитражу вам ставят следующую задачу: __>1) есть две разнесенные системы (два сайта, биржи, или игровые сервера — думаю не суть важно). __>2) в каждой из этих систем есть идентичный по сути объект, который обладает разными характеристиками (напр ценная бумага с разной стоимостью, или книжка/диск на сайте) __>3) Нужно получить данные объекта из двух систем, сравнить их и в зависимости от результата сравнения пары выполнить действие __>Вы смотрите физику и видите что каждый объект весит напр. 50kb. Значит чтобы сформировать пару нужно мин. 100k (в реальности больше, т.к. там будут доп. очереди, буферы и т.д.). Итого 10 пар = 1Мб, 10k пар 1 Гб, 100k пар — 10Гб. Издержки обработки должны быть минимальны (у нас же low latency в теории ). Таким образом вы можете прикинуть мин. требования к памяти — напр. для моего примера в 20k пар потребуется минимум 4Гб памяти с учетом расходов на базовый софт. Пример конечно крайне простой и абстрактный, но думаю суть понятна.
Суть понятна. Почему DL385 G7 с 2-мя процами и 32 ГБ оперативной пямяти за примерно 10 тысяч в данном случае справится хуже, чем 3 сервера с одним процом и 4 ГБ оперативы по пять тысяч каждый?
Здравствуйте, _ABC_, Вы писали:
_AB>Нет, это не придирки к словам. Это та граница, после которой по словам разработчиков имеет смысл горизонтально масштабироваться. Значит это именно та граница, которую в монго считают серьезной.
Зачем передёргивать то? ) Там вполне чётко сказано, что это минимальный порог, опускаясь ниже которого, скорее всего ничего хорошего не получишь. А вы интерпретировали это как "серьёзную границу, с которой стоит начинать" — типичное враньё. Думаю у них там где-нибудь на сайте можно поискать рекомендации на счёт того, с какого размера лучше начинать и думаю это будут совсем другие цифры.
Здравствуйте, _ABC_, Вы писали:
ABC> Нет, это не придирки к словам. Это та граница, после которой по словам разработчиков имеет смысл горизонтально масштабироваться. Значит это именно та граница, которую в монго считают серьезной.
Не соглашусь. Давай возьмем исходную фразу: "If the collection is small (less than say, 400MB) we recommend not bothering to shard it.". Если понимать буквально, то они не рекомендуют шардить коллекции менее, скажем, 400 метров, однако обратного совершенно не следует. При этом 400 метров, судя по "less than say" — условность, которая связана с тем, что linux (как основная платформа для mongo) может полноценно работать на достаточно широком диапазоне железа.
Т.о., tiny, small, medium, large — это все условности.
ABC> РСУБД тоже позволяют легко мигрировать на более мощное оборудование.
Там помимо миграции еще было масштабирование. Мигировать я могу любую базу простым копированием файловой системы в худшем случае. Но дело даже не в этом — у них тупо разные области решаемых задач.
ABC> Получается, что ниша монгодб — сверхмаленькие проекты, которые скорее всего не выстрелят? Чтобы целесообразно было запустить сотню мелких проектов на как можно более слабом железе с рассчетом на выстрел одного-двух, которые потом и масштабировать?
Странный вывод из моих слов. То, что mongo хорошо живет на слабом железе совершенно не означает, что это ее ниша. С ростом проекта любое железо рано или поздно становится слабым — сегодня у тебя 1К пользователей, завтра 100К, через год лям и выше — у меня просто не болит голова на тему роста mongo (но занята ростом нагрузки на postgres).
Здравствуйте, _ABC_, Вы писали:
_AB>Ну и почему у Вас тогда получается, что один сервер за 70 тысяч справляется хуже, чем три по пять?
Где же я такое писал? Я написал цитирую — "...разнесение с точки зрения уменьшения стоимости входа в эту стратегию (и возможно стоимости владения, но не факт), вам эффективнее использовать горизонтальное масштабирование (то бишь шардинг по русски ), чем вертикальное". Сервер за 70, 50 или даже 20k очевидно будет более эффективен (возможно гораздо более эффективен по производительности и стоимости владения, опять же в зависимости от условий), чем 3 по 1.5k. Но при всем этом вход самопальной горизонтальной системы будет ниже по деньгам, а возможности ее масштабирования никак не ниже чем у системы вертикального масштабирования.
_AB>Суть понятна. Почему DL385 G7 с 2-мя процами и 32 ГБ оперативной пямяти за примерно 10 тысяч в данном случае справится хуже, чем 3 сервера с одним процом и 4 ГБ оперативы по пять тысяч каждый?
Вы ушли куда-то в сторону от темы. Если ставить так вопрос — то конечно DL385 G7 выйдет победителем. Я бы конечно мог сейчас с пеной у рта доказывать, что вот если силами моджахедов собрать в пакистане на коленке сервера с одним CPU, то это было бы еще круче, чем кастрированный DL385 G7, у которого какой-нибудь плюгавый мужик из HP при конфигурировании выдернул все что мог, но это пустая трата времени.
В общем, мой посыл был следующим — в некоторых случаях (не всегда) горизонтальное масштабирование будет эффективным чем вертикальное. Напр. с точки зрения снижения стоимости входа + возможно ROI. И это касается соврешенно разных систем — маленьких, средних, больших. Ваша фраза >"Рекомендация разносить данные на разные сервера, если их размер меньше десятков ГБ вызывает недоумение, особенно в разрезе песнопений об экономии на железе. >Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?"
по сути неверна, так как не учитывает все возможное многообразие задач. Приведу более простой пример из моей практики. В 2k3 разрабатывал одну web-систему — в бэкэнде был sql server 2k (лучшее решение на тот момент по произв./стоимость). Хотя данных было не очень много (около 5~7 Гб), OLTP-нагрузка для того времени была высокой, так что пришлось специально "хинтить", настраивать query governer и пинировать некоторые таблицы (ms-евангилисты, если вы это читаете срочно начинайте гуглить или бинговать эти страшные слова). Сервер хорошо держал нагрузку на OLTP, но поиск по БД (длинные запросы) убивал перфоманс напрочь; эскалация, массовый рост tempdb и скачки в RAM. Нашли быстрое решение — вынесли поисковые таблицы на отдельный mssql2k сервер, все стало super. Это ответ на ваш вопрос "зачем" ?
M>> Цитирую: M>> If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
AB>Тоже разумная рекомендация, т.к. монга очень скорострельна на стандартных кейсах и шардинг маленьких коллекций может не иметь практического смысла.
Ну да, ну да. Получается, что то, что больше 400 MB — это уже большие коллекции?
Здравствуйте, Mamut, Вы писали:
M> Ну да, ну да. Получается, что то, что больше 400 MB — это уже большие коллекции?
Нет, где-то ниже объяснял, что до 400 — маленькие и обратного не следует. Все эти термины и числа условны исходя из банального здравого смысла.
Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте), но они совершенно не в том шкафу, где пытаются их искать "крестоносцы"
Здравствуйте, Anton Batenev, Вы писали:
AB>Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте),
Какие, если не секрет?
AB>но они совершенно не в том шкафу, где пытаются их искать "крестоносцы"
То есть то, что писал gandjustas про mongo's global lock vs SQL's fine-grained locks, неверно?
Здравствуйте, dimgel, Вы писали:
d> AB>Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте), d> Какие, если не секрет?
На вскидку из того с чем сталкивался плотно:
* Низкое качество тестирования кода в результате чего релизы (хоть и частые) могут падать (или течь) в самом элементарном кейсе. Особенно это касается вспомогательных подсистем типа провайдера для PHP или nginx (это из тех, с которыми я имел дело — возможно, что и в других). Поправимо (ибо open source), но неприятно.
* Нагрузка на дисковую подсистему при перебалансироке и возникающие при этом эффекты с определением отказа ноды. Опять же не фатально, но нужен некоторый опыт эксплуатации, чтобы предвидеть и уметь справиться (на 3-м шарде такой опыт уже появляется).
* Каждый шард — это два сервера (а не один, как кажется в самом начале пути). Можно один, но неудобно в работе и рискованно.
* IPv6 (для меня достаточно актуально) — возможно, что сейчас ситуация поправилась, но в свое время тупо не работало.
Это из эксплуатации. С программированием как-то было все сильно проще за исключением разве что попытки эмуляции транзакционности (но тут сам боженька велел обломиться и согласиться на soft-вариант, который устроил).
d> AB>но они совершенно не в том шкафу, где пытаются их искать "крестоносцы" d> То есть то, что писал gandjustas про mongo's global lock vs SQL's fine-grained locks, неверно?
Возможно я пропустил, т.к. пришел поздно и ветка была уже большая.
Если речь идет об этом, то да, есть такое. На моей практике время блокировки на запись не превышает 0.5-0.6% от времени остальных запросов, по этому на моих кейсах эта особенность меня не беспокоит (но возможно, что у кого-то другой опыт).
M>> Ну да, ну да. Получается, что то, что больше 400 MB — это уже большие коллекции?
AB>Нет, где-то ниже объяснял, что до 400 — маленькие и обратного не следует. Все эти термины и числа условны исходя из банального здравого смысла.
Банальный зравый смысл показывает, что у того же Foursquare шарды на 64 гига, и что с нынешними объемами RAM'а "маленькие" коллекции начинаются, наверное, в районе гигабайта, а то и больше.
AB>Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте), но они совершенно не в том шкафу, где пытаются их искать "крестоносцы"
Я, вообще-то, говорю про другое Я говорю про то, что
_>Ужасы какие. Это же переделка всего. В то время как в случае nosql мы вообще ничего не трогаем проекте. Только запускаем новые сервера, правим конфиг и всё.
Ложь. Нет в NoSQL, которые позволяют сделать это настолько легко. Практически у всех или закат солнца вручную (типа банальной репликации копированием) или потеря потеря каких-либо важных свойств (типа половины букв в ACID).
Здравствуйте, Sinclair, Вы писали:
ANS>>Это ты так думаешь от того, что ты смотришь на сбой /мастера/ как на апокалипис, конец времени после которого уже не важно что там в БД за данные. Но при автофайловере такой сбой превращается в норму. И вот некая система видела данные, работала с ними, а потом трах-бах и не видит. Ну и какая это консистентность? S>И тем не менее, последовательность наблюдаемых изменений будет в такой системе одинаковой.
Не будет. В момент "фэйловера" она нарушиться, если есть недореплицированные комиты. Эти комиты уезжают в будущее. Единственный способ сохранить "Sequential Consistency" это будет запретить и чтение и запись. Практичность подобного решения сомнительна.
ANS>>Не важно ставим или нет. ACID система работает как единое целое, что повышает требования к коммуникационным каналам между нодами. S>Нет. Это вы себе придумали зачем-то. ACID построен на понятиях сериализуемости. Требования задавать общесистемные часы у ACID нету.
Маша сделала комит, а потом говорит Пете человеческим голосом: "Смотри что я тут закомитила". Петя смотрит и в зависимости от того, что он может увидеть и получаются разные гарантии консистентности. Ты утверждаешь, что в ACID системе Петя (после получения приглашения от Маши) может не увидеть Машин комит, а через 5 минут позже — увидеть. Я уверен, что в ACID системе Петя обязан увидеть комит Маши сразу, если она его пригласила.
S>>>С чего вы это взяли? Я же вам уже написал, что при таком подходе надо останавливать систему при падении вообще любой реплики, скольно бы их ни было. ANS>>Достаточно кворума. Т.е. получается при одном сервере его падение — катастрофа. При двух — падение слейва катастрофа. При трёх серверах для даунтайма нужно одновременное падение двух. S>Вы опять сами себе противоречите. При двух серверах падение любого получается катастрофа — ведь останется только один сервер! Значит, система из двух серверов неотказоустойчива. Тогда и три сервера вам ничем не помогут — ведь при падении одного из них останется только два, а неотказоустойчивость этой комбинации уже доказана. S>Я вам это уже в третий раз рассказываю, а вы игнорируете. Почему? Не совпадает с вашим шаблоном?
Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер".
S>>>Плохо работает, чего тут думать. Уменьшили латентность, получили потерю консистентности. На всякий случай: если отказаться от идеи пестовать split brain, то можно сохранить консистентность, ценой некоторого роста латентности. ANS>>Чего? S>Что конкретно вам непонятно? Вам непонятно, почему уменьшается латентность? Потому что европейским клиентам быстрее сбегать в европейский датацентр, чем в северную америку. Непонятно, почему возникает неконсистентность? Потому что мы разрешаем европейским клиентам работать со своей репликой, не извещая об этом американскую реплику. Непонятно, как сохранить консистентность? Элементарно — запрещать модификации при потере связи между датацентрами, или заставлять европейских клиентов ходить в американский датацентр. Непонятно, почему ухудшится латентность? Потому, что операции записи теперь будут стоить немножко больше. S>Если вам кажется, что запрет модификаций — это отказ от availability, то это тоже иллюзия. Потому, что бескомпромиссная availabilty вообще невозможна в распределённой среде. Ведь канал между серверами гораздо надёжнее канала между сервером и клиентом; а в случае падения последнего никакая избыточность на серверной стороне вас не спасёт. S>Вот поэтому-то CAP-теорема и является фуфлом: рассматриваемая ею модель слишком сферическая и слишком в вакууме. S>Для того, чтобы осмысленно рассуждать о нарушениях консистентности, доступности и связности, надо вводить более продвинутые модели. И сравнивать не абсолютные величины типа "есть"/"нету", а вероятности тех или иных событий.
Очень много рассуждений. Я только понял, что с твоей точки зрения это нормально, что пользователь работал работал, а потом после очередного рефреша у него пропали данные за 10 часов работы. И ACID это не противоречит.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не будет. В момент "фэйловера" она нарушиться, если есть недореплицированные комиты. Эти комиты уезжают в будущее.
Ок, в такой схеме (если происходит фейловер для клиента, который работал с мастером на запись) — да, нарушается последовательность, это правда. С точки зрения теории кристалла, это частичное нарушение durability. Не очень важно то, что произошёл фейловер. С тем же успехом могло произойти восстановление из бэкапа — и с тем же результатом, "изменения за последние xxx секунд потеряны".
Нужно понимать, что схем, которые бы гарантировали 100% durability, в природе не существует. Кворум, на который вы так сильно уповаете, принципиально не лучше. Для него просто вероятность нарушения durability ниже. Это место вам понятно или нужно подробнее пояснять?
ANS>Маша сделала комит, а потом говорит Пете человеческим голосом: "Смотри что я тут закомитила". Петя смотрит и в зависимости от того, что он может увидеть и получаются разные гарантии консистентности. Ты утверждаешь, что в ACID системе Петя (после получения приглашения от Маши) может не увидеть Машин комит, а через 5 минут позже — увидеть. Я уверен, что в ACID системе Петя обязан увидеть комит Маши сразу, если она его пригласила.
На чём основана ваша уверенность? И зачем она вам нужна?
ANS>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер".
Поясните. Я не вижу ошибки.
ANS>Очень много рассуждений. Я только понял, что с твоей точки зрения это нормально, что пользователь работал работал, а потом после очередного рефреша у него пропали данные за 10 часов работы. И ACID это не противоречит.
Нет, это противоречит "математически строгому ACID". Да, это нормально. Я вам ещё раз объясню: схема, в которой данные не пропадают никогда, физически нереализуема. Всё, что можно сделать — это уменьшить плотность вероятности сбоя в единицу времени. Вы рассматриваете консистентность как булеву переменную. Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности. Осмысленный подход — вводить вероятностные параметры системы — MTBF, MTBR, и т.д., и сравнивать различные реализации по этим параметрам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, a_g_99, Вы писали:
__>по сути неверна, так как не учитывает все возможное многообразие задач. Приведу более простой пример из моей практики. В 2k3 разрабатывал одну web-систему — в бэкэнде был sql server 2k (лучшее решение на тот момент по произв./стоимость). Хотя данных было не очень много (около 5~7 Гб), OLTP-нагрузка для того времени была высокой, так что пришлось специально "хинтить", настраивать query governer и пинировать некоторые таблицы (ms-евангилисты, если вы это читаете срочно начинайте гуглить или бинговать эти страшные слова).
Ну да, конечно. MS евангелисты не знают того, что знаем мы, SQL Server DBA среднего пошиба.
Верится с трудом, хотя если имеются в виду определенные MS SQL Server MVP последнего созыва, то вполне может быть, что и не знают. Мельчает народ, мельчает...
Ну а уж от хинтов программисты просто без ума, пихают их куда не попадя. Поубивав бы.
__>Сервер хорошо держал нагрузку на OLTP, но поиск по БД (длинные запросы) убивал перфоманс напрочь; эскалация, массовый рост tempdb и скачки в RAM. Нашли быстрое решение — вынесли поисковые таблицы на отдельный mssql2k сервер, все стало super. Это ответ на ваш вопрос "зачем" ?
Так вроде как абсолютно стандартное решение — разделение OLTP и BI нагрузок. Разве нет?
Здравствуйте, _ABC_, Вы писали:
_AB>Ну да, конечно. MS евангелисты не знают того, что знаем мы, SQL Server DBA среднего пошиба.
Я не DBA, так что высказаться на тему сравнения евангелистов и DBA с полной страстью не смогу. Но если бы нужно было поставить кругленькую сумму денег на DBA против евангелиста при оценке навыков владения SQL Server, я бы ставил на DBA среднего пошиба. В память врезалась одна история — будучи еще зеленым программистом получил психологическую травму, посетив одну конференцию MS. Там известный упитанный евангелист на спорте с постамента призывно кричал что SQL Server как труба. Шок был жесткий (я только не понял железная или пластиковая . Или габой ?). _AB>Верится с трудом, хотя если имеются в виду определенные MS SQL Server MVP последнего созыва, то вполне может быть, что и не знают. Мельчает народ, мельчает...
MVP — это model-view-controller ? Шутка
Они точно не знают. Да и зачем им это? Ведь есть книжки Дилани и Бен-Гана, где по верхам накидано что и как. Или еще хуже SQL Server для начинающих русского писателя Пети Иванова (это вообще супер, читаешь слезами обливаешься). А понимать концепции работы оптимизатора, системы ввода-вывода, стратегий соединения — не барское это дело для таких людей . _AB>Ну а уж от хинтов программисты просто без ума, пихают их куда не попадя. Поубивав бы.
Использование хинтов как хирургия. Такое вмешательство крайне редко, опасно но иногда необходимо. Если не умеете этого делать, лучше придерживаться общепринятой концепции — хинты зло, микрософт не рекомендует. _AB>Так вроде как абсолютно стандартное решение — разделение OLTP и BI нагрузок. Разве нет?
Это просто контрпример к вашей фразе — зачем дробить коллекции меньше 10Гб. Ответ — производственная необходимость
Здравствуйте, a_g_99, Вы писали:
_AB>>Ну а уж от хинтов программисты просто без ума, пихают их куда не попадя. Поубивав бы. __>Использование хинтов как хирургия. Такое вмешательство крайне редко, опасно но иногда необходимо.
Вот-вот. Хирургия. А пошла мода при насморке нос отрезать.
__>Если не умеете этого делать, лучше придерживаться общепринятой концепции — хинты зло, микрософт не рекомендует.
В том-то и проблема, что "умеют".
Здравствуйте, a_g_99, Вы писали:
_AB>>Суть понятна. Почему DL385 G7 с 2-мя процами и 32 ГБ оперативной пямяти за примерно 10 тысяч в данном случае справится хуже, чем 3 сервера с одним процом и 4 ГБ оперативы по пять тысяч каждый? __>Вы ушли куда-то в сторону от темы. Если ставить так вопрос — то конечно DL385 G7 выйдет победителем. Я бы конечно мог сейчас с пеной у рта доказывать, что вот если силами моджахедов собрать в пакистане на коленке сервера с одним CPU, то это было бы еще круче, чем кастрированный DL385 G7, у которого какой-нибудь плюгавый мужик из HP при конфигурировании выдернул все что мог, но это пустая трата времени.
Ну вы бы хоть какой-то пример привели в защиту своих утверждений. Я пока никак не могу найти ситуацию, где цена одного сервера росла бы быстрее, чем цена кучи серверов, суммарно вытягивающих все те же характеристики.
__>В общем, мой посыл был следующим — в некоторых случаях (не всегда) горизонтальное масштабирование будет эффективным чем вертикальное. Напр. с точки зрения снижения стоимости входа + возможно ROI. И это касается соврешенно разных систем — маленьких, средних, больших.
Покажите пожалуйста, в каких именно случаях это так.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну вы бы хоть какой-то пример привели в защиту своих утверждений. Я пока никак не могу найти ситуацию, где цена одного сервера росла бы быстрее, чем цена кучи серверов, суммарно вытягивающих все те же характеристики.
Простой пример для серии IBM iSeries 80x (AS400). Я взял эту серию для сравнения исходя из двух причин:
1) Сервера серии уже настроены и преконфигурированы.
2) Для данной серии есть уже готовая метрика CPW, разработанная самой IBM для расчета производительности системы. Методику расчета можете погуглить отдельно. Производительность каждого сервера оценивается данной метрикой.
Средние цены в штатах на сервера можно посмотреть напр. здесь — http://www.nvcsales.com/ibm/eserver-i.asp.
Теперь простой пример:
берем средненькие iSeries 800 (FP — 2464) стоимостью $51,893 при CPW=950
и берем хороший мощный iSeries 870 в интерпрайзе (FP — 2486) стоимостью $1,966,778 при CPW=11500
Итого теор. чтобы полностью покрыть один [870] нам потребуется 11500/950 = 13 [800] серверов
Цена 13*$51,893 = 674,609 < 2 млн. в 3 раза. Соотвественно если посмотрите на различные серии то увидите, что чем ближе серии тем меньше разрыв по деньгам (что логично)
Естесвенно TCO для сети машин будет существенно(многократно?) выше чем для одного суперсервера за счет Software license costs & maintenance, электроэнергии и пр. adm. costs. Но ROI скорее всего ниже.
S>Покажите пожалуйста, в каких именно случаях это так.
Я кратко попробую перечислить области, наверное так будет наглядно и правильно:
1) CDN-системы. Здесь DL определяет реализацию.
2) открытые проекты & community, которые должы использовать "общественные" мощности. проект SETI
3) системы с неизвестным верхним пределом масштабирования. напр. youtube
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Sinclair, Вы писали:
S>>Ну вы бы хоть какой-то пример привели в защиту своих утверждений. Я пока никак не могу найти ситуацию, где цена одного сервера росла бы быстрее, чем цена кучи серверов, суммарно вытягивающих все те же характеристики. __>Итого теор. чтобы полностью покрыть один [870] нам потребуется 11500/950 = 13 [800] серверов
А вот тут поподробнее. Я, конечно, верю, что есть задачи с идеальной параллельностью, но мы, вроде бы, о БД говорим — а тут все не совсем так, прямо скажем.
Почему 13 серверов будут работать в 13 раз быстрее одного? Ну и, разумеется, не посчитана инфраструктура
Лучше уж сравнивать по какому-нибудь tpc.org, там есть кластерные решения и решения на одной машине.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Здравствуйте, a_g_99, Вы писали:
ДФ>А вот тут поподробнее. Я, конечно, верю, что есть задачи с идеальной параллельностью, но мы, вроде бы, о БД говорим — а тут все не совсем так, прямо скажем.
В этом-то то и преимущество окружающего нас мира — в нем существует огромный разброс задач даже применительно к БД. Я напр. могу привести кучу реальных примеров — один сервер, одна БД — успешное решение. Но есть и другие, когда разделение задач действительно выгодно (напр. OLTP и OLAP, CDN/geolocation) ДФ>Почему 13 серверов будут работать в 13 раз быстрее одного? Ну и, разумеется, не посчитана инфраструктура
Вы неправильно поняли. Из такого "идеализированного" сравнения следует что 13 серверов могут работать примерно так же как один, но стоимость затрат на их приобретение будет существенно ниже. Про инфраструктуру — согласен на 100%. Дополнительно нужно будет организовать сеть, пространство, обеспечить поддержку пула серверов и т.д. Но даже при таком раскладе стоимость подобной сети будет пониже одного суперсервера + создается возможность более гибкого масштабирования кластера в целом.
ДФ>Лучше уж сравнивать по какому-нибудь tpc.org, там есть кластерные решения и решения на одной машине.
Я буду только за, если кто-то приведет стату по tpc cluster/no cluster, чтобы разрушить или подтвердить мои утверждения
Здравствуйте, a_g_99, Вы писали: __>Цена 13*$51,893 = 674,609 < 2 млн. в 3 раза. Соотвественно если посмотрите на различные серии то увидите, что чем ближе серии тем меньше разрыв по деньгам (что логично)
Спасибо, интересный пример.
Да, если говорить о чистой вычислительной мощности, то цена растёт нелинейно, по крайней мере, за пределами "среднего" диапазона.
Но для баз данных важна дисковая подсистема. И у меня вызывает лёгкую оторопь манера некоторых людей тут сравнивать многодисковые SAN-системы со встроенными в дешёвые сервера десктопными винтами.
__>Естесвенно TCO для сети машин будет существенно(многократно?) выше чем для одного суперсервера за счет Software license costs & maintenance, электроэнергии и пр. adm. costs. Но ROI скорее всего ниже.
S>>Покажите пожалуйста, в каких именно случаях это так. __>Я кратко попробую перечислить области, наверное так будет наглядно и правильно: __>1) CDN-системы. Здесь DL определяет реализацию. __>2) открытые проекты & community, которые должы использовать "общественные" мощности. проект SETI __>3) системы с неизвестным верхним пределом масштабирования. напр. youtube
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, a_g_99, Вы писали:
ДФ>>Лучше уж сравнивать по какому-нибудь tpc.org, там есть кластерные решения и решения на одной машине. __>Я буду только за, если кто-то приведет стату по tpc cluster/no cluster, чтобы разрушить или подтвердить мои утверждения
А чего тут приводить — всё доступно публично. Кластерных решений — всего четыре. Из относительно свежих — вот:
10366554 tpmC при цене 1.38 USD за tpmC
30249688 tpmC при цене 1.01 USD за tpmC
Всё остальное — некластерное. Например, есть 5055888 tpmC при цене 0.89 USD за tpmC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Не будет. В момент "фэйловера" она нарушиться, если есть недореплицированные комиты. Эти комиты уезжают в будущее. S>Ок, в такой схеме (если происходит фейловер для клиента, который работал с мастером на запись) — да, нарушается последовательность, это правда. С точки зрения теории кристалла, это частичное нарушение durability. Не очень важно то, что произошёл фейловер. С тем же успехом могло произойти восстановление из бэкапа — и с тем же результатом, "изменения за последние xxx секунд потеряны".
Не "потеряны", а "уехали в будущее". Это хужее будет.
S>Нужно понимать, что схем, которые бы гарантировали 100% durability, в природе не существует. Кворум, на который вы так сильно уповаете, принципиально не лучше. Для него просто вероятность нарушения durability ниже. Это место вам понятно или нужно подробнее пояснять?
Далось тебе это дюрабилити. Вроде говорили про консистентность. Пробую последний раз. В такой схеме "фэйловер" это штатная ситуация и может происходить хоть по 100 раз на день. (Собственно, есть статистика, что большая часть так называемых фэйловеров происходит просто от того, что система что-то там надумала, а не из-за реальных сбоев). Каждый раз будет бочина с консистентностью. Клиент (напр., сервер приложений) должен это учитывать (например, что бы поддерживать когерентность кеша).
ANS>>Маша сделала комит, а потом говорит Пете человеческим голосом: "Смотри что я тут закомитила". Петя смотрит и в зависимости от того, что он может увидеть и получаются разные гарантии консистентности. Ты утверждаешь, что в ACID системе Петя (после получения приглашения от Маши) может не увидеть Машин комит, а через 5 минут позже — увидеть. Я уверен, что в ACID системе Петя обязан увидеть комит Маши сразу, если она его пригласила. S>На чём основана ваша уверенность? И зачем она вам нужна?
На практике. btw, запись в РДБМС обычно состоит еще и из чтения (для проверки,к примеру, уникальности). В sequental consistency операции чтения и записи могут разъехаться во времени, что сделает невозможным проверку констрейнтов.
ANS>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер". S>Поясните. Я не вижу ошибки.
Ошибка после дефиса.
S>Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не "потеряны", а "уехали в будущее". Это хужее будет.
Вы продолжаете говорить загадками. Поясните мне разницу между эффектами, наблюдаемыми клиентом при падении одной машины и восстановлении из бэкапа, датированного Tx-Delta, и при фейловере на слейва, который отстаёт по репликации на Delta.
ANS>Далось тебе это дюрабилити. Вроде говорили про консистентность.
Просто то, что в CAP называют консистентностью, в ACID называют дюрабилити. Мы же это вроде бы уже обсуждали.
ANS>Пробую последний раз. В такой схеме "фэйловер" это штатная ситуация и может происходить хоть по 100 раз на день. (Собственно, есть статистика, что большая часть так называемых фэйловеров происходит просто от того, что система что-то там надумала, а не из-за реальных сбоев). Каждый раз будет бочина с консистентностью. Клиент (напр., сервер приложений) должен это учитывать (например, что бы поддерживать когерентность кеша).
Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"? Поймите, что вся теория надёжности — про построение более надёжных систем из менее надёжных компонентов. Если у вас сервер A падал в среднем раз в шесть месяцев, то от включения его в Active/Passive кластер он не станет падать чаще. Вся идея фейловера — в том, чтобы увеличить MTBF. Если вам это непонятно — спрашивайте.
Если сервер падает 100 раз в день, значит у него MTBF
ANS>На практике. btw, запись в РДБМС обычно состоит еще и из чтения (для проверки,к примеру, уникальности). В sequental consistency операции чтения и записи могут разъехаться во времени, что сделает невозможным проверку констрейнтов.
Вы путаете две разных вещи. Вы говорите о действиях, происходящих в одной транзакции. ACID требует от них упорядоченности.
Если вы разносите проверку уникальности и запись в две разных транзакции — значит, вы не понимаете, что такое транзакция. Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
ANS>>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер". ANS>Ошибка после дефиса.
Простите, а сколько серверов останется после падения одного из двух? Если у вас ещё и арифметика альтернативная, то придётся беседу свернуть. S>>Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности. ANS>Ерунда.
Прекрасный аргумент. Продолжайте в том же духе — это соберёт под знамёна NoSQL массы поклонников.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Не "потеряны", а "уехали в будущее". Это хужее будет. S>Вы продолжаете говорить загадками. Поясните мне разницу между эффектами, наблюдаемыми клиентом при падении одной машины и восстановлении из бэкапа, датированного Tx-Delta, и при фейловере на слейва, который отстаёт по репликации на Delta.
.
ANS>>Далось тебе это дюрабилити. Вроде говорили про консистентность. S>Просто то, что в CAP называют консистентностью, в ACID называют дюрабилити. Мы же это вроде бы уже обсуждали.
Это не так. То, что гарантии консистентности в ACID /похоже/ проистекают из D не делает это одинаковыми.
S>Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"?
Иначе нет никакого смысла огород городить.
ANS>>На практике. btw, запись в РДБМС обычно состоит еще и из чтения (для проверки,к примеру, уникальности). В sequental consistency операции чтения и записи могут разъехаться во времени, что сделает невозможным проверку констрейнтов. S>Вы путаете две разных вещи. Вы говорите о действиях, происходящих в одной транзакции. ACID требует от них упорядоченности. S>Если вы разносите проверку уникальности и запись в две разных транзакции — значит, вы не понимаете, что такое транзакция.
Когда говорят о консистентности, то, естественно, рассматривают отдельные операции чтения/записи. Границы транзакций это просто те диапазоны в пределах которых операции чтения/записи могут перемещаться системой. В твоей модели операции могут уезжать за границы транзакций, что есть ерунда.
S>Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
Всё таки. Маша сделала комит и звонит Пете. Петя комита не видит, проходит пол часа потом видит. По твоему это для ACID базы нормально?
ANS>>>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер". ANS>>Ошибка после дефиса. S>Простите, а сколько серверов останется после падения одного из двух? Если у вас ещё и арифметика альтернативная, то придётся беседу свернуть.
Уточню. Ошибка в том, что ты поставил слово "ведь". Правильно так: "При двух серверах падение любого — останется только один сервер. Получается катастрофа, потому что...".
S>>>Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности. ANS>>Ерунда. S>Прекрасный аргумент.
Это не аргумент. Это оценка.
S>Продолжайте в том же духе — это соберёт под знамёна NoSQL массы поклонников.
Как вроде я тебя агитирую. Постов, где люди делают фэйловер на 2-х серверах и асинхронной репликации и удивляются результату, в инете есть. Хотя даже одного примера достаточно, чтобы показать, что схема в общем случае не рабочая. И, что интересно, речь тут не об NoSql.
.
Я уже комментировал этот пример. Люди намеренно сделали split brain. Фейловера, как такового, не произошло — часть клиентов стали работать с отдельной системой.
S>>Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"? ANS>Иначе нет никакого смысла огород городить.
Ещё раз: все огороды и весь смысл сводятся к подъёму MTBF и availability уменьшению downtime. Я в прошлый раз недописал.
Если у вас сервер падает 100 раз в день — у него MTBF 864 секунды, или примерно 15 минут. Если RT, рекавери после фейла занимает 5 минут, то его availability = 66%. Если рекавери вовсе нету, то два таких сервера в режиме фейловера, очевидно, сдохнут через полчаса. "Три сервера с кворумом" — через 45 минут. И так далее — серъёзно нарастить надёжность в системах, не предусматривающих восстановление, невозможно. Ну поставите вы 100 серверов. Сдохнут через сутки.
Так вот, если рекавери занимает 5 минут, то 33% времени кластер работает в режиме одного сервера. Фейл оставшегося сервера в это время приведёт к фейлу, наблюдаемому клиентом. В простой модели сбоев, равномерно распределённых во времени, второй сервер тоже лежит 33% своего времени.
То есть, MTBF всей системы равно 45 минутам, а availability = 86%. Если вас это устраивает, то всё хорошо. Если нет — надо делать что-то ещё. Пока что видно, что из двух серверов с такой надёжностью получить приемлемую систему не получается. Потому, что формула даёт нам MTBF2 = MTBF1*MTBF1/RT, а доступность, A2 = (MTBF2-RT)/MTBF2 = 1 — (RT/MTBF1)^2. Или 1 — (1-A1^2).
Отсюда понятно, что надо либо добавлять ещё сервера, либо быстрее восстанавливать их, либо улучшать MTBF.
Некоторые товарищи делают регулярный фейловер — но не потому, что это "штатная ситуация", а для того, чтобы убедиться, что всё сработает корректно и избежать ситуации, когда slave система приходит в негодность.
ANS>Когда говорят о консистентности, то, естественно, рассматривают отдельные операции чтения/записи. Границы транзакций это просто те диапазоны в пределах которых операции чтения/записи могут перемещаться системой.
Нет. Вы неправильно понимаете транзакции. Транзакции — это группы операций, для которых есть гарантия сериализуемости.
Определение сериализуемости — возможность построить некоторый порядок, в котором как будто бы выполнялись транзакции. Понимаете, некоторый, а не какой-то конкретный. Конкретный порядок есть только с точки зрения одного клиента. Перечитайте определения.
ANS>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда.
Не могут.
S>>Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
ANS>Всё таки. Маша сделала комит и звонит Пете. Петя комита не видит, проходит пол часа потом видит. По твоему это для ACID базы нормально?
Конечно. Потому, что математическая модель сериализуемости не подразумевает никаких звонков кому бы то ни было. У Маши и Пети есть ровно один способ общаться — это СУБД, с которой они работают. "Звонок" означает, что Маша произвела транзакцию, которую увидел Петя. То есть Маша произвела транзакцию T1 (основную), затем T2 (звонок).
Тогда есть гарантии того, что Петя будет видеть их в том же порядке.
А в ситуации, которую вы описываете (два независимых канала асинхронных коммуникаций) ожидать какого-то определённого порядка событий не стоит.
Простой жизненный пример: Маша положила денег на счёт Пете через свой мобильный телефон, и тут же ему звонит. Из очевидных соображений понятно, что Петя запросто может увидеть деньги на счету значительно позже, чем услышать Машин голос. И никакому ACID это не противоречит: система перевода денег выдала Маше подтверждение коммита. Это означает, что она обязуется доставить деньги Пете, ни больше, ни меньше. Это не означает, что деньги доставлены Пете. Sequential consistency означает, что если Маша положила Пете сначала 100, а потом 200 рублей, то Петя не может сначала увидеть на счету 200, а потом 300. Только 100, а потом 300. Ну, или сразу 300, если будет долго тупить.
ANS>>>>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого ANS>Уточню. Ошибка в том, что ты поставил слово "ведь". Правильно так: "При двух серверах падение [i]любого — останется только один сервер. Получается катастрофа, потому что...".
Потому, что система из одного сервера ненадёжна. Вы несколько раз повторили (странный) тезис о том, что при отказе слейва нужно запрещать коммиты. Это и есть отказ от доступности. Фейл одной машины привёл к отказу обслуживания клиента.
ANS>Как вроде я тебя агитирую. Постов, где люди делают фэйловер на 2-х серверах и асинхронной репликации и удивляются результату, в инете есть. Хотя даже одного примера достаточно, чтобы показать, что схема в общем случае не рабочая. И, что интересно, речь тут не об NoSql.
Удивление людей — штука плохопредсказуемая. Вот вы удивляетесь совершенно очевидным вещам про ACID.
Рабочесть схемы — штука довольно-таки условная. Вот вы, к примеру, отказываетесь оперировать характеристиками надёжности, а в бинарной модели консистентных систем не бывает в принципе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Разница подробно описана в посте про hadr и фэйловер на 2х серверах: http://www.rsdn.ru/forum/philosophy/4715865.1.aspx
. S>Я уже комментировал этот пример. Люди намеренно сделали split brain. Фейловера, как такового, не произошло — часть клиентов стали работать с отдельной системой.
Намеренно? Ну-ну.
S>>>Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"?
Формулы skipped. Мне не ясно, если работа системы это не "штатная ситуация", то что тогда "штатная"?
ANS>>Когда говорят о консистентности, то, естественно, рассматривают отдельные операции чтения/записи. Границы транзакций это просто те диапазоны в пределах которых операции чтения/записи могут перемещаться системой. S>Нет. Вы неправильно понимаете транзакции. Транзакции — это группы операций, для которых есть гарантия сериализуемости.
Да-а. "Консистентность" неприменима к транзакциям целиком. Только к отдельным операциям. И границы транзакций (совместно с уровнем изоляции) просто ограничивают возможность переупорядочивания операций чтения/записи. Вот смотри (то что обычно эти статьи об ОЗУ и процессорах пусть тебя не смущает).
В sequental consistency допустим такой результат:
T1: W(x)1 T
------------------------------
T2: T R(x)0 T R(x)1
"T" я задал границы транзакций. Чтение "R(x)0" нужно для проверки констрейнта. Оно возвращает, что записи нет (она приедет позже). Результат — ничего не работает. Значит, нужна модель консистентности строже чем "sequental".
S>Определение сериализуемости — возможность построить некоторый порядок, в котором как будто бы выполнялись транзакции. Понимаете, некоторый, а не какой-то конкретный. Конкретный порядок есть только с точки зрения одного клиента. Перечитайте определения.
Это так, но к делу отношения не имеет.
ANS>>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда. S>Не могут.
Могут.
S>>>Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
См. выше.
ANS>>Всё таки. Маша сделала комит и звонит Пете. Петя комита не видит, проходит пол часа потом видит. По твоему это для ACID базы нормально? S>Конечно.
Не знаю обрадует это тебя или огорчит, но твоё мнение в мире уникально.
S>А в ситуации, которую вы описываете (два независимых канала асинхронных коммуникаций) ожидать какого-то определённого порядка событий не стоит. S>Простой жизненный пример: Маша положила денег на счёт Пете через свой мобильный телефон, и тут же ему звонит. Из очевидных соображений понятно, что Петя запросто может увидеть деньги на счету значительно позже, чем услышать Машин голос. И никакому ACID это не противоречит: система перевода денег выдала Маше подтверждение коммита.
Вообще-то, такое поведение называется "eventual consistency". И свойственно оно именно NoSql системам. Это просто подтверждение моего тезиса о том, что большинство современных систем в целом (со всеми кешами, очередями и пр.) уже NoSql-системы, не смотря на то, что где-то там внизу есть ACID СУБД. И какие гарантии консистентности там есть — неизвестно. Скорее всего они potentialy consistent
Здравствуйте, Andrei N.Sobchuck, Вы писали: S>>Я уже комментировал этот пример. Люди намеренно сделали split brain. Фейловера, как такового, не произошло — часть клиентов стали работать с отдельной системой. ANS>Намеренно? Ну-ну.
Конечно.
ANS>Формулы skipped. Мне не ясно, если работа системы это не "штатная ситуация", то что тогда "штатная"?
С точки зрения клиента, штатная ситуация — это когда клиент выполняет запрос и получает результат. Нештатная — это когда клиент выполняет запрос, но результата не получает.
С точки зрения сервера штатная ситуация — это работа сервера. Нештатная — отказ сервера.
То, что кластер скрывает сбои сервера от клиента не означает, что теперь сервер можно безопасно перегружать. Это как противопожарная пропитка — она не означает, что после неё в деревянном домике можно будет разводить костры. Она всего лишь означает, что деревянный домик будет немножко медленнее гореть.
Точно так же и кластер — он понижает частоту наблюдаемых клиентом нештатных ситуаций. А вы почему-то думаете, что он позволяет их избежать совсем.
ANS>Да-а. "Консистентность" неприменима к транзакциям целиком. Только к отдельным операциям.
Нет. Только к транзакциям целиком.
ANS>"T" я задал границы транзакций. Чтение "R(x)0" нужно для проверки констрейнта. Оно возвращает, что записи нет (она приедет позже). Результат — ничего не работает.
Ошибочное утверждение выделено. Всё прекрасно работает. Какой именно предикат сломался в вашей программе?
Поймите, что консистентность — это всего лишь некоторая функция от данных. Например, сумма остатков на всех счетах в банковской системе всегда должна быть равна нулю.
Все гарантии ACID сводятся к тому, что если у нас любая транзакция сохраняет этот инвариант, то и любая последовательность этих транзакций будет его сохранять. ANS>Значит, нужна модель консистентности строже чем "sequental".
Такая модель может использоваться. Но никакого требования её иметь нету. Почитайте Бернстайна, там подробно написано про транзакции. ANS>Это так, но к делу отношения не имеет.
Ну конечно же имеет. ANS>>>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда. ANS>Могут.
Вы фантазируете.
ANS>Не знаю обрадует это тебя или огорчит, но твоё мнение в мире уникально.
Вот это — вряд ли.
ANS>Вообще-то, такое поведение называется "eventual consistency". И свойственно оно именно NoSql системам.
Вообще-то нет. Eventual позволяет переупорядочивать апдейты от одного и того же источника. Sequential — нет.
S>>Потому, что система из одного сервера ненадёжна. Вы несколько раз повторили (странный) тезис о том, что при отказе слейва нужно запрещать коммиты. ANS>Он тебе кажется странным из-за странного понимания термина "консистентность".
Ну тогда давайте разъясним его, объяснив, почему не нужно запрещать коммиты при отказе мастера.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dimgel, Вы писали:
D>Чтобы меня можно было подпустить, прошу разъяснить первый пункт. Из трёх содержащихся в нём утверждений понимаю только одно — про LB. Про master-master и что такое локальность можно поподробнее? Спасибо.
Локальность — это минимизация response time для клиентов. Допустим, Вася и Маша расположены на расстоянии в 1200 миллисекунд друг от друга (roundtrip). Это означает, что принципиально невозможно дать им обоим ендпоинт, до которого будет расстояние в 400 миллисекунд. Master-master означает, что мы можем дать им два разных (локальных) ендпоинта, каждый из которых будет отвечать своему клиенту с достаточной скоростью, например — 200 миллисекунд.
Понятно, что никакая схема со strict consistency не даст в master-master ничего полезного. Потому что если Машин сервер стоит в 200 мсек от Маши, а Васин — в 200мсек от Васи, то от Машиного сервера до Васиного будет минимум 800 мсек. Так что нет никакого способа, при котором в ответ на Васину транзакцию его сервер успеет договориться с Машиным сервером о распределённой блокировке, и вернуть Васе резулььтат. Это займет столько же или больше, чем напрямую сходить на Машин сервер.
Поэтому люди, которые хотят иметь master-master, должны отдавать себе отчёт в том, что они делают.
Можно пожертвовать строгой консистентностью, и реализовать ручное разрешение конфликтов (применяется в многих документо-ориентированных системах).
Можно развести workflow так, чтобы в каждый момент у каждого документа был только один владелец. С точки зрения теории, эта реализация длинных транзакций выражается в терминах коротких транзакций, в которой первоначальная транзакция (acquire document lock) может быть долгой, зато после неё многие транзакции в тот же документ выполняются быстро. Требует некоторых ограничений от предметной области — например, локальности зависимостей. То есть мы считаем, что изменения в документ не зависят от изменений, внесённых другими авторами в другие документы.
Это кажется тривиальным и очевидным; но для более общего случая неприменимо. Например, в классическом примере перевода денег со счёта А на счёт Б нам было бы нужно сначала получить "длинный лок" на оба счёта, после чего "быстро" провести перевод денег и отпустить счета. Понятно, что смысла в этом особого нет, т.к. мы не ожидаем провести много операций с этими двумя счетами, и накладные расходы на получение блокировки будут значительными.
Для коммутативных операций можно обойтись без жесткого порядка.
Например, если у нас есть общее поле счётчика чего-то (голоса на выборах), и на каждом избирательном участке выполняются транзакции типа count+=delta, то не обязательно захватывать глобальную блокировку этого счётчика. Локальные последовательности модификаций, полученных на каждом избирательном участке, можно синхронизовывать друг с другом в любом порядке; главное — синхронизовывать delta, а не count.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Локальность — это минимизация response time для клиентов. S>[...]
Понятно, спасибо.
S>Для коммутативных операций можно обойтись без жесткого порядка. S>Например, если у нас есть общее поле счётчика чего-то (голоса на выборах), и на каждом избирательном участке выполняются транзакции типа count+=delta, то не обязательно захватывать глобальную блокировку этого счётчика. Локальные последовательности модификаций, полученных на каждом избирательном участке, можно синхронизовывать друг с другом в любом порядке; главное — синхронизовывать delta, а не count.
В данном use case, я так понимаю, и единая база с репликой на каждом участке не нужна (и даже вредна, если говорить о безопасности).
А — ясно. Я думал ты что новое скажешь (как то, что видимость изменений после комита в ACID не обязательна), а у тебя всё свелось к банальному "эти системы настолько легко делать, что правильно никто не умеет".
ANS>>Формулы skipped. Мне не ясно, если работа системы это не "штатная ситуация", то что тогда "штатная"? S>С точки зрения клиента, штатная ситуация — это когда клиент выполняет запрос и получает результат. Нештатная — это когда клиент выполняет запрос, но результата не получает. S>С точки зрения сервера штатная ситуация — это работа сервера. Нештатная — отказ сервера.
Хм. Для меня нештатная ситуация это когда люди по зданию бегают махая руками над головой и крича "всё пропало". А штатная — когда всё спокойно. Вот как отказ винта в рейдё.
ANS>>Да-а. "Консистентность" неприменима к транзакциям целиком. Только к отдельным операциям. S>Нет. Только к транзакциям целиком.
Если рассматривать транзакции целиком, то ты как бы сакрализируешь процес выполнения запроса. В то время как рассмотрение отдельных операций чтения-записи объясняет почему сервер работает так и не иначе. Следовательно это более удобная модель, а значит правильная.
ANS>>"T" я задал границы транзакций. Чтение "R(x)0" нужно для проверки констрейнта. Оно возвращает, что записи нет (она приедет позже). Результат — ничего не работает. S>Ошибочное утверждение выделено. Всё прекрасно работает. Какой именно предикат сломался в вашей программе?
Уникальность, внешний ключ.
S>Поймите, что консистентность — это всего лишь некоторая функция от данных. Например, сумма остатков на всех счетах в банковской системе всегда должна быть равна нулю.
Мы это уже проходили. Консистентность в ACID vs. "модели консистентности" в CAP.
S>Все гарантии ACID сводятся к тому, что если у нас любая транзакция сохраняет этот инвариант, то и любая последовательность этих транзакций будет его сохранять.
Но цена этого настолько велика, что люди активно ищут способа помножить эти гарантии на ноль.
ANS>>>>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда. ANS>>Могут. S>Вы фантазируете.
ANS>>Не знаю обрадует это тебя или огорчит, но твоё мнение в мире уникально. S>Вот это — вряд ли.
Тогда тебя не затруднит найти ссылки на такое мнение.
ANS>>Вообще-то, такое поведение называется "eventual consistency". И свойственно оно именно NoSql системам. S>Вообще-то нет. Eventual позволяет переупорядочивать апдейты от одного и того же источника. Sequential — нет.
В eventual упор на видимость изменений. in-order он или out-of-order не важно. Если рассмотерть твой пример с постановкой перевода в очередь, то окажется что сам писатель (тот кто разместил перевод) не видит результатов своих действий. Т.е. "W(x)1 R(x)0". Sequential такое запрещает.
S>>>Потому, что система из одного сервера ненадёжна. Вы несколько раз повторили (странный) тезис о том, что при отказе слейва нужно запрещать коммиты. ANS>>Он тебе кажется странным из-за странного понимания термина "консистентность". S>Ну тогда давайте разъясним его, объяснив, почему не нужно запрещать коммиты при отказе мастера.
Это при синхронной репликации. Иначе бы она не называлась синхронной. Что будет при асинхронной — я давал ссылку
. Как можна "весь траффик автоматически переключается в работающий датацентр" при "потеря связности между датацентрами может составлять часы" мне лично не понятно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Хм. Для меня нештатная ситуация это когда люди по зданию бегают махая руками над головой и крича "всё пропало". А штатная — когда всё спокойно. Вот как отказ винта в рейдё.
Мы же в техническом форуме. Тут лучше иметь более строгие критерии штатных и нештатных ситуаций, чем руки и крики.
ANS>Если рассматривать транзакции целиком, то ты как бы сакрализируешь процес выполнения запроса. В то время как рассмотрение отдельных операций чтения-записи объясняет почему сервер работает так и не иначе. Следовательно это более удобная модель, а значит правильная.
Я не понимаю, что такое "сакрализируешь". Не надо ничего изобретать — почитайте Бернстайна, он очень подробно разжёвывает, что такое транзакция, и как она работает. Ваша модель просто некорректна, поэтому неважно насколько она удобна.
ANS>Уникальность, внешний ключ.
Там нет никакой уникальности или внешнего ключа. В вашей транзакции вообще нет операций записи, которые могли бы сломаться. То, что вы ожидаете, что результат, полученный вами в пределах транзакции, останется действительным и после коммита — это ваши личные тараканы.
ANS>Мы это уже проходили. Консистентность в ACID vs. "модели консистентности" в CAP.
Вы это как-то плохо проходили.
ANS>Но цена этого настолько велика, что люди активно ищут способа помножить эти гарантии на ноль.
ANS>Тогда тебя не затруднит найти ссылки на такое мнение.
Почитайте учебники. Бернстайна например.
ANS>В eventual упор на видимость изменений. in-order он или out-of-order не важно.
Это вы откуда взяли?
S>>Ну тогда давайте разъясним его, объяснив, почему не нужно запрещать коммиты при отказе мастера. ANS>Это при синхронной репликации.
Вы не ответили на вопрос. Допустим, у нас синхронная репликация. Почему не нужно запрещать коммиты при отказе мастера?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Мы же в техническом форуме. Тут лучше иметь более строгие критерии штатных и нештатных ситуаций, чем руки и крики.
Ок. Отказ винта в рейде это уже нештатная ситуация?
S>Я не понимаю, что такое "сакрализируешь".
Транзакция у тебя работает, а как — не важно. Хотя по сути каждая транзакция состоит из множества отдельных операций чтения/записи в разделяемую память. Это можно игнорировать и работать с идеальной моделью, но только до определённого предела.
S>Не надо ничего изобретать — почитайте Бернстайна, он очень подробно разжёвывает, что такое транзакция, и как она работает. Ваша модель просто некорректна, поэтому неважно насколько она удобна.
Моя модель — это какая?
ANS>>Уникальность, внешний ключ. S>Там нет никакой уникальности или внешнего ключа. В вашей транзакции вообще нет операций записи, которые могли бы сломаться.
"Там" — это где? Я повторю вопрос. Есть две последовательные транзакции в которых вставляется по одной строчке. Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже?
ANS>>Мы это уже проходили. Консистентность в ACID vs. "модели консистентности" в CAP. S>Вы это как-то плохо проходили.
Я тебя дал ссылку на статью где рассказывают о том, что такое "консистентность" (которая в CAP). Ты упорно ссылаешься на "консистентность", как определено в ACID. Упорство это достойно, но утомляет.
ANS>>Тогда тебя не затруднит найти ссылки на такое мнение. S>Почитайте учебники. Бернстайна например.
Ты точно помнишь о чем мы тут говорим? А то меня терзают смутные сомнения...
ANS>>В eventual упор на видимость изменений. in-order он или out-of-order не важно. S>Это вы откуда взяли?
Из определения.
S>Вы не ответили на вопрос. Допустим, у нас синхронная репликация. Почему не нужно запрещать коммиты при отказе мастера?
Очевидно, потому что slave никуда ничего не реплицирует.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ок. Отказ винта в рейде это уже нештатная ситуация?
В некотором смысле да. Если его не заменить в течение регламентированного времени, то от "надёжности" рейда быстро останутся только воспоминания. ANS>Транзакция у тебя работает, а как — не важно. Хотя по сути каждая транзакция состоит из множества отдельных операций чтения/записи в разделяемую память. Это можно игнорировать и работать с идеальной моделью, но только до определённого предела.
Это не нужно игнорировать. Нужно просто разобраться в том, как работают шедулеры операций для того, чтобы обеспечить требования сериализуемости транзакций.
ANS>Моя модель — это какая?
Модель, в которой транзакции обозначают границы перемещения операций во времени.
Модель, к которой все границы транзакций привязаны к некоему источнику времени, общему для всех участников распределённой работы.
ANS>"Там" — это где?
В вашем протоколе транзакций. Перечитайте своё сообщение внимательно. У вас три транзакции, в двух из которых есть только чтение.
ANS>Я повторю вопрос. Есть две последовательные транзакции в которых вставляется по одной строчке.
Что вы называете "последовательными" транзакциями?
Если они выполняются с одного клиента, то у него есть гарантии sequential consistency, т.е. порядок выполнения изменений детерминирован.
Если две транзакции выполняются с разных клиентов, то вопрос об их последовательности весьма условен.
ANS>Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже?
Очевидно, выполнив чтение перед записью.
Требования сериализуемости транзакций в ACID означают, что результат выполнения обеих транзакций будет эквивалентен некоторому последовательному их выполнению.
То есть, одна из транзакций будет обязана откатиться. Но кто из них первая, а кто вторая, сказать заранее невозможно. ANS>Из определения.
И чем тогда она отличается от sequential consistency S>>Вы не ответили на вопрос. Допустим, у нас синхронная репликация. Почему не нужно запрещать коммиты при отказе мастера? ANS>Очевидно, потому что slave никуда ничего не реплицирует. О, как здорово. Ну так и мастер без слейва ничего никуда не будет реплицировать. Сосредоточьтесь и ответьте, в чём же тут сакральная разница?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В некотором смысле да. Если его не заменить в течение регламентированного времени, то от "надёжности" рейда быстро останутся только воспоминания.
"В некотором смысле" — это строгий критерий для технического форума?
ANS>>Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже? S>Очевидно, выполнив чтение перед записью.
Так вот, при "sequential consistency" БД не обязана вернуть результат закомиченой вставки.
S>То есть, одна из транзакций будет обязана откатиться. Но кто из них первая, а кто вторая, сказать заранее невозможно.
Для того чтобы что-то откатить нужно увидеть, что в БД есть некие данные с которыми транзакция конфликтует. Если при их наличии система гарантировано эти данные возвращает это строгая консистентность. Если не гарантировано, то уровень слабее строгого.
ANS>>Из определения. S>И чем тогда она отличается от sequential consistency
Очевидно тем, что "sequential" — определение, а "eventual" — базворд.
S> О, как здорово. Ну так и мастер без слейва ничего никуда не будет реплицировать. Сосредоточьтесь и ответьте, в чём же тут сакральная разница?
Я уже отвечал, но повторюсь. Если при репликации не гарантируется, что закомиченные данные будут и в реплике, то это не синхронная репликация.
... ANS>>Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже? S> S>Очевидно, выполнив чтение перед записью. S>Требования сериализуемости транзакций в ACID означают, что результат выполнения обеих транзакций будет эквивалентен некоторому последовательному их выполнению. S>То есть, одна из транзакций будет обязана откатиться. Но кто из них первая, а кто вторая, сказать заранее невозможно.
...
извините что влезаю. Мне вот стало интересно как можно вставить перепринятие решения внутрь уже закоммиченной транзакции которая будет проигрываться из лога в будущем. То есть есть Т1 она прочитала Х — не нашла его — на клиенте решила что можно писать — записала Х — закоммитилась. Приходит Т2 и делает то же самое и тоже успешно так как Т1 временно уехала. Теперь вопрос а кто именно будет определять что Т1 надо откатывать когда она заново применяется из лога после того как завершилась Т2?
Здравствуйте, SleepyDrago, Вы писали:
SD>извините что влезаю. Мне вот стало интересно как можно вставить перепринятие решения внутрь уже закоммиченной транзакции которая будет проигрываться из лога в будущем.
Тут дело не в том, что из лога. А в зависимостях между транзакциями.
Если она есть — то ACID реально становится источником "общего времени".
Например, у нас все клиенты выполняют такой стейтмент (в implicit auto-commit transaction):
update timer set timer.value = timer.value + 1 output inserted.value
Выдаваемые ими значения будут определять последовательность транзакций. При этом номера будут одинаково видимыми для всех клиентов.
Если Маша закоммитила свою транзакцию и получила 5, то Петя не может тоже получить 5. И меньше, чем Маша, он получить тоже не может.
Вася, который выполняет просто select timer.value в цикле, будет наблюдать неубывающую последовательность (в силу sequential consistency). Но он, в отличие от Пети, не имеет гарантий того, что полученное им значение соответствует тому, которое получил Вася минуту назад.
Понятно, что мы не можем взять назад обещание, данное Маше при подтверждении её коммита. Но мы можем предотвратить транзакцию Пети от завершения. Там есть несколько стратегий. В оптимистичной блокировке, например, Петя вполне может получить 5, но при попытке коммита получить исключение.
В пессимистичной блокировке всё несколько меняется: если мы позволяем себе вести диалог в процессе транзакции, то уровень гарантий меняется в зависимости от выставленного уровня изоляции (или детального контроля над блокировками). В частности, Вася, получающий shared lock с автоотпусканием (read commited), рискует увидеть stale data. А если он попытается получить exclusive lock, то СУБД будет обязана дождаться синхронизации всего.
Поэтому так делать не рекомендуют: это, фактически, позволяет одному невежливому клиенту остановить работу всего кластера.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>"В некотором смысле" — это строгий критерий для технического форума?
Я вам привёл критерии этого некоторого смысла. Вам их недостаточно?
S>>Очевидно, выполнив чтение перед записью. ANS>Так вот, при "sequential consistency" БД не обязана вернуть результат закомиченой вставки.
А, понятно. Да, в некоторых случаях ACID приходится давать более сильные гарантии, чем sequential. Грубо говоря, чтения могут отдавать stale data, но как только у нас появляется зависимость по записи, придётся сериализовывать. Либо отказывать в коммите тем, кому не повезло.
ANS>Очевидно тем, что "sequential" — определение, а "eventual" — базворд.
S>> О, как здорово. Ну так и мастер без слейва ничего никуда не будет реплицировать. Сосредоточьтесь и ответьте, в чём же тут сакральная разница? ANS>Я уже отвечал, но повторюсь. Если при репликации не гарантируется, что закомиченные данные будут и в реплике, то это не синхронная репликация.
Вы имеете в виду, что при синхронной репликации при отказе слейва можно продолжать принимать коммиты на мастере?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Убери memcached, ситуация изменится? Ни разу. Это общий вопрос распределенных систем — как только ты получил данные из внешней системы, они перестали быть актуальные.
При данном подходе возможна такая аномалия: мы можем получать данные в обратном хронологическом порядке. То есть сначала получили свежие данные, потом еще раз обратились и получили более старые данные в сравнении с тем, что было первый раз. И вообще не понятно, зачем это все надо, если приличные СУБД сами умеют кешировать не хуже memcached, но с учетом ACID.
И это еще без учета кластеризации. С ней в случае с memcached вообще полный капец наступает в плане каких-либо гарантий.
Этож как такой брен написать надо.
.
