Здравствуйте, 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 сливает.
