Состоялся релиз распределённой документоориентированной базы данных Apache CouchDB 3.0, относящейся к классу NoSQL-систем. Исходные тексты проекта распространяются под лицензией Apache 2.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52463
Полнотекстовый поиск добавили?
> Полнотекстовый поиск добавили?
>>В состав включён поисковый движок Dreyfus на основе Lucene, позволяющий значительно упростить развёртывание поисковой системы на базе CouchDB;да разные возможности были до того
https://github.com/gesellix/couchdb-2-elasticsearch (там рекомендуют то что ниже)
https://www.elastic.co/guide/en/logstash/current/plugins-inp...
и из старых
https://github.com/rnewson/couchdb-lucene
добавили простое взаимодействие с lucene, в коммерческом продукте Cloudant lucene идет из коробки.
Так что фактически подтянули функциональность до приемлемого уровня.
Апаче могильник, апаче могильник, повторяют постоянно на опеннете. Пилится и шиперится....
Ну ладно, колумбарий
интересная БД, учитывая историю её появления, создателя (Damien Katz) и развитие в виде couchbase
А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением документов в том же Слоне?
> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением
> документов в том же Слоне?попробуйте в jsonb с запросами и возможно вопросы отпадут ;)
и хотя couchbase несколько другой продукт https://query-tutorial.couchbase.com/tutorial/#1
Так а преимущества-то в чём?
Как я понял, в том, что, если в Слоне хранить jsonb, то как-то не так будут работать запросы? Сомневаюсь.
> Так а преимущества-то в чём?
> Как я понял, в том, что, если в Слоне хранить jsonb, то
> как-то не так будут работать запросы? Сомневаюсь.сложнее обслуживание и масштабирование, синтаксис "несколько сложноват", с ключами есть свои особенности, тулинг ещё не весь не везде, с документацией по jsonb не шибко, нужно описывать данные...
https://blog.couchbase.com/postgres-jsonb-and-nosql/
бенчей нет - скорость сравнить проблематично
и кочбэйз мастер-мастер, с достаточно простой клатеризацией и прочими плюшкамиНО это все не про кочДБ ;) там тоже мастер-мастер, но нет мемори-фёст и нет n1ql
Понятно, это для тех, у кого json головного мозга. И, соответственно, главное требование к "СУБД", чтоб яваскриптик и ясон. И, да, мемори фёст. Можно подумать где-то мемори не фёст.
Мастер-мастеров не бывает. Ну не бывает. Мастер-мастер это как сказать ребёнку, что пальцы можно пихать в розетку, главное их сначала заточить, чтобы они в эту розетку влезли.
> не бываетВот это новость. Плохой опыт?
К слову, там в статье такая дичь дикая написана. Какие-то миллионы миллиардов join-ов в РСУБД. Что за чушь.
... да и нет никакой проблемы хоть в квинтиллионе joins-ов.
Denis Rosa, Developer Advocate, Couchbase on August 6, 2019
Просто бизнес, в раше кстати кто то из опсосов пользует
Бизнес не бизнес, а дело в том, что в статье (это, кстати, типично для евангелистов NoSQL) перевирается работа с реляционными СУБД. С ними есть проблемы, но совершенно другие. Т.е. текст статье орёт просто о том, что писавший её с реляционными СУБД не работал никогда, а труд его жизни это статейки обо всём на свете крапать (завидное умение).
В общем, преимущество одно -- если у вас есть специалист, который что-то там лабал на яваскрипте или пехепе, то ему не нужно будет разбираться в особенностях реляционного моделирования и декларативных языках запросов. Что, в общем-то, неплохой такой плюс. А минусы? Типичны. Нет транзакционной и структурой целостности, нет изоляций, модель "не защищает себя сама".
> В общем, преимущество одно -- если у вас есть специалист, который что-то
> там лабал на яваскрипте или пехепе, то ему не нужно будет
> разбираться в особенностях реляционного моделирования и декларативных языках запросов.
> Что, в общем-то, неплохой такой плюс. А минусы? Типичны. Нет транзакционнойу кочбэйз ACID https://blog.couchbase.com/couchbase-brings-distributed-mult.../
> и структурой целостности, нет изоляций, модель "не защищает себя сама"."реляционное моделирование" не всегда нужно (чаще не нужно), зачем оверинжиниринг?
Нет. ACID-а там в принципе быть не может. Обеспечивается целостность только на уровне записи, но не документа.
> Нет. ACID-а там в принципе быть не может. Обеспечивается целостность только на
> уровне записи, но не документа.если вы хотите поспорить с документацией...
"The database tier now offers ACID transactions across multiple documents, multiple buckets, and multiple nodes."
https://i2.wp.com/blog.couchbase.com/wp-content/uploads/2019...
Да, но тут скорее не спор, а то, что в документации просто манипулируют понятием.
> Да, но тут скорее не спор, а то, что в документации просто
> манипулируют понятием.дык напишите прям там, развенчайте "манипуляцию", примерчики подкиньте - где не будет работать как написано
Сервер доступен дя скачивания, тулинг для многих ЯП
https://docs.couchbase.com/java-sdk/3.0/howtos/distributed-a...
Зачем и для кого?
Не нужно кому и для чего? Если у вас есть ОО-модель, то ОРМ сам вам всё разложит. И поэтому никакое моделирование и не потребуется. Другое дело, что реляционные модели просто эффективней. Т.е. надёжно хранить что-то, надёжно изменять что-то, искать что-то или агрегировать что-то куда проще по реляционной модели (даже если вы никак с ней напрямую не работаете). Поэтому мне и не ясно зачем хранить сериализацию состояний объектов (пусть и в ясон-представлении), вместо того, чтобы давать указания "проигрывать" реляционную модель. Ведь выгоды никакой вообще, а издержек масса.
> Не нужно кому и для чего? Если у вас есть ОО-модель, то
> ОРМ сам вам всё разложит. И поэтому никакое моделирование и не
> потребуется. Другое дело, что реляционные модели просто эффективней. Т.е. надёжно хранить
> что-то, надёжно изменять что-то, искать что-то или агрегировать что-то куда проще
> по реляционной модели (даже если вы никак с ней напрямую не
> работаете). Поэтому мне и не ясно зачем хранить сериализацию состояний объектов
> (пусть и в ясон-представлении), вместо того, чтобы давать указания "проигрывать" реляционную
> модель. Ведь выгоды никакой вообще, а издержек масса.ну как-то вот живут ;) https://habr.com/ru/post/436762/
хабр? фу
Это просто модно так.
Люди пишут, что в ряде случаев, "чтобы работало быстрее" они отказываются от транзакционной надёжности. Есть большой накопитель "в памяти", с предельно денормализованный моделью, который и принимает решения, а затем уже принятое таким образом решение дублируется относительно медленной обычной реляционной транзакционной СУБД. Решение вполне сносное: "накопитель в памяти" относительно их требований вполне надёжен, "грязь" в случае сбоя редка и решается административно и персонально. Но тут коуч используется не как СУБД, а как кэш (накопитель), персистируют же данные вполне традиционно -- в толстый реляционный надёжный Оракл.
> Люди пишут, что в ряде случаев, "чтобы работало быстрее" они отказываются от
> транзакционной надёжности. Есть большой накопитель "в памяти", с предельно денормализованный
> моделью, который и принимает решения, а затем уже принятое таким образом
> решение дублируется относительно медленной обычной реляционной транзакционной СУБД.
> Решение вполне сносное: "накопитель в памяти" относительно их требований вполне надёжен,
> "грязь" в случае сбоя редка и решается административно и персонально. Но
> тут коуч используется не как СУБД, а как кэш (накопитель), персистируют
> же данные вполне традиционно -- в толстый реляционный надёжный Оракл."написано" (в каментах) на предложение "другой" модели но с рсубд, что трудозатраты были бы выше, чем даже переписать под новый движок
https://habr.com/ru/post/436762/#comment_19640432
Это всё похоже на бла-бла-бла. Обчитался потциент Клипмана вот и произошёл такой вот прецедент. В индустрии же важно быть модным. Чтоб движуха была, а то динозавром заклеймят.
Из статьи не понял зачем там объективно NoSQL. Больной жаловался на то, что "Оракл много транзакций не может". Может. До одури много может. Потолок в ярд явно надуман. Не вижу что там в этот ярд может упереться. И совершенно мне не ясно зачем там объектный кэш для повышения оперативности реакции. Буквально, автор утверждает, что алгоритмы поиска в памяти у Коуча быстрее, чем у Оракла. Что-то очень-очень сомнительно.
> Это всё похоже на бла-бла-бла. Обчитался потциент Клипмана вот и произошёл такой
> вот прецедент. В индустрии же важно быть модным. Чтоб движуха была,
> а то динозавром заклеймят.
> Из статьи не понял зачем там объективно NoSQL. Больной жаловался на то,
> что "Оракл много транзакций не может". Может. До одури много может.
> Потолок в ярд явно надуман. Не вижу что там в этот
> ярд может упереться. И совершенно мне не ясно зачем там объектный
> кэш для повышения оперативности реакции. Буквально, автор утверждает, что алгоритмы поиска
> в памяти у Коуча быстрее, чем у Оракла. Что-то очень-очень сомнительно.ну сделайте проект - докажите обратное, вы же "уверены" ;)
Мариот - тоже кучу всего перепробывал, ушел на коуч - SQL захлебывался, почитайет по ссылкам.
иБэй заюзал коуч https://www.youtube.com/watch?v=2GZA5SrWlvk&feature=youtu.be
Маркетинг - ну есть, не без этого, но это большой бизнес и просто на шару ввязаться в масштабный проект с заменой движка... звучит более сомнительно
Да, мы все очень злы к друг другу -- сразу бросаемся разоблачать и сомневаться. Объективно, в статье не достаточно исходных данных. Поэтому и включается опыт (и дремучие инстинкты). А мой опыт твердит, что NoSQL это совсем ни к чему. Это один из симптомов куда более выше расположившейся болезни.
> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением
> документов в том же Слоне?Сейчас нету смысла, 12 лет назад да эта БД считалась как прорыв, а сегодня остальные технологии подтянулись в то время как CouchDB все еще полируют изначальную задумку.
Отличие от слоника в том что CouchDB это AP база, слоник CA.
>> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением
>> документов в том же Слоне?
> Сейчас нету смысла, 12 лет назад да эта БД считалась как прорыв,
> а сегодня остальные технологии подтянулись в то время как CouchDB все
> еще полируют изначальную задумку.больше - "ушли" в кочбэйз и его пилят активно
> Отличие от слоника в том что CouchDB это AP база, слоник
> CA.
Таки выпилили совсем Erlang?
> Таки выпилили совсем Erlang?стесняюсь спросить первоисточник такого предположения ;)
>> Таки выпилили совсем Erlang?
> стесняюсь спросить первоисточник такого предположения ;)Ну в статье этой ни одного упоминания
>>> Таки выпилили совсем Erlang?
>> стесняюсь спросить первоисточник такого предположения ;)
> Ну в статье этой ни одного упоминаниявы точно читали?
>> Для запуска CouchDB теперь требуется Erlang/OTP 20.3.8.11+, 21.2.3+ или 22.0.5. Теоретически сохранена работоспособность с веткой Erlang/OTP 19, но она не охвачена тестами.
Понимаю, что надежды мало, но спрошу: кто-нибудь пробовал запихнуть в неё ФИАС (к чему соблазняют шардинг и кластеризация) и делать поиск по нему?
> Понимаю, что надежды мало, но спрошу: кто-нибудь пробовал запихнуть в неё ФИАС
> (к чему соблазняют шардинг и кластеризация) и делать поиск по нему?Запихнуть конечно можно и даже работать будет, она даже будет в нормально синхронизироваться между регионами. Только учтите что нужно 2 раза больше места на диске чем сама база, запись медленная. можете еще посмотреть на riak если вам так нужна распространенность. А лучше опишите свои требования и спросите в tg на канале тарантула сможет Tarantool то что вам нужно или нет.
> riak
> TarantoolСпасибо, пощупаю
Как она, по сравнению в MongoDB? Интересно послушать тех, кто имеет опыт разработки под обе.
Опыт разработки в наше время это ни о чём, увы. Каждый хвалит свой опыт.
> Как она, по сравнению в MongoDB?конкретно кочДБ ориентирован на несколько иные задачи (если так можно выразиться)
+ ограничение для "файла" помещенного в БД - 4Гб (ЕМНИП)стоит сравнивать с кочбэйз...
https://www.couchbase.com/comparing-couchbase-vs-mongodb
бенчи еще для 5.5 версии (текущая 6.5 )
https://resources.couchbase.com/c/altoros-nosql-performance-...единственный момент - файлы в базе хранить не получится (ограничение по размеру) и надо будет кастылить что-то своё
хотя с т.з. хранить "большие" файлы в БД - это не совсем "правильно" ;)
Заюзал предыдущую версию как кэш json данных. По началу было не плохо. Данные сжимаются, бегают. Можно было слейвов натыкать, если бы в производительность стал упираться. Только не работает она. При одном живом мастере постоянно ругается на конфликты записей, при обновлении записи.
В общем не работает.
Сейчас PostgreSQL с типом jsonb и индексами GIS намного круче.
