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

[lair.livejournal.com]

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

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

[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 дороже получается.

[lair.livejournal.com]

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

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

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