PHP и различные виды NoSQL

[@Conung_ViC]

отдельное спасибо за картинку!
=)

[@mishasamin]

Аааа! Еретики! Использовать NoSQL вместо MySQL!.. Ааа!..

[@jkoz]

В статье не говорилось про использование «вместо». Мне кажется разумным использовать их «вместе» =)

[@Delphinum]

Сарказм? Какой сарказм?

[@Kudja]

отчего же? вполне успешно используем mysql для данных и redis для кеша, в него же можно (никак руки не доходят) сессии пользователей сложить

[@Grigorieff]

Есть такие типы данных, которые удобнее хранить в NoSQL, а для других удобнее MySQL, часть noSQL-хранилищ удобно использовать в качестве кэша

[@NorthDakota]

Даже Монти с вами солидарен)

[@sparksounds]

Еще в Graph Stores можно добавить такой комбайн как OpenLink Virtuoso. Приходилось с ним работать как раз используя php.

[@AndryX]

У MongoDB тоже есть интерактивный shell tutorial: try.mongodb.org/

[@iDen]

А также кому интересно могут пройти бесплатные курсы в университете MongoDB.
Как раз сейчас идет курс M102: MongoDB for DBAs.

[@bashtannik]

Годный пост, плюсую. Коротко и по делу. Давайте дальше статьи про FoundationDB, Neo4j, OrientDB.

[@Holden]

Как на счёт SOLR?

[@Exbe]

Подождите-подождите. SOLR надстройка над lucene. Lucene ориентирован на хранение поисковых индексов, т.е. это более узкое решение. Давайте тогда еще-больше специализированных решений добавим, типо файловых систем — это тоже «nosql».

А вот Jena, имхо, можно в список добавить. Впрочем чур меня чур, семантические хранилища тройки или четверки хранят — ими можно граф описать. В принципе sparql — язык поиска пересечений по сем. графу.

[@NickyX3]

Вместо SOLR надо был написать ElasticSearch, который легко хранит как сам индекс, так и данные, и в принципе все больше и больше подходит под использования в качестве NoSQL решения с выборкой по многим полям-ключам

[@x7mz]

Tarantool
Противопоставляется Redis, от которого отличается, по словам разработчиков, увеличенным быстродействием, благодаря тому, что все данные находятся в памяти. Есть встроенный механизм очередей.

Фишка Tarantool в том что это почти реляционная база, с индексами для выборки. Сравнивается с Redis потому что имеет схожую производительность, оба хранят все в памяти, но постоянно пишут на диск чтобы не потерять данные.

В Redis очень хороший механизм очередей.

[@akalend]

тарантул 1.6 будет использовать вид хранения msgpack, а с внедрением этой фичи можно уже говорить о документно-ориентированности. По функциональности тарантул во многом превосходит редис.

[@mobilz]

А как же couchbase с «cross datacenter replication» из коробки?

[@Makaveli]

couchbase это membase, впитавший в себя кое-что из CouchDB, и то не всё. Вроде бы не форк, а с другой стороны много общего. Вот тут есть описание отличий Couchbase от CouchDB.

[@SiDChik]

Чую впереди еще серия статей: noSQL и C#, noSQL и asp, noSQL и Python… То есть при чем здесь PHP? К тому же все это сравнение уже не раз здесь было представлено?

[@bethrezen]

Есть ещё ArangoDb. Про производительность и клиенты для различных языков.

[@akalend]

не плохой обзор, полезно начинающим… но хотелось добавить следующее:
1) практика показывает, что на сайтах производителей тесты не всегда объективны и их лучше делать самому.
порой у меня тесты отличались на 50-250% процентов от заявленного,
все ИМХО зависит от методике тестирования и железа. По этому тесты делаем сами, а не ведемся на марткетинговые ходы.
2) что касается тарантула, то последние новости: в tarantool 1.6 в связи с переходом на FFI Lua производительность поднялась в от 20% до 800% и можно говорить о производительности от 1.2М до 5М (на разные виды операций)
3) Neo4j не единственная графовая БД :

[@inlanger]

Советую еще посмотреть в сторону www.rethinkdb.com/

[@Elfet]

Очень понравилась. Функциональности меньше чем в MongoDB, но сделано все более лаконично и удобно (так же очень интересно сравнить код первой и втрой и понять что лучше;) )

[@Makaveli]

Для CouchDB есть ещё инструмент couchdb-php, работает через CURL с кэшированием в Memcached. В CouchDB есть из коробки REST API.

[@Mithgol]

по результатам одного теста, она заметно медленнее MongoDB

Автор этого теста ещё в 2010 году упоминал, что этот тест (опубликованный в 2009 году) вряд ли можно считать основательным, так как и MondoDB, и CouchDB развиваются со временем, неравномерно ускоряя свою работу.

Сегодня на дворе 2014 год, так что эта ссылка устарела в несколько раз сильнее.

Подозреваю, между прочим, что и комикс Эрика Рэдмонда 2011 года, посвящённый выбору между существующими хранилищами, также мог несколько устареть за годы, прошедшие от момента его появления на свете.

(Например, в том году можно было установить новейшую MongoDB на Windows XP, а сейчас — не получится.)

[@Urn]

подтверждаю, у меня например уже устаревший кауч 1.2.0 летает по сравнению с 1.0.1

[@denis-isaev]

CouchDB во многом похожа на MongoDB. Отличается отсутствием блокировки при операциях чтения, и более сложной в настройке технологией шардинга

В чем они похожи, кроме того, что они документо-ориентированы? Они же принципиально разные. MongoDB предоставляет инструменты построения объединений (JOIN) во время чтения, а в CouchDB необходимо создавать материализованные представления выборок, а в момент чтения доставать их а-ля key-value. Они для принципиально разных ситуаций созданы.

[@KEKSOV]

Очень часто забывают про handler socket для MySQL. Вот годная презентация на эту тему от одного известного сайта

[@jkoz]

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.

[@VolCh]

Не сильно популярная документно-ориентированная СУБД BaseX есть, оперирующая XML-документами с помощью XQuery. Очень просто сделать отдачу прямо готового (x)HTML из базы.

[@africaunite]

Мы в прошлом году подсели вот на такой вариант Graph/Document/Key БД: www.arangodb.org

Отсчет у них начался ровно два года назад (предыдущая версия была известна под названием AvocadoDB), но за это время очень многое и интересное было обдумано, предложено и добавлено.
В последней версии (1.4 -> 2.0) появился sharding и ребята убрали максиму «АрангоДБ не для будущего Амазона»

Сочетание команды реальных (европейских, в основном) энтузиастов, отсутствие стремления сделать систему моментально популярной (и потому свобода движений) — иногда может быть очень интересным.

[@Urn]

Обзор слишком поверхностный. Redis это тоже in-memory хранилище.

[@AterCattus]

Заступлюсь немного за редиску) У меня в тестах выходило больше миллиона операций на одной инстанции redis. На обычной довольно-таки железке. Да и фишка redis, как по мне, это его типы данных и встроенный lua.