SQL vs NOSQL?

Толсто.

Ну а все-таки, интересует мнение по данному вопросу. Толсто или нет-это отдельный вопрос.

Вы бы в талкс хотя бы запостили - люди хотя бы посмеялись. А так люди заходят в тред и уходят с фейспалмом.

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

интересует мнение по данному вопросу

[[Пространная тирада об инструменте и задачах, а также недалеких фанбоях]]

Сам спросил, сам ответил?

Я вот вчера зашел в строительный магазин и увидел шуроповерт! Для меня это был шок! Раньше я работал только с молотком.

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

все радикально изменится с появлением квантовых компьютеров.

Деление SQL/NoSQL крайне дурацкое, ибо наличие или отсутсвие поддержки SQL ничего координально не меняет, обычно идет речь об ACID (и как следствие не очень быстрых) и не-ACID (и как следствие быстрых) базах. По сути NoSQL это базы для каких-то не очень важных данных. Далее нужно смотреть требования и выбирать что больше подходит. Вопрос что лучше как всегда крайне не уместен.

А разве квантовые компьютеры будут использовать какие-то принципиально новые устройства для долговечного хранения информации? Некие квантовые SSD? Если нет, то радикальных изменения в рынке СУБД не будет.

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

Да

Деление SQL/NoSQL крайне дурацкое

Правильнее было бы сказать деление на реляционные и нереляционные БД.

обычно идет речь об ACID (и как следствие не очень быстрых) и не-ACID (и как следствие быстрых) базах

CouchDB например соответствует требования ACID, но является нереляционной NoSQL СУБД.

CouchDB например соответствует требования ACID, но является нереляционной NoSQL СУБД.

Ого. Думал таких нет. Ну тогда да, деление на реляционные и не реляционные более справедливое.

CouchDB например соответствует требования ACID

В пределах одного узла?

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

да

http://www.youtube.com/watch?v=b2F-DItXtZs

А разве квантовые компьютеры будут использовать какие-то принципиально новые устройства для долговечного хранения информации?

Думаю, что да... какие-то другие. классические устройства тут не подходят.

заменить реляционные СУБД

а ничего что большинство NoSQL является реляционными.

вброс уныл

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

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

Это какие? Реляционный, на сколько я знаю, суть есть синоним табличный, то есть когда записи в одной пространстве документов имеют фиксированный формат, то есть одинаковые колонки.

На вскидку могу назвать разве что VoltDB. MongoDb, CouchDB, Redis, MemBase таковыми не являются, так как по колючу можно засейвить документ со своим какаим-то специфическим набором полей.

и не-ACID (и как следствие быстрых) базах.

Ага, MyISAM

большинство NoSQL является реляционными.

В кошмарах, и в каком месте там реалиционная алгебра маскируется под map-reduce?

не умеют работать со сложными транзакциями.

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

Ограничение на размер объекта у них вроде также довольно существенные.

Вы все еще храните файлы в базе?

просто многие думают что слово реляционный - есть отношение между таблицами, хотя в теории это не так, а то что key=>value базы реляционны то тут я думаю и дураку понятно, хотя они не sql

key=>value базы реляционны то тут я думаю и дураку понятно, хотя они не sql

Хм. И что является доменом value? :)

Хорошо, потенциально более быстрых.

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

value и есть отенциальное значение домена

И что это за домен? И кстати, какой домен у key?

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

координально

В школу.

Как это не нужны? В доброй половине случаев использования РСУБД, в особенности со сложной структурой и связями они еще как нужны.

То есть в половине тех случаев когда наваяют макароны из foreign key? Согласен, но и там до авторов сего безобразия быстро доходит, что что-то нещадно тормозит. Но, например в финансовом секторе ничего не поделать.

И часто бывает так, что крупные объекты необходимо хранить в базе.

Ну расскажите нам сии случаи.

key

key=>value базы реляционны то тут я думаю и дураку понятно,

Хм. И что является доменом value? :)

value и есть отенциальное значение домена

И что это за домен? И кстати, какой домен у key?

key

Это просто прекрасно.

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

С чего бы? Каковы возможные выигрыши от возврата к нереляционным?

Насколько быстро грузовики смогут вытеснить трактора? И вытеснят ли когда вообще?

не любо не слухай, а врать не мешай.

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

Тоесть существует 2 причины как я понял:

1) Не существенная-перестройка понимания. 2)Существенная-негодноготь самой NoSQL выполнять ряд задач, которые умеют выполнять РСУБД.

Скорее всего второй пункт отражает суть почти на 100%.

С чего бы? Каковы возможные выигрыши от возврата к нереляционным?

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

Насколько известно-с производительностью вопрос очень спорный. Что касается распределенности-то это также неочевидно, потому как проблем с рапределенностью у NoSQL как раз поболее будет. К тому же на сложноструктурных задачах нереляционки уступают, или вообще неприменимы.

на сложноструктурных задачах нереляционки уступают, или вообще неприменимы

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

Скорее всего второй пункт отражает суть почти на 100%.

Он отражает на 100% неспособность перестроить мышление.
Когда-то заставляли перестраивать вышление на реляционные табицы и многие сопротивлялись.
Так-же и теперь :)

Как вы думаете, насколько быстро технологии NoSQL смогут вытеснить SQL решения? И вытеснят ли когда вообще?

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

Уважаемый друг))) «Перестройка мышления» в данном случае-понятие эфемерное, размазанное, обманчивое и неочевидное. Дело ведь в данном случае совсем не в перестройке мышения, а в конкретной технической применинимости/не применимости конкретного решения или технологий под конкретные задачи. Есть четкие и нечеткие заключения, основанные как на анализе возможностей технической структуры какого-либо решения, так и на опыте их применения(который кстати у NoSQL СУБД не намного меньше чем у РСУБД~30 лет), которые свидетельствуют, что далеко не под все задачи подходит и вообще не факт, что когда-либо подойдет NoSQL(дело в рамках и ограничениях в возможностях технологий). Также как и сравниванием ООП-Functions языков программирования. И «перестройка мышления» в данном случае непричем. Это просто очевидно.

Большинство корморативынх проектов не используют SQL DB напрямую а посредвством ОО прослойки которая в большинстве случаев прекрасно ложатся на NoSQL.

Это совершенно очевидно, что большая чаcть проблем в миграции на NoSQL это заскорузлое мышление и борьба ДБ-одминов за кусок хлеба.

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

Это да.
И место им в музее.

И место им в музее.

Очевидно, у тебя есть альтернатива концепции и коду, который совершенствовался десятилетиями? Не говоря уже про то, что сравнивать nosql с настоящей реляционной БД — это все равно что сравнивать текстовый файлик с rtf-документом.