nosql (программистское)
Jun. 3rd, 2011 11:30 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva(эта запись может быть интересна интернет-разработчикам и сочувствующим)
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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 и десяткам других подобных сервисов (а также сотням из "длинного хвоста"). Вне "публичного пространства" - например, внутри больших компаний, внутри Амазона, Майкрософта, Гугла - таких систем и раньше было много, подозреваю.
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 и десяткам других подобных сервисов (а также сотням из "длинного хвоста"). Вне "публичного пространства" - например, внутри больших компаний, внутри Амазона, Майкрософта, Гугла - таких систем и раньше было много, подозреваю.
Two factors
Date: 2011-06-05 09:32 am (UTC)Представьте, что вы решили для охраны своего дома использовать собачку. Ротвейлеру, однако, надо кушать, его надо выводить "гулять", дрессировать, поскольку собаки сами по себе человека рвать не будут, нужна специальная выучка.
Еще хуже, если вы наняли охранное ведомство. Им надо платить много денег, оправдываться если вы забыли отключить сигнализацию и они прибыли "по ложному вызову". А что если "охранники" окажутся теми же грабителями, только на помесячной плате, и станут выдавливать из вас "за крышевание" и "ставить на счётчик"?
Те, кто занимается компьютерами очень часто забывают, что нигде нет "чистых технологий", и за ними всегда маячит "бизнес".
Я достаточно стар, чтобы помнить, какие поразительные заявления делала индустрия 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 или оптимизирующие её как не являющуюся лучшей всегда и везде.