nosql (программистское)

[avva]

(эта запись может быть интересна интернет-разработчикам и сочувствующим)

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

Частично это следствие изобретательного названия, т.е. взяли все, что не SQL и назвали NoSQL. Но все равно, даже учитывая это, действительно много разных систем стали популярными в последние несколько лет. Скажем, в начале 2000-х ничего такого не было.

Мне кажется, это объясняется сочетанием трех факторов. В порядке от менее к более важным:

1. Мода.

2. Та же причина, по которой собака лижет свои яйца. Написать какую-нибудь интересную псевдо-базу данных сейчас намного легче, чем скажем 15 лет назад. Компьютеры стали намного быстрее. Диски сильно быстрее не стали, зато памяти намного больше, и кэшировать данные в ней намного легче. То, что 15 лет назад нужно было писать на C, тщательно вымеривая размеры кэша, использование памяти, итд., сегодня - если речь не идет о миллионах клиентов - можно хоть на Питоне наваять. Хотя ваяют все же не на Питоне главным образом.

3. Удобство использования. Опенсорсная библиотека или база данных - а мы говорим именно об опенсорсе - живет постольку, поскольку может опереться на массу пользователей, на mindshare (бывают исключения, но они редки). 10 лет назад в веб-проектах любого рода пользоваться чем-то кроме MySQL или PostgreSQL было весьма затруднительно, потому что хостеры просто их не предоставляли. Помните таких людей, хостеров? Которые ставили сайты на одну и ту же машину, без виртуализации, и разрещали устанавливать на сервере только пакеты из заранее утвержденного списка? Которые соревновались друг с другом тем, какие версии PHP и Perl у них на серверах доступны, и из какой директории можно запускать CGI-скрипты?

В такой ситуации никакую MongoDB не установишь. А колокация своих собственных физических серверов стоила тогда больших денег. Понятно, что компании среднего и выше размеров это могли себе позволить и позволяли. Но вопрос-то в том, кто эту систему NoSQL будет пробовать на своих небольших проектах, кто доверит ей свой стартап из одного человека, кто будет писать о ней в блогах и на форумах. У всех этих людей не было выхода тогда: LAMP и гуляй смело. Хочешь что-то другое? Покупай свои сервера, плати кучу денег за их подключение к сети.

Поэтому главное, что привело к сегодняшней моде на NoSQL-системы в "публичном пространстве" - это, по-моему, развитие виртуализации, виртуализированного хостинга как следствия этого, а также падения цен на хостинг вообще. Сегодня каждый сам себе сисадмин благодаря Linode, Amazon EC2 и десяткам других подобных сервисов (а также сотням из "длинного хвоста"). Вне "публичного пространства" - например, внутри больших компаний, внутри Амазона, Майкрософта, Гугла - таких систем и раньше было много, подозреваю.

Comments

[xxqs.livejournal.com]

ну, BerkeleyDB существует и используется уже больше десятка лет. Я, например, использую её в проекте torrus.org с 2002 года. Когда надо несколько сотен тысяч объектов поднять из базы за пару минут, SQL просто не справится.

side node насчет MongoDB -- она принципипльно ни с какой архитектурой кроме x86 не совместима, и никто не смог убедить авторов, что они не правы.

[3doff.livejournal.com]

Что за "длинный хвост" в предпоследнем предложении? Не въехал.

[mudak.livejournal.com]

http://en.wikipedia.org/wiki/Long_Tail

[3doff.livejournal.com]

tanks

[xxqs.livejournal.com]

вот ещё любопытный вариант -- nosql база данных поверх Git: http://search.cpan.org/dist/Giddy/

[meshko.livejournal.com]

SQL не работает без DBA. Прогаммисты уже 30 лет мечтали о том, как бы от DBA избавиться. Вот, памяти стало много, избавляются потихоньку.

[egorfine.livejournal.com]

А мне кажется, важнейшая причина - это NIH+доступность реализации. В данном контексте NoSQL не отличается от функции обрезания лишних пробелов в строке и вполне успешно чешет вот то, что обычно болит при заболевании NIH. А потом наступает следующий этап: человек изобрел и внедрил свой quick-n-dirty KV store, а потом вдруг осознал: ба, да это же отдельный продукт. И пошла-пошла.

Даже я порой ловлю себя на мысли о том, как классно было бы написать простенький NoSQL на Node.js, ведь он там ну так же ж просится. Чисто эмоциональный порыв. Останавливает только то, что я не один: на Node.js уже нафигачили с десяток NoSQL'ей, один другого хуже. :-)

[olegs.livejournal.com]

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

хостинг - это не набор программ, а набор услуг. Облака, амазон, и пр. ничего не изменят. Захотят покупатели MongoDB - значит в CPanel добавят mongoDB.

сильное распространение mysql было связано с распространением php, на нем писали простые сайты и магазины. Коммерческий хостинг MS SQL сильно припозднился с выходом на рынок, он был сложен в настройке и дорог. Часто использовали ASP+MDB. mysql было просто настраивать, поддерживать, и продавать.

[tr1gger.livejournal.com]

Кроме моды есть и веская причина указанная главной фичей многих NoSQL баз, причём странно что ни автор, ни комментаторы даже не упомянули о ней: scalability.

Собственно эту моду задал гугловский Bigtable/GFS, выйдя на рынок с миллисекундным поиском. А до него пользовались "серьёзными" базами данных на мощных машинах. Не знаю насчёт M$, а в IBM, по слухам, до сих пор мэйнфреймы крутят и едут домой, когда те падают.

Последние полтора года наша команда из 11 человек занимается тем, что мигрирует один проект с SQL на NoSQL, так что можно сказать, мы собаку на этом съели.

[ygam.livejournal.com]

В Бинге есть свой аналог GFS/Map-Reduce: http://blogs.msdn.com/b/seliot/archive/2010/11/05/cosmos-petabytes-perfectly-processed-perfunctorily.aspx Это пишет менеджер тестеров из моей бывшей бригады.

[volk007.livejournal.com]

Рассвет NoSQL связан в первую очередь с тем, что SQL исключительно плохо подходит для веб приложений - нет ни scalability, ни redundancy, ни schema evolution. Все это достичь на MySQL весьма тяжело, любое веб-приложение с такими гарантиями является монстром с нетривиально законфигурированной базой данных, промежуточным уровнем для partitioning, memcached и т.д. Вот и получается, что проще на какой-нибудь Кассандре написать, что сильные духом и делают.

[cema.livejournal.com]

Это аналог InterSystems Caché.

[msh.livejournal.com]

Лет десять назад я работал над проектом, для которого хотели использовать небольшую базу, а SQL был не нужен. Так нашли с десяток кандидатов, оказалось есть такая ниша. Но тогда это была именно ниша.

Я думаю, что популярность в последнее время связана с "web 2.0". Есть такая шутка, что если за программистом хорошо не следить, то он вместо своей задачи обязательно напишет или новую ОС, или новый язык программирования. Но базы обычно не писали, потому что в проект их было не пропихнуть - к данным все относились с трепетом - разрешить вставить какой-нибудь уникальный скриптовый язык - это пожалуйста, но база должна быть настоящей.

Так вот в Web 2.0 обычно на данные всем плевать. Ну пропало сто комментов, тыща чекинов и все фоточки с котятами за день. Ну и ладно, в крайнем случае пост в блоге с извинениями.

[(Anonymous)]

With a database like SQLite you can load a couple of hundred thousand objects in a couple of seconds, not minutes. The same for the traditional client-server database systems such MySQL can be done in tens of seconds, not minutes. See, for example, this post:

http://www.codesynthesis.com/~boris/blog/2011/04/06/performance-odb-cxx-orm-vs-cs-orm/

[(Anonymous)]

Это точно. В 80х (70x?) годах задача была быстро данные наполнять (база данных - с каким же пиетитом тогда об этом говорили), а что потом - это неважно, отчеты можно и ночью сделать, а сейчас задача - как можно быстрее данные показать.

[meshko.livejournal.com]

Так вот в Web 2.0 обычно на данные всем плевать

о, да.

[rudnev.livejournal.com]

это стало пахнуть деньгами. у инвесторов одно связалось с другим: если интернет-стартап, то непременно чтоб милион пользователей и NoSql. а программисты и рады.

[migmit.livejournal.com]

Ох, где-то ж недавно видел статью, утверждавшую, что SQL и NoSQL — это на самом деле почти одно и то же. Поищу.

[lair.livejournal.com]

SQL исключительно плохо подходит для веб приложений - нет ни scalability, ни redundancy
Ась? То есть как - нет масштабируемости и отказоустойчивости?

Это смешно сейчас было, да.

[jerom.livejournal.com]

Ну во многих веб-проектах запрещают любые join и требуют только выборок по первичному ключу. Так что шаг был логичный.

А уж сколько проектов сделано на сохранении данных в миллионах маленьких файликов и не сосчитать.

[volk007.livejournal.com]

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

Отказаустойчивость в смысле гарантии сохранности подвержденных транзкций достигается вообще большой кровью, начиная с того, что нужно использовать кластер, RAID и т.д. И при это автоматичекий failover часто все равно не случается, потому что клиент криво написан или нагрузка от повторных запросов слишком высокая. И это у MsSQL и Oracle, настроить что бы это все заработало на MySQL вообще мало кому удается (и узнают об этом слишком поздно).

Не случайно серьезные люди отдельно от базы данных хранят журнал изменений, что бы потом можно было заново накатить (казалось бы, почему сразу так не написано, что бы этим не нужно было заниматься?). Например, вот: Database failure at JBMorgan Chase: corruption replicated to hot spare, restored from buckup, 874K transactions were reapplied.
http://www.dbms2.com/2010/09/17/jp-morgan-chase-oracle-database-outage/

[lair.livejournal.com]

Маштабируемость достигается либо покупкой более мощного сервера
Это вообще не масштабируемость.

или партицированием
...или разнесением write/read нагрузок, или полным дублированием. Вариантов-то есть.

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

И это у MsSQL и Oracle, настроить что бы это все заработало на MySQL вообще мало кому удается
Это уже не проблемы SQL как подхода, правда же? Собственно, все вышеописанное - тоже.

Не случайно серьезные люди отдельно от базы данных хранят журнал изменений, что бы потом можно было заново накатить
Омг. Это стандартная политика бэкапа для БД, что вас удивляет? Делать каждые 5 минут бэкап базы - невыносимо дорого, поэтому бэкапят базы (редко), диффы баз (чаще) и логи транзакций (часто). И в таком порядке и накатывают при сбое - сначала последний полный бэкап, потом дифы, потом логи, получая тем самым консистентную базу на последний возможный момент. Это не "серьезные люди", это любой нормальный DBA.

А у моргана проблема случилась в том, что оракл реплицировал ошибочные данные в hot spare, поэтому и фейловер умер. Это в любой системе может случится, и потребует восстановления из бэкапа. Аналогия: никакой массив не поможет от вируса, который гуляет и удаляет файлы, массив эти изменения будет честно реплицировать; чтобы восстановить данные, нужен бэкап.

Собственно, это лишний раз нам показывает, что hot spare помогает от аппаратно-программных сбоев, но не от потери данных.

[volk007.livejournal.com]

Ну понятно, что "логи транзакций (часто)" - не достаточно, все равно последние можно потерять, т.е. нужен "live backup", один из возможных вариантов - у них приложение все запросы пишет в отдельгный от DB лог, который они потом и переиграли.

"что вас удивляет?" В основном цена вопроса :)
Собстванно говоря, другими словами, Cassandra и други NoSQL пытаются решить сценарии, которые хотя и возможны, но слишком дороги в SQL, и пользуются ими не потому, что модно, а потому что на SQL дороже получается.

[os80.livejournal.com]

А что, слово "кот" стало более нецензурным, чем слово "яйца"?

[lair.livejournal.com]

Ну понятно, что "логи транзакций (часто)" - не достаточно, все равно последние можно потерять, т.е. нужен "live backup", один из возможных вариантов - у них приложение все запросы пишет в отдельгный от DB лог, который они потом и переиграли.
Вообще, в MS SQL (не знаю ничего про Oracle в этом вопросе) сама СУБД пишет транзакции в "отдельный от БД лог".

Live backup - не бывает. Это не бэкап, это реплика.

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

[oulenspiegel.livejournal.com]

По-моему, всё гораздо проще. Реляционные СУБД победили в своё время потому, что основной структурой для хранения данных в рамках бизнес-логики был массив. Реляционные БД в рамках не-объектного фреймворка очень удобны.
Но когда ООП стала потихоньку вытеснять старое, структурное программирование, возникла неприятность: объектная иерархия плохо мэппится в реляционную схему. В итоге появился костыль в виде ORM, который хотя и решал некоторые проблемы, но взамен создавал кучу новых. Каждый, кто всерьёз работал с Hibernate/NHibernate и т.п., хорошо это на своей шкуре прочувствовал. Поэтому, конечно, желание избавиться от ORM и породило определённое движение.
Лично я думаю, что за Scala и MongoDB будущее, но оно наступит ещё не скоро) Слишком велика инертность индустрии, зависящей от кадров, накопленного опыта и т.д.

[avva.livejournal.com]

Не понял, простите. При чем тут кот?

[os80.livejournal.com]

При том, что яйца лижут коты.

[herr-sgor.livejournal.com]

http://queue.acm.org/detail.cfm?id=1961297

[dimanium.livejournal.com]

Мне кажется очень важным упоминание термина "scalability" в комментариях. Движение NoSQL, имхо, выросло из того, что для достижения новых требований к приложениям (и одним из самых важных таких требований является горизонтальная масштабируемость) разные люди стали пытаться менять модель работы с данными, и из-за этого появилась концепция CAP, eventual consistency и много других новых понятий. Соответственно, это повлекло за собой изменение принципов разработки приложений, и поэтому часть движения декларирует отказ от SQL. На мой взгляд, это просто очень громкий и красивый слоган, и существующее NoSQL-движение скорее стоило бы назвать NoACID. Вот, а новых проектов так много появляется из-за того, что какого-то общепринятого подхода работы с данными "в новом стиле" ещё не сложилось, поэтому все делают что-то слегка своё.

Если вы не читали, рекомендую ознакомиться со статьями Майкла Стоунбрейкера на эту тему, он весьма интересно пишет. :) Например, http://cacm.acm.org/blogs/blog-cacm/50678-the-nosql-discussion-has-nothing-to-do-with-sql/fulltext (перевод этой и ещё некоторых любопытных статей по теме можно найти на http://citforum.ru/database/articles/index.shtml).

[avva.livejournal.com]

Спасибо, почитаю.

[migmit.livejournal.com]

Ага, она, родимая. Спасибо.

Two factors

[(Anonymous)]

ПЕРВОЕ
Представьте, что вы решили для охраны своего дома использовать собачку. Ротвейлеру, однако, надо кушать, его надо выводить "гулять", дрессировать, поскольку собаки сами по себе человека рвать не будут, нужна специальная выучка.

Еще хуже, если вы наняли охранное ведомство. Им надо платить много денег, оправдываться если вы забыли отключить сигнализацию и они прибыли "по ложному вызову". А что если "охранники" окажутся теми же грабителями, только на помесячной плате, и станут выдавливать из вас "за крышевание" и "ставить на счётчик"?

Те, кто занимается компьютерами очень часто забывают, что нигде нет "чистых технологий", и за ними всегда маячит "бизнес".
Я достаточно стар, чтобы помнить, какие поразительные заявления делала индустрия SQL о могуществе подхода ("таким образом все отношения мира можно выразить через операции реляционной алгебры" - я не преувеличиваю! Такая фраза у одного из "отцов" подхода впервые навела меня на мысль, что меня жулят)

Базы данных, выполняя необходимую функцию, одновременно превратились в монстра, который жрёт гораздо больше, чем приносит пользы. Коммерческие БД требуют сотен мегабайт только для установки, особо мощного hardware, специальных людей с мега-зарплатами для обслуживания.
При этом они дублируют операционную систему и раздаются без меры, становясь всё большей и большей bloatware. Одновременно выдумывая всё более спекулятивные способы взыскивать деньги и делать клиента беззащитными от них ("потеря" при переходе на другую систему, трудность или невозможность переносить данные и т.д.)

Поэтому уже два десятка лет видна тенденция не "виртуализации", а ИЗБАВЛЕНИЯ ОТ ЖАДНОГО УРОДА-СПЕКУЛЯНТА-МОШЕННИКА.

Сначала эту роль выполняли "народные" и маленькие/простые БД, вроде mSQL, MySQL и т.д. Последняя сама подросла и стала похожа на старших братьев, потому для массы народа - и в веб-проектах, и во внутрикомпанейских разработках, и для иных программ - всегда стоит вопрос "маленькой, быстрой и ДОСТАТОЧНО сильной базы". Зачем покупать за тысячи абсолютного чемпиона по подъёму тяжестей, если мне надо перенести доски до двора дачи, сколотить новый забор.



ВТОРОЕ
Термин NoSQL обманчив, т.к. this is an "umbrella term" означающий "всё остальное кроме Х".

Помимо уже упомянутых подгрупп втоде BerkeleyDB - TokyoCabinet (последний тоже уже маленько разросся), есть одно направление, которое если не перечеркивает, то сильно теснит Relational Databases ПО ЭФФЕКТИВНОСТИ.

Если выкинуть из головы вдолбленные годами штампы и посмотреть на то, к чему оптимизированы Relational Databases, то мы обнаружим, что они оптимальны:
(а) для добавления информации (writing)
(b) считывания полной строки из таблицы

Они очень плохо считывают частичную информацию.
Таким образом ПРАВИЛЬНАЯ оптимизация relational db заключается не в "нормализации таблиц", но в подгонке таблиц к форматам стандартных запросов так, что бы отдавались все колонки найденной строки.


Column-basedё DB's могут выполнять сложные запросы НА ПОРЯДОК быстрее, беря при том меньше памяти. Например, один из стандартных тестов с MySQL просто не смог выполниться в 1Гб памяти, тогда как a column-based db сделала его легко и очень быстро.

Поэтому еще один импульс для развития "NoSQL" технологий - попытка сделать те операции, которые стандартная модель делает очень плохо (выборка отдельных столбцов) или вообще сделать не может (так, в кучу NoSQL часто мешают разного рода системы, позволяющие выполнять map-reduce операции)



ИТАК, движет при создании NoSQL: (а) желание иметь простые и "достаточно" сильные системы вместо монстров, которые на 90% занимаются самопожиранием ресурсов и (б) попытки создать новые технологии, невозможные в Relational model или оптимизирующие её как не являющуюся лучшей всегда и везде.

[cema.livejournal.com]

InterSystems недавно выложил вариант Caché для свободного доступа, см. http://globalsdb.org/

$500 per day

[(Anonymous)]

If you have a desire to learn how to earn from $ 500 per day and work only for yourself, then write to us at email: admin@makemoneyonline.universalxyzdom.xyz

Hot sale! E-gift card amazon with a face value of $ 2000 for only $ 500.

[(Anonymous)]

Hot sale! E-gift card amazon with a face value of $ 2000 for only $ 500.
https://amazonegiftcardcheap.wordpress.com
The promotion will last until July 31, 2017. After July 31, the price will be $ 1000
https://amazonegiftcardcheap.wordpress.com

lista casino online italiani casino online ver casino 10 euros gratis sin deposito

[(Anonymous)]

http://hambre.sociedadnocturna.net/viewtopic.php?f=139&t=441098&p=528050#p528050
http://carnagetdm.com/forum/viewtopic.php?f=20&t=42277
http://imdbcommunity.com/community/viewtopic.php?f=20&t=270087
http://paniqo.org/viewtopic.php?f=88&t=85128
http://www.zdorovie-ok.ru/forum/viewtopic.php?f=23&t=6344
http://giantcapital.co/forum/viewtopic.php?f=7&t=93762
http://forum.menunedeli.ru/viewtopic.php?f=31&t=38368
http://tailexpert.neware.nl/support/viewtopic.php?f=6&t=7944
http://hookah-zone.com/forums/index.php?topic=393287.new#new
http://thelasthope.ru/index.php/forum/12-%D0%9D%D0%B0%D1%88-%D0%BF%D0%BE%D1%80%D1%82%D0%B0%D0%BB/31787-%D0%A0%D1%94%D0%A0%C2%B0%D0%A0%C2%B7%D0%A0%D1%91%D0%A0%D0%85%D0%A0%D1%95-%D0%A0%D1%95%D0%A0%D0%85%D0%A0%C2%BB%D0%A0%C2%B0%D0%A0%E2%84%96%D0%A0%D0%85-%D0%A0%C2%B0%D0%A0%D2%91%D0%A0%D1%98%D0%A0%D1%91%D0%A1%D0%82%D0%A0%C2%B0%D0%A0%C2%BB-start-online-casino-website-create-online-casino-website#31787
http://hdmi.guru/posting.php?mode=post&f=38
http://help.dominanta.vpoloni.com/viewtopic.php?f=2&t=39353
http://www.power-roleplay.com/forum/index.php?topic=251628.new#new
http://anarkys.com/forum/viewtopic.php?f=12&t=149617
http://www.travel.ipt.pw/News/bharatpur-bird-sanctuary/