Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 130
Вот последнее предложение — в рамочку и на стенку… а то некоторые люди поддавшись маркетингу видят в NoSQL решение всех проблем.
P.S. Интересно было бы почитать про Hadoop в более развернутом виде — как вы её используете, how-to, примеры обсчета задач, организация кластера и т.п.
P.S. Интересно было бы почитать про Hadoop в более развернутом виде — как вы её используете, how-to, примеры обсчета задач, организация кластера и т.п.
Суть в том, что когда сталкиваешься с проблемой, решение которой нельзя нагуглить, хочется попробовать серебряную пулю, которую все так расхваливают. Ведь хочется верить, что всё будет просто и красиво. Такая вот последняя надежда:)
В качестве how to могу описать построение tf-idf и обратного индекса. Это будет скорее теоретический поисковый индекс, а не реальный, но должно быть показательно. Сойдёт? А вот с практической точки зрения: у нас он используется сейчас для всего: обсчёт логов, обработка данных, хранение.
Про организацию кластера есть хороший доклад с форума технологий mail.ru.
В качестве how to могу описать построение tf-idf и обратного индекса. Это будет скорее теоретический поисковый индекс, а не реальный, но должно быть показательно. Сойдёт? А вот с практической точки зрения: у нас он используется сейчас для всего: обсчёт логов, обработка данных, хранение.
Про организацию кластера есть хороший доклад с форума технологий mail.ru.
И все-таки большинство в индустрии видят в SQL решение всех проблем.
Потому что долгое время это было именно так: habrahabr.ru/post/153859/#comment_5239341
Те кто поддался маркетингу — это их проблема, раз смотрят на рекламу, но не думают головой. Какая цена им, если вместо решения проблем и шевеления мозгами (за что они собственно ЗП получают), они ведутся на поводу у рекламы, даже не попытавшись проанализировать предлагаемые инструменты?
Почему нужно 1000 разу подумать, прежде чем нанимать на работу пионеров, которые где-то слышали про то, что noSQL — это круто. Всегда.
То есть монго не выдерживал 3 миллиарда записей а мускул выдержал? Записи были в одной таблице\коллекции или в разных?
Вам просто не хватало оперативки для построения индексов?
Вам просто не хватало оперативки для построения индексов?
К сожалению монго мы тогда использовали в других целях, для индексации данных его всерьёз никто не рассматривал.
Когда я пришёл, уже было желание использовать либо cassandra, либо riak, либо hbase. Hbase почему-то до меня был признан медленным, так что выбор был небольшой. А потом уже, когда первое решение на cassandra было готово, мы использовали mongodb для фронтенда.
Когда я пришёл, уже было желание использовать либо cassandra, либо riak, либо hbase. Hbase почему-то до меня был признан медленным, так что выбор был небольшой. А потом уже, когда первое решение на cassandra было готово, мы использовали mongodb для фронтенда.
noSQL пока слишком молодая сфера. Абсолютно согласен с тем, что noSQL очень удобно и быстро для решения ряда конкретных задач, но когда нужно что-то универсальное, больше подходит SQL.
Можно еще так сказать: SQL может полностью заменить noSQL (собственно так мы и жили до появляения этого класса баз данных), но noSQL не может полностью заменить SQL.
Можно еще так сказать: SQL может полностью заменить noSQL (собственно так мы и жили до появляения этого класса баз данных), но noSQL не может полностью заменить SQL.
Последнее — золотые слова!
Полностью согласен. В статье не написал про еще одно важное преимущество sql — огромнейшее сообщество.
Можно еще так сказать: SQL может полностью заменить noSQL (собственно так мы и жили до появляения этого класса баз данных), но noSQL не может полностью заменить SQL.
Скажем так, а надо ли что бы noSQL (опять же, какой именно nosql, возьмем к примеру mongo...) давал столько же плюшек что и рсубд? Как по мне — нет, хотя не спорю, есть те, у кого не один десяток бизнес логику под оракл хранимыми пишет…
Скажем так, а надо ли что бы noSQL (опять же, какой именно nosql, возьмем к примеру mongo...) давал столько же плюшек что и рсубд? Как по мне — нет, хотя не спорю, есть те, у кого не один десяток бизнес логику под оракл хранимыми пишет…
noSQL как и SQL, имеют свои сильные и слабые стороны. Это просто инструменты, которыми надо уметь пользоваться. И никто не мешает в рамках одного проекта часть данных хранить в noSQL, а часть в SQL хранилищах.
Ко всем плюсам MySQL хочется добавить, что при грамотном подходе (используя плагин) с ней можно работать и как с NoSQL через интерфейс Memcashed.
>И тем не менее: из 6ти проектов на монго, можно было бы написать 3-4 на mysql и не париться. Я написал их на монго только >потому, что мне нравится монго.
Не парится с чем? Просто после 6ти проектов все еще не привычно было работать с другой концепцией работы с данными, джоинтов не хватало или были другие проблемы?
>Скрипя сердцем мы потестировали на наших задачах mysql и на 3 млрд записях он показал себя весьма неплохо.
Но количество записей это ведь еще не все. Есть ведь еще rps — количество одновременных запросов. Или в ваших проектах этот параметр не учитывается
Не парится с чем? Просто после 6ти проектов все еще не привычно было работать с другой концепцией работы с данными, джоинтов не хватало или были другие проблемы?
>Скрипя сердцем мы потестировали на наших задачах mysql и на 3 млрд записях он показал себя весьма неплохо.
Но количество записей это ведь еще не все. Есть ведь еще rps — количество одновременных запросов. Или в ваших проектах этот параметр не учитывается
>джоинтов не хватало
Вы осторожнее с такими опечатками, с новыми законами за ваш комментарий весь Хабр пострадать может! :)
Вы осторожнее с такими опечатками, с новыми законами за ваш комментарий весь Хабр пострадать может! :)
На первом проекте уже всё было хорошо, ущемлённым себя не чувствуешь:) На втором проекте была только парочка небольших открытий, но в целом всё было уже известно.
Я имел в виду, что mongodb — это всё-таки другая парадигма, а mysql и oracle для меня на тот момент были гораздо более известными субд, кроме того mysql уже был поставлен на серверах, куда я должен был поставить разработки. Еще там был инцидент: админы установили версию mongo 1.8 и при тестировании сервер заглючило и данные были потеряны… благо тестовые. Но версия > 2 уже почти не имеет такой неприятности:)
Вы правы, количество строк — это не всё. Там нужна была высокая скорость записи (~30-40 тыс. в секунду), с которой была проблема у mysql, а вот чтений было очень мало.
Я имел в виду, что mongodb — это всё-таки другая парадигма, а mysql и oracle для меня на тот момент были гораздо более известными субд, кроме того mysql уже был поставлен на серверах, куда я должен был поставить разработки. Еще там был инцидент: админы установили версию mongo 1.8 и при тестировании сервер заглючило и данные были потеряны… благо тестовые. Но версия > 2 уже почти не имеет такой неприятности:)
Вы правы, количество строк — это не всё. Там нужна была высокая скорость записи (~30-40 тыс. в секунду), с которой была проблема у mysql, а вот чтений было очень мало.
Но версия > 2 уже почти не имеет такой неприятности:)
У нее кстати другие неприятности, например иногда падать. Помню мне два или три человека (которые никак друг с другом не связаны, работают в разных компаниях и занимаются разными задачами) писали о том, что они держат не один, а два сервера монги, один инстанс упадет — другой есть, первый же быстренько подниметься
У нее кстати другие неприятности, например иногда падать. Помню мне два или три человека (которые никак друг с другом не связаны, работают в разных компаниях и занимаются разными задачами) писали о том, что они держат не один, а два сервера монги, один инстанс упадет — другой есть, первый же быстренько подниметься
Сталкивался в mongo с проблемой автозапуска после ребута. Скрипт в init.d нормальный, вручную если управлять — все работает (stop/start). В вот после ребута системы приходится ручками удалять постоянно mongo.lock. В нете ниче насчет этого норм не пишут. Обращаясь к автору поста, хотелось бы по-подробнее узнать что там настраивать нужно?
«Скрипя сердцем»
Киборги заполонили планету
Киборги заполонили планету
Как-то вы меня расстроили Riak'ом.
Я тоже был очень расстроен первым знакомством:( Еще задолго до того, как появилась возможность её опробовать, мне понравилась эта статья, я начал читать о ней и верил в эту бд. Кстати, мой коллега попытался прикособочить к этой системе leveldb в качестве движка хранения данных и счастья также не испытал…
Особенно внимательно надо изучать, как база работает в случае реплицирования в соседний ДЦ (конечно, если необходима высокая доступность). Hadoop/HBase, например, не работает :) У бесплатного Riak такая же фигня с неймнодой. Кассандра умеет, но иногда она теряет данные при падении нод (впрочем, как и монга), но у неё другая большая проблема: практически никто не умеет её администрировать. Из-за этого её перестали использовать в Фейсбуке. Монга не особо хорошо умеет переваривать миллиарды записей (коллеги жаловались на тормоза уже после 400млн ключей).
Честно говоря на тот момент не сталкивался с необходимостью реплицирования по ДЦ, хотя было бы здорово, конечно.
Про то, почему её перестали использовать в фейсбуке — всегда было любопытно:)) взяли и отказались от своего же детища…
Про то, почему её перестали использовать в фейсбуке — всегда было любопытно:)) взяли и отказались от своего же детища…
У них кассандра использовалась для служебных нужд, пользователям оттуда данные не отдавались. В других местах они начала использовать hbase, тоже для внутреннего использования. В какой-то момент кластер с кассандрой поломался, и оказалось, что людей, которые умеют её готовить, в компании не осталось, уволились. А новые потыкались и поняли, что проще перелить данные в hbase, чем пытаться победить кассандру.
Вообще, это обычная история: свой велосипед оказался объективно хуже соседского, вот свой и выкинули.
Вообще, это обычная история: свой велосипед оказался объективно хуже соседского, вот свой и выкинули.
Кстати да, вспомнил, была и потеря данных в кластере cassandra… тогда на одной ноде закончилось место на диске, насколько я помню… Но было печально, конечно
>Монга не особо хорошо умеет переваривать миллиарды записей (коллеги жаловались на тормоза уже после 400млн ключей).
так шардинг вроде это решает.
так шардинг вроде это решает.
Даже стало интересно, что умеет нормально переваривать миллиарды записей
Потому что надо 1000 раз подумать, прежде чем вообще делать что либо.
Надо сказать, что реальные данные изменили картину и одну из задач с mysql решить так и не вышло. То есть совсем.
Расскажите что была за задача, интересно ;)
Sql писал не я, так что точно ответить не смогу, но помнится проблема там была в том, что на одном из этапов запроса до отсечения из базы тянулись около 1 млн записей, что и тормозило весь запрос, а контролировать это не получалось.
Задача по памяти выглядела как-то так: нужно выбрать из базы строки по ~200 правилам, при этом по каждому правилу надо было выбрать диапазон ключей этого правила с отсечением по лимиту
Задача по памяти выглядела как-то так: нужно выбрать из базы строки по ~200 правилам, при этом по каждому правилу надо было выбрать диапазон ключей этого правила с отсечением по лимиту
А почему нужно тысячу раз подумать, прежде чем использовать NoSQL?
А самое главное — как прийти к тому, что вот уже НАДО использовать? И что использовать в этом случае?
Читая статью, кажется, что искали серебряную пулю, а находили пули из другого, более мягкого материала, в результате чего пришли к выводу, что NoSQL не нужно совсем.
А самое главное — как прийти к тому, что вот уже НАДО использовать? И что использовать в этом случае?
Читая статью, кажется, что искали серебряную пулю, а находили пули из другого, более мягкого материала, в результате чего пришли к выводу, что NoSQL не нужно совсем.
Золота?
Хм, я надеялся ответить на этот вопрос статьёй… попробую ответить здесь и дополню статью.
Подумать надо прежде всего потому, что серебряной пули не будет. И как бы ни был понятен мануал к базе данных, количество сюрпризов от этого не уменьшится. Текущие nosql решения — молодые и от того не лишённые недостатков инструменты. Тем не менее некоторые из них вполне готовы к production использованию, например: mongodb, cassandra, redis, hbase.
А вот придти к ответу на вопрос «что использовать» и в каком случае -, на мой взгляд, нужно самому. Путём тестирования и исследования решений конкретной задачи.
Подумать надо прежде всего потому, что серебряной пули не будет. И как бы ни был понятен мануал к базе данных, количество сюрпризов от этого не уменьшится. Текущие nosql решения — молодые и от того не лишённые недостатков инструменты. Тем не менее некоторые из них вполне готовы к production использованию, например: mongodb, cassandra, redis, hbase.
А вот придти к ответу на вопрос «что использовать» и в каком случае -, на мой взгляд, нужно самому. Путём тестирования и исследования решений конкретной задачи.
Мой пример: социальные, мобильные и другие синглплеер игры, где необходимо отдать большую часть профиля игрока (домики, грядки, ачивки, квесты...).
То есть нам (в случае sql) необходимо сделать либо один запрос со множеством джойнов, либо несколько запросов и уже в коде объединять это все. Изменение-сохранение состояния, которое затрагивает множество объектов (построил дом — выполнил квест — получил награду и ачивку за выполнение 10 квестов) должно происходить атомарно. То есть
Как пришел: достаточно долгий путь борьмы с sql, схемой — иногда проще добавить еще один внешний ключ и выбирать по нему, сортируя все в коде, нежели отдавать эту роль базе данных. Сценарием использования: множество запросов или один но с множеством ждойнов, количеством бойлерплейт-кода и производительностью.
Постепенно начал задавася вопросом — а так ли необходимо хранить данные в десятке разных мест, ведь единственное преимущество такого хранения — централизованное изменение съемы.
Производительность с каждой неделей устраивала все меньше и меньше — счет пользователей идет на десятки тысяч, а данных в бд, строк в некоторых таблицах — на миллионы (и плевать по сути, что таблица представляет из себя три инта). Масштабирование sql — дело не из самых приятных. Появление в некоторых, особо «удачных» местах blob-ов спасало, но осадочек то оставался…
На чем остановился: mongodb, который немножко использовал сам, видел как используется в продакшне. В теории отлично подходил под наши требования: одна коллекция на все данные пользователя, атомарность чтения-записи, да и мы были в курсе, что если что можем потерять допустим некоторые последние изменения, то и ладно, главное что профиль цел и ничего дальше не поломается. Единственное что планировалось оставить на sql — логи, огромнейшее количество данных, которое невероятно важно для понимания что сейчас происходит в игре. Нет, конечно можно было и в монге их писать, но не думаю что mongo+sql так уж лучше чем postres + sql.
На практике же, когда эйфория прошла, реальность раставила все по своим местам — без разочарований, косяков, понимании того, что теперь некоторые вещи так просто и не сделаешь… естественно не обошлось. Но понимание того, что теперь можно не тратить время на то, что бы подумать как бы это все хранить, да так, что бы бд не загнулась, а просто писать код (сохраняя его в удобной форме для приложения, соответсвено) — вселяло чувство что путь мы выбрали правильный.
И на последок: Если при использовании рсубд мы очень не хотим что бы на наших замечательных графиках использование дисков базой ушло за сотню, то при использовании nosql решений в целом, а уж тем более монги в частности, нам необходимо смотреть на график памяти, потому что если ее не хватит, всем будет… нет, не маленький пушной зверек, но что-то очень близкое.
Разработчики монги решили, что если кончилась память, то лучше не упасть, а продолжать писать все на диск. В итоге падение производительности в несколько сотен раз, что в разы хуже любой рсубд и любой самописной тулзой. По ощущениям — монго откровенно намекает на то, что ей очень и очень плохо и просит вас придти к ней на помощь.
То есть нам (в случае sql) необходимо сделать либо один запрос со множеством джойнов, либо несколько запросов и уже в коде объединять это все. Изменение-сохранение состояния, которое затрагивает множество объектов (построил дом — выполнил квест — получил награду и ачивку за выполнение 10 квестов) должно происходить атомарно. То есть
Как пришел: достаточно долгий путь борьмы с sql, схемой — иногда проще добавить еще один внешний ключ и выбирать по нему, сортируя все в коде, нежели отдавать эту роль базе данных. Сценарием использования: множество запросов или один но с множеством ждойнов, количеством бойлерплейт-кода и производительностью.
Постепенно начал задавася вопросом — а так ли необходимо хранить данные в десятке разных мест, ведь единственное преимущество такого хранения — централизованное изменение съемы.
Производительность с каждой неделей устраивала все меньше и меньше — счет пользователей идет на десятки тысяч, а данных в бд, строк в некоторых таблицах — на миллионы (и плевать по сути, что таблица представляет из себя три инта). Масштабирование sql — дело не из самых приятных. Появление в некоторых, особо «удачных» местах blob-ов спасало, но осадочек то оставался…
На чем остановился: mongodb, который немножко использовал сам, видел как используется в продакшне. В теории отлично подходил под наши требования: одна коллекция на все данные пользователя, атомарность чтения-записи, да и мы были в курсе, что если что можем потерять допустим некоторые последние изменения, то и ладно, главное что профиль цел и ничего дальше не поломается. Единственное что планировалось оставить на sql — логи, огромнейшее количество данных, которое невероятно важно для понимания что сейчас происходит в игре. Нет, конечно можно было и в монге их писать, но не думаю что mongo+sql так уж лучше чем postres + sql.
На практике же, когда эйфория прошла, реальность раставила все по своим местам — без разочарований, косяков, понимании того, что теперь некоторые вещи так просто и не сделаешь… естественно не обошлось. Но понимание того, что теперь можно не тратить время на то, что бы подумать как бы это все хранить, да так, что бы бд не загнулась, а просто писать код (сохраняя его в удобной форме для приложения, соответсвено) — вселяло чувство что путь мы выбрали правильный.
И на последок: Если при использовании рсубд мы очень не хотим что бы на наших замечательных графиках использование дисков базой ушло за сотню, то при использовании nosql решений в целом, а уж тем более монги в частности, нам необходимо смотреть на график памяти, потому что если ее не хватит, всем будет… нет, не маленький пушной зверек, но что-то очень близкое.
Разработчики монги решили, что если кончилась память, то лучше не упасть, а продолжать писать все на диск. В итоге падение производительности в несколько сотен раз, что в разы хуже любой рсубд и любой самописной тулзой. По ощущениям — монго откровенно намекает на то, что ей очень и очень плохо и просит вас придти к ней на помощь.
Спасибо, примеры из жизни — лучше всего.
То есть вам MongoDB подошла, несмотря на объективные минусы?
А то я, прежде чем попробовать что-то новое, всегда ищу тесты и накручиваю себя до фанатизма, а после знакомства разочарование всегда очень сильно бьёт, как это было с Python/Django. Так же будет и с MongoDB — сейчас мне уже кажется, что это хранилище можно использовать везде. Эх.
То есть вам MongoDB подошла, несмотря на объективные минусы?
А то я, прежде чем попробовать что-то новое, всегда ищу тесты и накручиваю себя до фанатизма, а после знакомства разочарование всегда очень сильно бьёт, как это было с Python/Django. Так же будет и с MongoDB — сейчас мне уже кажется, что это хранилище можно использовать везде. Эх.
А что разочаровало в Python, если не тайна?
Про использование везде — осторожнее, общение с деньгами я бы пока mongo не доверил…
Про использование везде — осторожнее, общение с деньгами я бы пока mongo не доверил…
Относительно невысокая скорость работы) Читая завлекаловки типа использования Python NASA и для математических расчётов, хотелось, чтобы приложения, написанные на этом языке, работали намного быстрее.
То есть… Быстро написать — это здорово, но если это быстронаписанное не будет быстро работать, то в чём тогда смысл? А если под это быстронаписанное, но медленно работающее, ставить кеширующие сервера типа Varnish, то есть ли смысл тогда менять PHP на Django, если там тоже можно поставить что-то хорошее к уже имеющимся акселераторам?
Впрочем, знакомство с Django я только-только начал, возможно, всё выправится…
Насчёт вашего замечания о том, что работу с деньгами пока доверять монго не стоит — да, понятно почему, да и в других статьях тоже пишут, что не стоит полностью отказываться от РСУБД, используя NoSQL-решения.
То есть… Быстро написать — это здорово, но если это быстронаписанное не будет быстро работать, то в чём тогда смысл? А если под это быстронаписанное, но медленно работающее, ставить кеширующие сервера типа Varnish, то есть ли смысл тогда менять PHP на Django, если там тоже можно поставить что-то хорошее к уже имеющимся акселераторам?
Впрочем, знакомство с Django я только-только начал, возможно, всё выправится…
Насчёт вашего замечания о том, что работу с деньгами пока доверять монго не стоит — да, понятно почему, да и в других статьях тоже пишут, что не стоит полностью отказываться от РСУБД, используя NoSQL-решения.
Деньги это такая чтука, что лишним перестраховатся не будет, у нас деньги писались и в монгу и в постгрес, к сожалению миллиардов платежей у нас не было, что бы проверить надежность монги. но за те тысячи вроде монго и не потеряла
Неужели так заметна просадка? Честно говоря не смотрел на скорость, надо будет обратить внимание… Для меня python — это прежде всего удобный и красивый язык.
Простите за злостный оффтоп в вашей теме!
Да, он очень красив и удобен, но — мой сдвиг — от него ожидалось ВСЁ, в том числе и очень высокая скорость работы. Пока что я только знакомлюсь с ним, но 32 rps на встроенном веб-сервере для относительно простых страниц с одним простым запросом к БД, сгенерировать которые на PHP займёт не больше 7-10 мс, мне не нравится…
Да, он очень красив и удобен, но — мой сдвиг — от него ожидалось ВСЁ, в том числе и очень высокая скорость работы. Пока что я только знакомлюсь с ним, но 32 rps на встроенном веб-сервере для относительно простых страниц с одним простым запросом к БД, сгенерировать которые на PHP займёт не больше 7-10 мс, мне не нравится…
Tornado может быстрее чем 7-10. Хотя, тут конечно вопрос в железе, для начала нужно уточнить.
Встроенный сервер он только для отладки. Попробуйте gunicorn. Не забывайте статику отдавать nginx или lighttpd. Отключите режим отладки в настройках
Так вы производительность тестировали в режиме отладки на встроенном отладочном сервере? Это даже не смешно. Попробуйте, как выше писали gunicorn… Ну или nginx+uwsgi.
Вы никогда не думали, что вы плохо выбираете инструменты? (=
Начну с Python:
* он быстрее PHP (сравнение интерпретаторов и синтетические тесты) — как вы понимаете, реальная скорость приложения зависит от показателя прямых рук архитектора и разработчиков, а также знания инструментов;
* математические числодробительные алгоритмы на Python — это не миф: numpy.scipy.org/ www.scipy.org/
* Django — может быть очень быстрым, но он не для этого задуман. Популярность веб-фреймворков на Python или Ruby обусловленны не феноменальной скоростью работы. Для веб-приложений в первую очередь важна скорость разработки, так как веб-приложения должны быть очень гибкими и могут очень быстро меняться под изменяющиеся требования рынка, нагрузок, положения Луны на небе и т.д. При этом подразумевается, что для написания такого веб-приложения требуется меньше высококвалифицированных гуру, которые могут быть дорогими, но дадут отличное решение, и много железа для масштабирования, так как железо дешевле зарплаты этих самых гуру. Ну и конечно, если вы начали писать приложение на Django к примеру, или Rails, это вовсе не избавляет вас от проблем, что вам надо думать о том, какая архитектура будет у приложения, как хранить данные, как кешировать и многие другие. Эти фреймворки дают инструменты для быстрого решения ежедневных проблем, и пытаются автоматизировать там, где они могут это делать. Остальное на вашей совести как и везде.
Так что ваше утверждение вообще странно и размыто. Может быть вы просто запустили development http-сервер на локальной машине, который предназначен для тестирования, посмотрели, потрогали и решили — медленно.
Что касается MongoDB. Вы не пытались покопаться в документации? Я понимаю, что на каждом углу любители Node.JS кричат о крутости монги (так как собственно по большому счету они ни с чем другим работать не умеют и это априори DB на этой хипстерской платформе). Я нисколько не умоляю заслуг монги. Это великолепная база, и она великолепно решает проблемы, для которых предназначена и есть весьма мощные success story от ее использования.
Но я бы наткнувшись на новый инструмент, особенно NoSQL, подумал бы, зачем разработчики ее создали вообще? Это такой намек на: www.mongodb.org/display/DOCS/Philosophy и www.mongodb.org/display/DOCS/Use+Cases
По второй ссылке очень примечательно www.mongodb.org/display/DOCS/Use+Cases#UseCases-WhenshouldyouconsiderusingMongoDB%3F и www.mongodb.org/display/DOCS/Use+Cases#UseCases-Whenshouldyouusesomethingelse%3F
То есть к примеру, даже сами разработчики говорят: если ваша проблема решается SQL-базами, или у вас приложение в e-commerce (не поддерживаются транзакции) — не используйте MongoDB. (=
В итоге я бы сказал, что MongoDB и вообще NoSQL — это Not Only SQL — это *дополнение* к SQL.
Начну с Python:
* он быстрее PHP (сравнение интерпретаторов и синтетические тесты) — как вы понимаете, реальная скорость приложения зависит от показателя прямых рук архитектора и разработчиков, а также знания инструментов;
* математические числодробительные алгоритмы на Python — это не миф: numpy.scipy.org/ www.scipy.org/
* Django — может быть очень быстрым, но он не для этого задуман. Популярность веб-фреймворков на Python или Ruby обусловленны не феноменальной скоростью работы. Для веб-приложений в первую очередь важна скорость разработки, так как веб-приложения должны быть очень гибкими и могут очень быстро меняться под изменяющиеся требования рынка, нагрузок, положения Луны на небе и т.д. При этом подразумевается, что для написания такого веб-приложения требуется меньше высококвалифицированных гуру, которые могут быть дорогими, но дадут отличное решение, и много железа для масштабирования, так как железо дешевле зарплаты этих самых гуру. Ну и конечно, если вы начали писать приложение на Django к примеру, или Rails, это вовсе не избавляет вас от проблем, что вам надо думать о том, какая архитектура будет у приложения, как хранить данные, как кешировать и многие другие. Эти фреймворки дают инструменты для быстрого решения ежедневных проблем, и пытаются автоматизировать там, где они могут это делать. Остальное на вашей совести как и везде.
Так что ваше утверждение вообще странно и размыто. Может быть вы просто запустили development http-сервер на локальной машине, который предназначен для тестирования, посмотрели, потрогали и решили — медленно.
Что касается MongoDB. Вы не пытались покопаться в документации? Я понимаю, что на каждом углу любители Node.JS кричат о крутости монги (так как собственно по большому счету они ни с чем другим работать не умеют и это априори DB на этой хипстерской платформе). Я нисколько не умоляю заслуг монги. Это великолепная база, и она великолепно решает проблемы, для которых предназначена и есть весьма мощные success story от ее использования.
Но я бы наткнувшись на новый инструмент, особенно NoSQL, подумал бы, зачем разработчики ее создали вообще? Это такой намек на: www.mongodb.org/display/DOCS/Philosophy и www.mongodb.org/display/DOCS/Use+Cases
По второй ссылке очень примечательно www.mongodb.org/display/DOCS/Use+Cases#UseCases-WhenshouldyouconsiderusingMongoDB%3F и www.mongodb.org/display/DOCS/Use+Cases#UseCases-Whenshouldyouusesomethingelse%3F
То есть к примеру, даже сами разработчики говорят: если ваша проблема решается SQL-базами, или у вас приложение в e-commerce (не поддерживаются транзакции) — не используйте MongoDB. (=
В итоге я бы сказал, что MongoDB и вообще NoSQL — это Not Only SQL — это *дополнение* к SQL.
Python быстрее PHP или PHP+APC?
Я же написал:
> сравнение интерпретаторов и синтетические тесты
Имел ввиду PHP, но думаю он итак будет быстрее. Особенно, если сравнивать PyPy и PHP+APC. Но сути в этом утверждении для нашего вопроса, не больше чем пользы от баяна для козы. Сравнивать скорость интерпретатора бесполезно в вакуумных условиях, а в плане конкретных приложений — тут во многом зависит от качества реализации приложения, а не скорости интерпретатора. Так что можете шибко не цепляться к этой моей фразе.
> сравнение интерпретаторов и синтетические тесты
Имел ввиду PHP, но думаю он итак будет быстрее. Особенно, если сравнивать PyPy и PHP+APC. Но сути в этом утверждении для нашего вопроса, не больше чем пользы от баяна для козы. Сравнивать скорость интерпретатора бесполезно в вакуумных условиях, а в плане конкретных приложений — тут во многом зависит от качества реализации приложения, а не скорости интерпретатора. Так что можете шибко не цепляться к этой моей фразе.
Так по сути минусов (не сказал что бы таких уж и больших) у нее, для нас было два — можно немного потерять данных еще и в бд (до этого этим страдал наш игровой сервер).
Второе — так как часто приходилось менять структуру бд (эх, геймдизайнеры), а в монге это затруднительно, то приходилось писать ручками скрипты миграции… бррр. Но, мне и так приходилось их писать, потому как иногда изменения были достаточно существенные.
В случае постгреса игра вставала на несколько часов (к примеру в понедельник в пять утра) и я запускал ручками sql бэкапил правил, заливал обратно. С монгой в этом плане было по-другому: игрок заходил в игру и его профиль мигрировался: т.е. загружаем данные в старую структуру, перекидываем в новую… играем играем, сохраняем + в фоне за пару дней (искусственно ограничивали скорость) перекидывались все остальныые профили.
Остальное сейчас уже не припомню — большинство проблем решал все таки наш администратор, за что ему огромное спасибо (ненавижу администрирование… и проблемы).
Мне еще расказывали что есть некоторе неприятности при шардинге и огромном количестве записей в одной коллекции, да и можем банально упереться в максимальный размер одной записи, но мы до этих проблем так и не дожили.
Но зная какой ад меня ждал бы при масштабирование бд на sql-е… я, да и люди, которые столкнулись с этой проблемой на два-три месяца раньше меня, за монгу готовы были убить :)
Второе — так как часто приходилось менять структуру бд (эх, геймдизайнеры), а в монге это затруднительно, то приходилось писать ручками скрипты миграции… бррр. Но, мне и так приходилось их писать, потому как иногда изменения были достаточно существенные.
В случае постгреса игра вставала на несколько часов (к примеру в понедельник в пять утра) и я запускал ручками sql бэкапил правил, заливал обратно. С монгой в этом плане было по-другому: игрок заходил в игру и его профиль мигрировался: т.е. загружаем данные в старую структуру, перекидываем в новую… играем играем, сохраняем + в фоне за пару дней (искусственно ограничивали скорость) перекидывались все остальныые профили.
Остальное сейчас уже не припомню — большинство проблем решал все таки наш администратор, за что ему огромное спасибо (ненавижу администрирование… и проблемы).
Мне еще расказывали что есть некоторе неприятности при шардинге и огромном количестве записей в одной коллекции, да и можем банально упереться в максимальный размер одной записи, но мы до этих проблем так и не дожили.
Но зная какой ад меня ждал бы при масштабирование бд на sql-е… я, да и люди, которые столкнулись с этой проблемой на два-три месяца раньше меня, за монгу готовы были убить :)
К примеру, я тоже тепло отношусь к Mongo. Первое впечатление субд производит потрясающее, особенно возможностями по репликации и шардингу из коробки. Но при более близких и длительных отношениях случаются проблемы. Например, гонки в условиях отсутствия транзакций. Приходится вручную городить двухфазные коммиты и дополнительные условия в запросах. И всё начинает выглядеть не так прекрасно и просто, как поначалу. А ещё в ней есть трудности с моделированием структуры данных. Этот процесс мне показался более сложным, чем классическая реляционная нормализация/денормализация. Грубо говоря, формат хранения данных сильно зависит от запросов над ними. И если со временем появляются несовместимые со структурой запросы, начинается кошмар. Так что для хранения данных типа «база разношёрстных объектов с пересекающимися типами свойств и гибким поиском» — да, я выберу Mongo. Но для хранения гибкой модели из взаимодействующих сущностей — только рсубд.
Какая-то складывается закономерная картина. Появляется некая супер технология X, которая пиарится где только можно, расхваливается, синтетические заточенные тесты показывают как минимум в трое большую производительность и т.д. Потом разработчики начинают во всем этом деле крутится и вдруг понимают (да как это так!) что не бывает чуда. Что если оно в 3 раза быстрее то значит не святым духом оно ускоряется, что есть и минусы с которыми надо или мириться или выбирать более подходящий инструмент. Надо просто научится ВЫБИРАТЬ НАИБОЛЕЕ ПОДХОДЯЩИЙ ИНСТРУМЕНТ
А как выбрать-то не тестируя?
Ну появилась новая технология-Х, никтож толком-то не знаеткак она… вот и появляется куча статей «как я писал на новой Х, мега вконтактик с шахматами и поэтессами»…
А потом появится куча статей в стиле «Х — говоно или золото?», «Х — то о чем я мечтал всю жизнь», «Х — однозначно говно» и т.д.
Куда же без этого?
А разработчики тестируют это, пробуют и потом по результатам уже набитых шишек как раз и выбирают наболее подходящий инструмент…
P.S. Хотя да, фанатики они всегда есть, и суют без разбору предмет своего обожания куда ни попадя…
Ну появилась новая технология-Х, никтож толком-то не знаеткак она… вот и появляется куча статей «как я писал на новой Х, мега вконтактик с шахматами и поэтессами»…
А потом появится куча статей в стиле «Х — говоно или золото?», «Х — то о чем я мечтал всю жизнь», «Х — однозначно говно» и т.д.
Куда же без этого?
А разработчики тестируют это, пробуют и потом по результатам уже набитых шишек как раз и выбирают наболее подходящий инструмент…
P.S. Хотя да, фанатики они всегда есть, и суют без разбору предмет своего обожания куда ни попадя…
К сожалению, реляционные базы данных давно уже стали тем самым «наиболее подходящим инструментом». Теперь даже для того, что бы просто хранить несколько десятков записей мы используем mysql/postgres и учим sql, хотя нам нужно SELECT * FROM entries where id = ?.
Но, благодаря тому, что интернет растет и развивается горадо быстрее нежели производительность рсубд, поставила этот спам на свое законное место… тоесть, к сожалению, еще пока нет, но я надеюсь в будущем все сложеться именно так.
К примеру сейчас в любом языке (в стандарной библиотеки) есть api для доступа ко всем популярным рсубд, но нет ни одного языка, где опять же, в стандартной библиотеки, есть api для доступа к любой из всех популярных nosql. Да и преподают у нас в учебных заведениях и теорию баз данных, где на первой лекции мы окунаемся в историю, на второй пробегаемся по зоопарку бд, и еще 20 лекций нам расхваливают как хорошо хранить данные в кортежах отношений (или как там это правильно зовется), мы много узнаем о том, что данные нужно не просто хранить, а нормализировать. Все 10 лабараторных — это конечно же работа с sql от microsoft.
Поэтому многие даже не знают из чег оможно выбирать.
Поэтому многие привыкли что данные хранятся именно так и никак иначе. Вот и требуют от nosql (опять же, nosql разный бывает: redis и mongo — это два совершенно разных подхода к хранению данных), чего-то невозможного.
Но, благодаря тому, что интернет растет и развивается горадо быстрее нежели производительность рсубд, поставила этот спам на свое законное место… тоесть, к сожалению, еще пока нет, но я надеюсь в будущем все сложеться именно так.
К примеру сейчас в любом языке (в стандарной библиотеки) есть api для доступа ко всем популярным рсубд, но нет ни одного языка, где опять же, в стандартной библиотеки, есть api для доступа к любой из всех популярных nosql. Да и преподают у нас в учебных заведениях и теорию баз данных, где на первой лекции мы окунаемся в историю, на второй пробегаемся по зоопарку бд, и еще 20 лекций нам расхваливают как хорошо хранить данные в кортежах отношений (или как там это правильно зовется), мы много узнаем о том, что данные нужно не просто хранить, а нормализировать. Все 10 лабараторных — это конечно же работа с sql от microsoft.
Поэтому многие даже не знают из чег оможно выбирать.
Поэтому многие привыкли что данные хранятся именно так и никак иначе. Вот и требуют от nosql (опять же, nosql разный бывает: redis и mongo — это два совершенно разных подхода к хранению данных), чего-то невозможного.
Как уже правильно заметили — правильный инструмент под конкретную задачу будет работать всегда лучше, чем неправильный. Но это на уровне КЭПа. От статьи хотелось бы побольше конкретики: более точные цифры о количестве и роде данных. А то, знаете, миллиард key-value записей и миллиард записей по 100 полей это две большие разницы…
Опять же, что вы будете делать с вашей RDB на миллиард записей, когда (внезапно!) понадобиться расширить схему данных? А если для проекта намного важнее бОльшая скорость вставки, чем вероятность потерять какую-то небольшую часть данных?
Это риторические вопросы, намекающие на плюсы и минусы двух подходов — вот это было бы интереснее.
имхо, конечно.
Опять же, что вы будете делать с вашей RDB на миллиард записей, когда (внезапно!) понадобиться расширить схему данных? А если для проекта намного важнее бОльшая скорость вставки, чем вероятность потерять какую-то небольшую часть данных?
Это риторические вопросы, намекающие на плюсы и минусы двух подходов — вот это было бы интереснее.
имхо, конечно.
Опять же, к выбору правильного инструмента. Я хочу сказать что в споре sql vs nosql у нас не два подхода. У нас их четыре, или даже пять (я уже не помню какая бд к каким относится), но casandra vs mongo vs redis vs mysql vs mysql + hs — это все разные вещи по архитектуре, у которых по разному с возможностями, которые разные по принципам работы с ними.
Многие выбирают какой-либо nosql инструмент только потому, что так делают другие (о, ребята из xxx используют yyy, круто, наверное и мне надо), даже не задумываясь о том, что бы посмотреть что либо еще. Либо задумываясь, но понимая что это — то еще болото, где никто ничего толком не знает, каждый тянет на себя одеяло и выбрать придется что-то одно…
Многие выбирают какой-либо nosql инструмент только потому, что так делают другие (о, ребята из xxx используют yyy, круто, наверное и мне надо), даже не задумываясь о том, что бы посмотреть что либо еще. Либо задумываясь, но понимая что это — то еще болото, где никто ничего толком не знает, каждый тянет на себя одеяло и выбрать придется что-то одно…
Мм, ну к примеру, ежедневно используя Трелло (который работает офигенно :) ), я заранее прекрасно отношусь к редису и монге (равно как и к node.js), хотя сам их не щупал, и уверен, что они хорошо подходят для подобного веб-приложения.
А вообще, мне кажется, будущее за сервисами типа Cloudant — потому что никто не любит администрировать базу, все любят писать код.
А вообще, мне кажется, будущее за сервисами типа Cloudant — потому что никто не любит администрировать базу, все любят писать код.
Проблема в том, что решалось несколько задач, поэтому и сеты данных были разные. Их описание не получилось бы маленьким, могло бы запутать читателя лишней информацией. Хотя я согласен, что конкретики не хватает.
Вот насчёт schemaless и скорости вставки — по идее эти 2 преимущества многих nosql решений должны быть уже известны читателю из других статей про nosql. Но я могу дополнить статью, надо подумать как бы это оформить.
Вот насчёт schemaless и скорости вставки — по идее эти 2 преимущества многих nosql решений должны быть уже известны читателю из других статей про nosql. Но я могу дополнить статью, надо подумать как бы это оформить.
> понимание людьми сути nosql и того, почему выбирать эту технологию
Как вы верно написали дальше, это термин, а не *технология*. Да, я понимаю, что со словом *технология* всё звучит круче, но давайте не здесь.
Как вы верно написали дальше, это термин, а не *технология*. Да, я понимаю, что со словом *технология* всё звучит круче, но давайте не здесь.
Главным же сюрпризом этого решения для меня стало то, что база данных может быть вообще не нужна, если вам нужно хранить и перерабатывать действительно большие данные.
У меня в своё время был разрыв шаблона, когда главный программист на моё слово Oracle невозмутимо сказал «XML рулит»
У меня в своё время был разрыв шаблона, когда главный программист на моё слово Oracle невозмутимо сказал «XML рулит»
Никогда не понимал людей, которые хотят исключить из проекта на 100% SQL, почему не хотят объединять данные подходы?
В многих местах удобнее работать с nosql, когда вопрос заходит за списки, очереди и другие линейные/временные данные. А реляционными данными куда удобнее работать в реляционной БД.
Я на своем проекте, весьма крупном пользуюсь двумя системами, MySQL и Redis все прекрасно уживается и проблемы вообще не наблюдаются. Redis отдаются временные данные, которые могут прожить от 1 минуты до 1 недели. В то время Mysql очень хорошо справляется с хранением постоянных связанных данных.
В многих местах удобнее работать с nosql, когда вопрос заходит за списки, очереди и другие линейные/временные данные. А реляционными данными куда удобнее работать в реляционной БД.
Я на своем проекте, весьма крупном пользуюсь двумя системами, MySQL и Redis все прекрасно уживается и проблемы вообще не наблюдаются. Redis отдаются временные данные, которые могут прожить от 1 минуты до 1 недели. В то время Mysql очень хорошо справляется с хранением постоянных связанных данных.
а) не хотят плодить сущности
б) в большинстве задач возникает рано или поздно проблема синхронизации дублированных данных в разных хранилищах
б) в большинстве задач возникает рано или поздно проблема синхронизации дублированных данных в разных хранилищах
а) не хотят плодить сущности
В оригинале сущности не стоит плодить без необходимости. А необходимость регулярно возникает.
б) в большинстве задач возникает рано или поздно проблема синхронизации дублированных данных в разных хранилищах
Довольно успешно решается при грамотном планировании на уровне архитектуры, когда четко определяется где конкретные данные первичные, и регулярной фоновой процедуре проверки целостности и необходимой синхронизации данных.
В оригинале сущности не стоит плодить без необходимости. А необходимость регулярно возникает.
б) в большинстве задач возникает рано или поздно проблема синхронизации дублированных данных в разных хранилищах
Довольно успешно решается при грамотном планировании на уровне архитектуры, когда четко определяется где конкретные данные первичные, и регулярной фоновой процедуре проверки целостности и необходимой синхронизации данных.
Если прежде, чем использовать noSQL, придётся 1000 раз подумать по разу в день, то внедрение noSQL начнётся в четвёртом квартале третьего года, считая от начала раздумий.
В современном динамичном миреIT-бизнеса такое отставание может быть даже фатальным.
В современном динамичном мире
Не понял, каким образом в статью о noSQL попал Hadoop. Насколько я понимаю, noSQL — подход к организации баз данных с использованием моделей, отличных от реляционных. То есть, что SQL, что noSQL — это базы данных, приложения, ответственные за хранение и выборку данных. А Hadoop — это система обработки данных. Можно говорить о HBase или Hive, которые интегрированы с Hadoop, или рассказать о поддержке Hadoop в Cassandra, но говорить о чистом Hadoop и MapReduce в статье с обзором noSQL решений некорректно.
Добавил в заголовок hdfs. Просто hdfs — это тоже хранилище данных и оно совсем не реляционное:) А еще там есть структуры файлов, которые позволяют делать индексы на базе api hadoop, например, — MapFile. Очень простая, но быстрая штука, я вам скажу.
Это больше чем среда для распределённых вычислений. Я воспринимаю hadoop(hdfs) как хранилище для действительно больших данных.
Это больше чем среда для распределённых вычислений. Я воспринимаю hadoop(hdfs) как хранилище для действительно больших данных.
HDFS в первую очередь — файловая система. Под хранилищем в терминах БД понимается несколько другая модель. Разница хотя бы в том, что БД при работе с данными оперирует содержимым единиц хранения (таблиц в SQL или файлов/таблиц/областей памяти/что-там-еще в noSQL), а файловая система в общем случае работает на уровне самих единиц хранения (то есть файлик с места на место передвинет, но выборку по его тексту не сделает). Отличие HDFS от традиционных ФС — распределенность, что нужно для поддержки приложений обработки BigData, как например Hadoop. Соответственно, HDFS используется или как хранилище для данных на время выполнения задач обработки с Hadoop, или как хранилище пар ключ-значение (под управлением Hive). То есть там и там HDFS используется именно как файловая система. А что вы имеете ввиду, говоря про «хранилище для действительно больших данных»? HDFS можно использовать для хранения файлов, но опять же, при чем тут Hadoop?
Hadoop как платформа распределённых вычислений — ни при чём, это верно. Но в экосистеме hadoop находится и hdfs, и hbase, и hadoop mapreduce. Говоря о hadoop как о хранилище, мы имеем в виду весь спектр средств хранения данных в этой экосистеме. Да hdfs — прежде всего fs, но это распределённое хранилище петабайтов данных. Api hadoop'a позволяет работать с этой fs не как с набором файлов, а как с единицами данных. Разумеется, что вместо hdfs мы можем подставить туда другую реализацию файловой системы и hadoop будет работать с ней также, как с хранилищем.
Например: упомянутый мной MapFile — это не один файл, а два:) Но с помощью api hadoop'a мы можем работать с этими файлами как с индексом k-v. К слову, когда я «игрался» с hadoop, эта вещь искала слова за что-то около милисекунды в индексе inverted index, tf-idf, из 300 млн. слов, чем не реализация простейшего k-v хранилища на встроенном api?
К сожалению, я не могу рассказать ничего об hbase, так как его использует соседняя команда, а для «домашнего» использования у меня есть cassandra.
Например: упомянутый мной MapFile — это не один файл, а два:) Но с помощью api hadoop'a мы можем работать с этими файлами как с индексом k-v. К слову, когда я «игрался» с hadoop, эта вещь искала слова за что-то около милисекунды в индексе inverted index, tf-idf, из 300 млн. слов, чем не реализация простейшего k-v хранилища на встроенном api?
К сожалению, я не могу рассказать ничего об hbase, так как его использует соседняя команда, а для «домашнего» использования у меня есть cassandra.
Правильно, но теперь мы уже отдалились от темы статьи. Можно организовать систему хранения данных с использованием экосистемы Hadoop, но это совсем не noSQL. В рамках статьи имело бы смысл рассмотреть hive и упомянуть, что она происходит из проекта hadoop и является частью стека используемых при работе с hadoop технологий.
Согласен, но, писать о том, чем я не пользовался — не хотелось бы. Потому что по неопытности можно надавать вредных советов. Лучше уж их вообще не давать:) Удалять hadoop из статьи — не хотелось бы, потому что читателю может быть полезно узнать об этом решении и рассмотреть его экосистему поподробнее. Ссылка есть, там приведены почти все части экосистемы.
Если вы касались hbase или hive, если вам не трудно, вы могли бы описать их характерные черты в использовании, я добавлю в статью с вашим копирайтом:)
Если вы касались hbase или hive, если вам не трудно, вы могли бы описать их характерные черты в использовании, я добавлю в статью с вашим копирайтом:)
Добавил пометку в статью: «Hadoop — это экосистема решений по хранению и обработке огромных объёмов данных.»
Чтобы не было недопониманий.
Чтобы не было недопониманий.
Исходя из моего опыта, nosql удобнее всего строить на базе postgresql — с его очень приличным оптимизатором запросов и возможностью хранить хэш-массив внутри ячейки таблицы и выполнять поиск по полям этого хэш-массива, он позволяет строить достаточно гибкие схемы.
Я когда начинал учить Django, не смог прикрутить авторизацию данных и сессии к монго, и они отлично крутились на SQLite, имея реляционную модель, а вот для хитрых структур данных юзал монго, получая более гибкую модель данных и ненужность миграций после каждого чиха(утрируя). К чему это я? Копетанство о том, что инструмент нужно выбирать, исходя из требований. Серебряной пули нету =(
На больших приложениях с долгой историей «ненужность миграций» — очень страшная и опасная мысль (=
только туча бекапов, только хардкор :)
Миграции, зачастую, это только изменение схемы данных. В scheme free хранилищах они как бы не нужны чисто идеологически. С другой стороны, если необходимо единообразие схемы (какая-то схема всё равно обычно подразумевается приложением), то необходима конвертация из старого формата в новый, чтобы в коде не поддерживать несколько форматов одновременно. Но можно ли такую конвертацию называть миграцией?
Кстати, вот эта возможность иметь несколько форматов мне лично оказалась очень даже важна, когда есть несколько типов документов с некоторым общим набором полей типа автора, даты и т.д. И есть какие-то данные, присущие только конкретному типу. Таким образом их с одной стороны достаточно легко выгребать по унифицированным критериям и с другой стороны совершать конкретные действия уже сообразно типу. То есть схема проявляет свое присутствие не столько в самой базе, сколько уже в логике работы с данными. Таким образом, схем-фри базы как раз удобно использовать там, где надо несколько форматов. В этом контексте такая постепенная миграция, когда некоторое время одновременно действует два формата: старый и новый — довольно естественно смотрится.
Хм, ну я все таки считал бы такую конвертацию миграцией, в терминологии приложения. Ведь организация хранения данных в представлении РСУБД, по сути тоже формат хранения данных (более абстрактно, но все же).
а кто нибудь работает профессионально с Cassandra, MongoDB и прочими. Может дать оценку GlobalsDB?
я как работающий только с продуктами InterSystems, хотел бы понять почему GlobalsDB/Cache` пока никак не встанут в одну линейку с остальными NoSQL.
я как работающий только с продуктами InterSystems, хотел бы понять почему GlobalsDB/Cache` пока никак не встанут в одну линейку с остальными NoSQL.
Или прокомментировал вот это: www.mgateway.com/docs/universalNoSQL.pdf
Почему то все забыли про nosql плагин для mysql HandlerSocket. Дает возможность обращаться к одним и тем же таблицам и как к хранилищу ключ-значение, что дает ощутимый прирост в скорости, так и с помощью классической sql выборки с внешними связями и joinами.
Хороший обзор, спасибо
Интересен ваш опыт с OrientDB
Интересен ваш опыт с OrientDB
Я работал с Ориентом. Понравилось то, что эту БД можно легко встроить в настольное приложение, для чего я ее и использовал. Правда стоит учитывать, что Ориентом занимается только один человек (по крайней мере, раньше так было, когда я с ней работал), и когда обнаруживается глюк, он исправляется не так быстро, как в более популярных базах. Ну и вообще когда я с ней работал (года полтора назад), она была сыроватая, но приятная в использовании. С документацией было слабенько, но разработчик отвечал на письма и темы в Google Groups.
Спасибо за комментарий. К сожалению, OrientDB я не использовал, потому ничего путного не могу сказать про эту базу данных. Только потрогал немного, когда выбирал небольшое k-v решение, но выбрал в итоге leveldb.
У меня мало опыта с базами данных, но, пока что, считаю, что при правильно спроектированном приложении noSQL с лёгкостью заменит SQL базу, причём поддержка и расширение такого проекта будет значительно проще.
Очень хотелось бы какого-нибудь примера из жизни, который не получится эффективно решить с помощью noSQL.
Очень хотелось бы какого-нибудь примера из жизни, который не получится эффективно решить с помощью noSQL.
Хотите примеров? Их есть у меня.
Тупая запись и последующий анализ нескольких типов логов, линейный каталог оборудования на 10-15 млн записей.
Реализация несложная, а вот быстродействие Вас огорчит.
А вот тот же каталог оборудования с учетом вложенности ( Например: Участок водопровода сотоит из труб и колодцев, колодец состоит из крышки люка, задвижки и насоса, насос в свою очередь состоит из ряда деталей, сложная делать состоит из прокладок и других деталей и.т.д. ) проще реализовать на noSQL и вежливо попросить заказчика нарастить мощность оборудования.
Опытный экскаваторщик сумеет ковшом закрыть спичечный коробок, стоящий на земле, но в реальной жизни это быстрее сделать руками или ногой.
Тупая запись и последующий анализ нескольких типов логов, линейный каталог оборудования на 10-15 млн записей.
Реализация несложная, а вот быстродействие Вас огорчит.
А вот тот же каталог оборудования с учетом вложенности ( Например: Участок водопровода сотоит из труб и колодцев, колодец состоит из крышки люка, задвижки и насоса, насос в свою очередь состоит из ряда деталей, сложная делать состоит из прокладок и других деталей и.т.д. ) проще реализовать на noSQL и вежливо попросить заказчика нарастить мощность оборудования.
Опытный экскаваторщик сумеет ковшом закрыть спичечный коробок, стоящий на земле, но в реальной жизни это быстрее сделать руками или ногой.
Я не очень понимаю проблему записи и анализа логов в noSQL-базе. Особенно, если логи записывать не в виде строк, а в виде документов. Т.е., каждая запись — документ с определённым набором полей. Далее можно map-reduce или ещё что-нибудь.
Например, couchDB позволяет создавать заранее выборку (view), которая автоматически будет инкрементно индексироваться и время отдачи этой выборки будет практически таким же, как и время отдачи одного документа.
Каталог оборудования с учётом вложенности — тут не возьмусь сказать сходу, надо сравнивать.
Аналогию понял, спасибо.
Например, couchDB позволяет создавать заранее выборку (view), которая автоматически будет инкрементно индексироваться и время отдачи этой выборки будет практически таким же, как и время отдачи одного документа.
Каталог оборудования с учётом вложенности — тут не возьмусь сказать сходу, надо сравнивать.
Аналогию понял, спасибо.
Я и написал, что реализовать не проблема, но при прочих равных, в данной задаче SQL предпочтительнее, т.к. просмотр отчетов довольно нерегулярное занятие и если мы будем обновлять вьюху при каждой записи в лог, то это потребует дополнительной мощности системы. Ведь логи пишуться постоянно. У меня http daemon на некоторых серверах добавляет до 1000 записей в секунду. Конечно, мы можем отключить постоянный апдейт вьюхи, но тогда при обращении к ней, к примеру раз в две недели вьюха будет перестраиваться довольно долго. Существенно дольше, чем отработает запрос к SQL таблице.
Решение просто как 3 копейки:
Система пишет лог в noSQL базу, а потом по расписанию несколько раз в сутки переносит поля в SQL таблицу. В результате я имею быстрый оперативный лог, который нужен в 90% случаев, и историю за полгода, требующую минимум места и не требующую ресурсов до обращения к ней. А это бывает не чаще раза в год.
Решение просто как 3 копейки:
Система пишет лог в noSQL базу, а потом по расписанию несколько раз в сутки переносит поля в SQL таблицу. В результате я имею быстрый оперативный лог, который нужен в 90% случаев, и историю за полгода, требующую минимум места и не требующую ресурсов до обращения к ней. А это бывает не чаще раза в год.
Я бы кстати, немного добавил от себя. CouchDB сам по себе не про логи (= У нее есть индексы, вьюхи и прочие очень вкусные вещи, типа Map Reduce на всем этом деле. Но она не про логгирование, ибо на запись не больно шустра. Тут как раз MongoDB лучше, она как раз про логи.
Я для примера привёл. Ясное дело, что в каждом конкретном случае надо выбирать конкретный инструмент, но, пока что, моё мнение — для любой задачи можно найти подходящее noSQL-решение, которое будет в среднем лучше, чем SQL-решение.
Возможно, позже пойму что был не прав.
Возможно, позже пойму что был не прав.
для любой задачи можно найти подходящее noSQL-решение, которое будет в среднем лучше, чем SQL-решение
Как вы реализуете, например, транзакции затрагивающие более одного документа?
>для любой задачи можно найти подходящее noSQL-решение, которое будет в среднем лучше, чем SQL-решение…
… по какому-то критерию. Плюс есть классы задач, которые очень хорошо ложатся на реляционные БД вообще и SQL в частности.
… по какому-то критерию. Плюс есть классы задач, которые очень хорошо ложатся на реляционные БД вообще и SQL в частности.
Автор в своем описании забыл прадедушку noSQL систем — Lotus Domino. И этот прадедушка до сих пор крепок и не впал в маразм, хотя багаж прошлого изрядно осложняет жизнь.
Теперь про конкретику. Я начал писать приложения на Lotus еще в середине 90-х. Плюсом была быстрота реализации проекта, кроссплатформенность, масштабируемость и документоориентированная модель данных, а огромным минусом было быстродействие и сложность перестройки ума головы с реляционной на нереляционную модель данных. С тех пор много воды и версий Lotus утекло, но основные проблемы все равно остались. Они лежат в самой идеологии документоориентированной модели. Не надо замыкаться на слабых сторонах продукта, надо просто уметь их избегать.
Мы до сих пор разрабатываем приложения на Lotus, но при этом практически всегда в системах с большими объемами данных, закладываем интеграцию с реляционной СУБД на нижнем уровне. По крайней мере, в Lotus это делается несложно и различными способами. Начиная от встроенных механизмоов синхронизации, кончая Web сервисами.
Бизнес логику однозначно проще делать на noSQL, а вот всякие редкоизменяемые и однозначно связанные объекты с большим количеством записей, типа логов, редко требуемых архивов, каталогов товаров или объектов, проще выносить в SQL.
Разберем тот же пример с профилем игрока.
В рамках гибридной реализации — профиль храниться в NoSQL хранилище и довольно часто используется.
При этом хранилище с историей скилзов, к примеру, можно реализовать как SQL, т.к. там будет огромное число стандартных записей — полная история изменения скилзов. Протокол обмена, к примеру, Web сервисы. При необходимости изменения какого-либо скилза игрока дергается соответствующий сервис на SQL системе, который вносит изменения в скиллз конкретного игрока. Триггер в таблице скилзов, в свою очередь, определяет значение нового скилза и дергает Web сервис на стороне noSQL системы, который и записывает измененный скилз в профиль конкретного игрока.
Надо просто на этапе планирования архитектуры приложения определить что где будет храниться и четко прописать интерфейсы взаимодействия.
И не стоит забывать о еще одном преимуществе такой архитектуры — при повышении нагрузки довольно просто будет разнести SQL и noSQL подсистемы по разным серверам и резко снизить загруженность Front end.
Теперь про конкретику. Я начал писать приложения на Lotus еще в середине 90-х. Плюсом была быстрота реализации проекта, кроссплатформенность, масштабируемость и документоориентированная модель данных, а огромным минусом было быстродействие и сложность перестройки ума головы с реляционной на нереляционную модель данных. С тех пор много воды и версий Lotus утекло, но основные проблемы все равно остались. Они лежат в самой идеологии документоориентированной модели. Не надо замыкаться на слабых сторонах продукта, надо просто уметь их избегать.
Мы до сих пор разрабатываем приложения на Lotus, но при этом практически всегда в системах с большими объемами данных, закладываем интеграцию с реляционной СУБД на нижнем уровне. По крайней мере, в Lotus это делается несложно и различными способами. Начиная от встроенных механизмоов синхронизации, кончая Web сервисами.
Бизнес логику однозначно проще делать на noSQL, а вот всякие редкоизменяемые и однозначно связанные объекты с большим количеством записей, типа логов, редко требуемых архивов, каталогов товаров или объектов, проще выносить в SQL.
Разберем тот же пример с профилем игрока.
В рамках гибридной реализации — профиль храниться в NoSQL хранилище и довольно часто используется.
При этом хранилище с историей скилзов, к примеру, можно реализовать как SQL, т.к. там будет огромное число стандартных записей — полная история изменения скилзов. Протокол обмена, к примеру, Web сервисы. При необходимости изменения какого-либо скилза игрока дергается соответствующий сервис на SQL системе, который вносит изменения в скиллз конкретного игрока. Триггер в таблице скилзов, в свою очередь, определяет значение нового скилза и дергает Web сервис на стороне noSQL системы, который и записывает измененный скилз в профиль конкретного игрока.
Надо просто на этапе планирования архитектуры приложения определить что где будет храниться и четко прописать интерфейсы взаимодействия.
И не стоит забывать о еще одном преимуществе такой архитектуры — при повышении нагрузки довольно просто будет разнести SQL и noSQL подсистемы по разным серверам и резко снизить загруженность Front end.
Еще забыли про Амазоноаский DynamoDB.
Тоже смотрел разное, в итоге написал вот такую короткую статью-обзор:
maximkr.livejournal.com/20797.html
Вообще из всего NoSQL больше всего нравится elasticsearch
maximkr.livejournal.com/20797.html
Вообще из всего NoSQL больше всего нравится elasticsearch
Могу ошибаться, но каким боком к NoSQL (кстати выше сказано верно про Hadoop) относится ElasticSearch? Это поисковый движок, а не хранилище данных (=
Так там можно хранить данные, хоть с индексацией, хоть без. На базе lucene недавно делал систему хранения данных, там десятки терабайт — все ок.
Странная штука, надо сказать (= Я понимаю хранить индексы для поисковых запросов, а вот данные. Надо будет глянуть, но что-то как-то у меня диссонанс настал с хранением данных в поисковом движке (=
Когда начал его изучать, то толком не понял, почему он считается поисковым движком, не полноценной БД. :)
Там есть тип — документ. У него могут быть совершенно полноценные поля. Для поля можно указать, нужно его только хранить, только индексировать, то и другое вместе. Можно поле анализировать (тогда в одном поле можно несколько элементов хранить и искать по ним) или нет (тогда ищем по полному совпадению). Есть развитый язык запросов, можно создавать запросы динамически, есть возможность кешировать запросы. Транзакции есть. Индекс сам по себе практически неубиваемый. Чем оно хуже прочих NoSQL СУБД — решительно не понятно, ИМХО даже лучше.
ИМХО они просто начали раньше, чем началось это NoSQL движение, поэтому к ним «прицепилось», что это индекс. Если поискать по мейл-листу, то проекты с использованием Lucene (и движков на его основе) в качестве полноценной СУБД — не редкость.
ИМХО они просто начали раньше, чем началось это NoSQL движение, поэтому к ним «прицепилось», что это индекс. Если поискать по мейл-листу, то проекты с использованием Lucene (и движков на его основе) в качестве полноценной СУБД — не редкость.
К высокой производительности, большим данным, гарантиям доступности и т. п., отношения не имею, потому большинство критериев в статье для меня не критичны. Выбираю noSQL (CouchDB в основном) или SQL (MySQL по инерции) по результатам анализа предметной области, в основном свойств её сущностей. Если получается, что сущности будут представлены в SQL БД в виде сильно разряженных ненормализованных таблиц, либо связи основной таблицы с десятками, а то сотнями «словарей», то смотрю какие проблемы с выборкой могут быть при использование noSQL, придётся ли, в частности дублировать данные, чтобы осуществлять выборку рекомендуемыми средствами БД или придётся использовать нерекомендуемые, а то и вообще фильтровать данные на уровне приложения. Конечно, не только это учитываю, но как-то в большинстве случаев сводится к этому.
Читал в предвкушении что вот-вот появится Mnesia. Не появилась,- опечалило. Это nosql старушка старше чуть ли не всех других, а вы её даже не упомянули :)
Эх, вот где бы взять такую же статью, но на английском. А то задолбали отдельные коллеги со своими благими порывами…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему нужно 1000 раз подумать, прежде чем использовать noSQL