Комментарии 34
отдельное спасибо за картинку!
=)
=)
Аааа! Еретики! Использовать NoSQL вместо MySQL!.. Ааа!..
В статье не говорилось про использование «вместо». Мне кажется разумным использовать их «вместе» =)
Сарказм? Какой сарказм?
Даже Монти с вами солидарен)
Еще в Graph Stores можно добавить такой комбайн как OpenLink Virtuoso. Приходилось с ним работать как раз используя php.
У MongoDB тоже есть интерактивный shell tutorial: try.mongodb.org/
А также кому интересно могут пройти бесплатные курсы в университете MongoDB.
Как раз сейчас идет курс M102: MongoDB for DBAs.
Как раз сейчас идет курс M102: MongoDB for DBAs.
Годный пост, плюсую. Коротко и по делу. Давайте дальше статьи про FoundationDB, Neo4j, OrientDB.
Как на счёт SOLR?
Подождите-подождите. SOLR надстройка над lucene. Lucene ориентирован на хранение поисковых индексов, т.е. это более узкое решение. Давайте тогда еще-больше специализированных решений добавим, типо файловых систем — это тоже «nosql».
А вот Jena, имхо, можно в список добавить. Впрочем чур меня чур, семантические хранилища тройки или четверки хранят — ими можно граф описать. В принципе sparql — язык поиска пересечений по сем. графу.
А вот Jena, имхо, можно в список добавить. Впрочем чур меня чур, семантические хранилища тройки или четверки хранят — ими можно граф описать. В принципе sparql — язык поиска пересечений по сем. графу.
Вместо SOLR надо был написать ElasticSearch, который легко хранит как сам индекс, так и данные, и в принципе все больше и больше подходит под использования в качестве NoSQL решения с выборкой по многим полям-ключам
Tarantool
Противопоставляется Redis, от которого отличается, по словам разработчиков, увеличенным быстродействием, благодаря тому, что все данные находятся в памяти. Есть встроенный механизм очередей.
Фишка Tarantool в том что это почти реляционная база, с индексами для выборки. Сравнивается с Redis потому что имеет схожую производительность, оба хранят все в памяти, но постоянно пишут на диск чтобы не потерять данные.
В Redis очень хороший механизм очередей.
А как же couchbase с «cross datacenter replication» из коробки?
couchbase это membase, впитавший в себя кое-что из CouchDB, и то не всё. Вроде бы не форк, а с другой стороны много общего. Вот тут есть описание отличий Couchbase от CouchDB.
Чую впереди еще серия статей: noSQL и C#, noSQL и asp, noSQL и Python… То есть при чем здесь PHP? К тому же все это сравнение уже не раз здесь было представлено?
не плохой обзор, полезно начинающим… но хотелось добавить следующее:
1) практика показывает, что на сайтах производителей тесты не всегда объективны и их лучше делать самому.
порой у меня тесты отличались на 50-250% процентов от заявленного,
все ИМХО зависит от методике тестирования и железа. По этому тесты делаем сами, а не ведемся на марткетинговые ходы.
2) что касается тарантула, то последние новости: в tarantool 1.6 в связи с переходом на FFI Lua производительность поднялась в от 20% до 800% и можно говорить о производительности от 1.2М до 5М (на разные виды операций)
3) Neo4j не единственная графовая БД :
1) практика показывает, что на сайтах производителей тесты не всегда объективны и их лучше делать самому.
порой у меня тесты отличались на 50-250% процентов от заявленного,
все ИМХО зависит от методике тестирования и железа. По этому тесты делаем сами, а не ведемся на марткетинговые ходы.
2) что касается тарантула, то последние новости: в tarantool 1.6 в связи с переходом на FFI Lua производительность поднялась в от 20% до 800% и можно говорить о производительности от 1.2М до 5М (на разные виды операций)
3) Neo4j не единственная графовая БД :
Советую еще посмотреть в сторону www.rethinkdb.com/
Для CouchDB есть ещё инструмент couchdb-php, работает через CURL с кэшированием в Memcached. В CouchDB есть из коробки REST API.
по результатам одного теста, она заметно медленнее MongoDBАвтор этого теста ещё в 2010 году упоминал, что этот тест (опубликованный в 2009 году) вряд ли можно считать основательным, так как и MondoDB, и CouchDB развиваются со временем, неравномерно ускоряя свою работу.
Сегодня на дворе 2014 год, так что эта ссылка устарела в несколько раз сильнее.
Подозреваю, между прочим, что и комикс Эрика Рэдмонда 2011 года, посвящённый выбору между существующими хранилищами, также мог несколько устареть за годы, прошедшие от момента его появления на свете.
(Например, в том году можно было установить новейшую MongoDB на Windows XP, а сейчас — не получится.)
CouchDB во многом похожа на MongoDB. Отличается отсутствием блокировки при операциях чтения, и более сложной в настройке технологией шардинга
В чем они похожи, кроме того, что они документо-ориентированы? Они же принципиально разные. MongoDB предоставляет инструменты построения объединений (JOIN) во время чтения, а в CouchDB необходимо создавать материализованные представления выборок, а в момент чтения доставать их а-ля key-value. Они для принципиально разных ситуаций созданы.
Очень часто забывают про handler socket для MySQL. Вот годная презентация на эту тему от одного известного сайта
We found Cassandra's eventual consistency model to be a difficult pattern to reconcile for our new Messages infrastructure
facebook.com/note.php?note_id=454991608919
Как я понял, HBase лучше подходила по требованиям сжатия данных и балансирования нагрузки. Плюс, команда Facebook уже имела большой опыт в работе с HBase, HDFS и Hadoop.
Не сильно популярная документно-ориентированная СУБД BaseX есть, оперирующая XML-документами с помощью XQuery. Очень просто сделать отдачу прямо готового (x)HTML из базы.
Мы в прошлом году подсели вот на такой вариант Graph/Document/Key БД: www.arangodb.org
Отсчет у них начался ровно два года назад (предыдущая версия была известна под названием AvocadoDB), но за это время очень многое и интересное было обдумано, предложено и добавлено.
В последней версии (1.4 -> 2.0) появился sharding и ребята убрали максиму «АрангоДБ не для будущего Амазона»
Сочетание команды реальных (европейских, в основном) энтузиастов, отсутствие стремления сделать систему моментально популярной (и потому свобода движений) — иногда может быть очень интересным.
Отсчет у них начался ровно два года назад (предыдущая версия была известна под названием AvocadoDB), но за это время очень многое и интересное было обдумано, предложено и добавлено.
В последней версии (1.4 -> 2.0) появился sharding и ребята убрали максиму «АрангоДБ не для будущего Амазона»
Сочетание команды реальных (европейских, в основном) энтузиастов, отсутствие стремления сделать систему моментально популярной (и потому свобода движений) — иногда может быть очень интересным.
Обзор слишком поверхностный. Redis это тоже in-memory хранилище.
Заступлюсь немного за редиску) У меня в тестах выходило больше миллиона операций на одной инстанции redis. На обычной довольно-таки железке. Да и фишка redis, как по мне, это его типы данных и встроенный lua.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP и различные виды NoSQL