| |
| 2.24, GentooBoy (ok), 04:07, 03/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
 добавили простое взаимодействие с lucene, в коммерческом продукте Cloudant lucene идет из коробки.
Так что фактически подтянули функциональность до приемлемого уровня.
| | |
|
| 1.5, none_first (ok), 13:17, 02/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 интересная БД, учитывая историю её появления, создателя (Damien Katz) и развитие в виде couchbase
| | |
| 1.6, NameName (?), 17:23, 02/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением документов в том же Слоне?
| | |
| |
| |
| 3.8, NameName (?), 18:15, 02/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Так а преимущества-то в чём?
Как я понял, в том, что, если в Слоне хранить jsonb, то как-то не так будут работать запросы? Сомневаюсь.
| | |
| |
| 4.9, none_first (ok), 18:31, 02/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Так а преимущества-то в чём?
> Как я понял, в том, что, если в Слоне хранить jsonb, то
> как-то не так будут работать запросы? Сомневаюсь.
сложнее обслуживание и масштабирование, синтаксис "несколько сложноват", с ключами есть свои особенности, тулинг ещё не весь не везде, с документацией по jsonb не шибко, нужно описывать данные...
https://blog.couchbase.com/postgres-jsonb-and-nosql/
бенчей нет - скорость сравнить проблематично
и кочбэйз мастер-мастер, с достаточно простой клатеризацией и прочими плюшками
НО это все не про кочДБ ;) там тоже мастер-мастер, но нет мемори-фёст и нет n1ql
| | |
| |
| 5.10, NameName (?), 18:40, 02/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Понятно, это для тех, у кого json головного мозга. И, соответственно, главное требование к "СУБД", чтоб яваскриптик и ясон. И, да, мемори фёст. Можно подумать где-то мемори не фёст.
Мастер-мастеров не бывает. Ну не бывает. Мастер-мастер это как сказать ребёнку, что пальцы можно пихать в розетку, главное их сначала заточить, чтобы они в эту розетку влезли.
| | |
| 5.11, NameName (?), 18:43, 02/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
К слову, там в статье такая дичь дикая написана. Какие-то миллионы миллиардов join-ов в РСУБД. Что за чушь.
| | |
| |
| 6.36, ананчик (?), 04:15, 04/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Denis Rosa, Developer Advocate, Couchbase on August 6, 2019
Просто бизнес, в раше кстати кто то из опсосов пользует
| | |
| |
| 7.38, Люся (?), 10:50, 04/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Бизнес не бизнес, а дело в том, что в статье (это, кстати, типично для евангелистов NoSQL) перевирается работа с реляционными СУБД. С ними есть проблемы, но совершенно другие. Т.е. текст статье орёт просто о том, что писавший её с реляционными СУБД не работал никогда, а труд его жизни это статейки обо всём на свете крапать (завидное умение).
| | |
|
|
|
|
| 3.12, NameName (?), 18:50, 02/03/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
В общем, преимущество одно -- если у вас есть специалист, который что-то там лабал на яваскрипте или пехепе, то ему не нужно будет разбираться в особенностях реляционного моделирования и декларативных языках запросов. Что, в общем-то, неплохой такой плюс. А минусы? Типичны. Нет транзакционной и структурой целостности, нет изоляций, модель "не защищает себя сама".
| | |
| |
| 4.14, none_first (ok), 19:15, 02/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> В общем, преимущество одно -- если у вас есть специалист, который что-то
> там лабал на яваскрипте или пехепе, то ему не нужно будет
> разбираться в особенностях реляционного моделирования и декларативных языках запросов.
> Что, в общем-то, неплохой такой плюс. А минусы? Типичны. Нет транзакционной
у кочбэйз ACID https://blog.couchbase.com/couchbase-brings-distributed-multi-document-acid-tr
> и структурой целостности, нет изоляций, модель "не защищает себя сама".
"реляционное моделирование" не всегда нужно (чаще не нужно), зачем оверинжиниринг?
| | |
| |
| 5.15, Ээээ (?), 19:25, 02/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Нет. ACID-а там в принципе быть не может. Обеспечивается целостность только на уровне записи, но не документа.
| | |
| |
| |
| 7.31, Ээээ (?), 16:50, 03/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Да, но тут скорее не спор, а то, что в документации просто манипулируют понятием.
| | |
|
|
| 5.16, Ээээ (?), 19:31, 02/03/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
Не нужно кому и для чего? Если у вас есть ОО-модель, то ОРМ сам вам всё разложит. И поэтому никакое моделирование и не потребуется. Другое дело, что реляционные модели просто эффективней. Т.е. надёжно хранить что-то, надёжно изменять что-то, искать что-то или агрегировать что-то куда проще по реляционной модели (даже если вы никак с ней напрямую не работаете). Поэтому мне и не ясно зачем хранить сериализацию состояний объектов (пусть и в ясон-представлении), вместо того, чтобы давать указания "проигрывать" реляционную модель. Ведь выгоды никакой вообще, а издержек масса.
| | |
| |
| 6.20, none_first (ok), 20:24, 02/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Не нужно кому и для чего? Если у вас есть ОО-модель, то
> ОРМ сам вам всё разложит. И поэтому никакое моделирование и не
> потребуется. Другое дело, что реляционные модели просто эффективней. Т.е. надёжно хранить
> что-то, надёжно изменять что-то, искать что-то или агрегировать что-то куда проще
> по реляционной модели (даже если вы никак с ней напрямую не
> работаете). Поэтому мне и не ясно зачем хранить сериализацию состояний объектов
> (пусть и в ясон-представлении), вместо того, чтобы давать указания "проигрывать" реляционную
> модель. Ведь выгоды никакой вообще, а издержек масса.
ну как-то вот живут ;) https://habr.com/ru/post/436762/
| | |
| |
| 7.35, Масса (?), 19:14, 03/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Люди пишут, что в ряде случаев, "чтобы работало быстрее" они отказываются от транзакционной надёжности. Есть большой накопитель "в памяти", с предельно денормализованный моделью, который и принимает решения, а затем уже принятое таким образом решение дублируется относительно медленной обычной реляционной транзакционной СУБД. Решение вполне сносное: "накопитель в памяти" относительно их требований вполне надёжен, "грязь" в случае сбоя редка и решается административно и персонально. Но тут коуч используется не как СУБД, а как кэш (накопитель), персистируют же данные вполне традиционно -- в толстый реляционный надёжный Оракл.
| | |
| |
| |
| 9.43, Нама (?), 18:29, 06/03/2020 [^] [^^] [^^^] [ответить] | +/– | Это всё похоже на бла-бла-бла Обчитался потциент Клипмана вот и произошёл такой... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 2.25, GentooBoy (ok), 04:20, 03/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением
> документов в том же Слоне?
Сейчас нету смысла, 12 лет назад да эта БД считалась как прорыв, а сегодня остальные технологии подтянулись в то время как CouchDB все еще полируют изначальную задумку.
Отличие от слоника в том что CouchDB это AP база, слоник CA.
| | |
| |
| 3.30, none_first (ok), 12:49, 03/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением
>> документов в том же Слоне?
> Сейчас нету смысла, 12 лет назад да эта БД считалась как прорыв,
> а сегодня остальные технологии подтянулись в то время как CouchDB все
> еще полируют изначальную задумку.
больше - "ушли" в кочбэйз и его пилят активно
> Отличие от слоника в том что CouchDB это AP база, слоник
> CA. | | |
|
|
| |
| 2.21, none_first (ok), 20:44, 02/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Таки выпилили совсем Erlang?
стесняюсь спросить первоисточник такого предположения ;)
| | |
| |
| 3.23, qsdg (ok), 22:44, 02/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 >> Таки выпилили совсем Erlang?
> стесняюсь спросить первоисточник такого предположения ;)
Ну в статье этой ни одного упоминания
| | |
| |
| 4.29, none_first (ok), 12:45, 03/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
>>> Таки выпилили совсем Erlang?
>> стесняюсь спросить первоисточник такого предположения ;)
> Ну в статье этой ни одного упоминания
вы точно читали?
>> Для запуска CouchDB теперь требуется Erlang/OTP 20.3.8.11+, 21.2.3+ или 22.0.5. Теоретически сохранена работоспособность с веткой Erlang/OTP 19, но она не охвачена тестами. | | |
|
|
|
| 1.22, YetAnotherOnanym (ok), 21:37, 02/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Понимаю, что надежды мало, но спрошу: кто-нибудь пробовал запихнуть в неё ФИАС (к чему соблазняют шардинг и кластеризация) и делать поиск по нему?
| | |
| |
| 2.26, GentooBoy (ok), 04:30, 03/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Понимаю, что надежды мало, но спрошу: кто-нибудь пробовал запихнуть в неё ФИАС
> (к чему соблазняют шардинг и кластеризация) и делать поиск по нему?
Запихнуть конечно можно и даже работать будет, она даже будет в нормально синхронизироваться между регионами. Только учтите что нужно 2 раза больше места на диске чем сама база, запись медленная. можете еще посмотреть на riak если вам так нужна распространенность. А лучше опишите свои требования и спросите в tg на канале тарантула сможет Tarantool то что вам нужно или нет.
| | |
|
| 1.28, qq (??), 12:11, 03/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Как она, по сравнению в MongoDB? Интересно послушать тех, кто имеет опыт разработки под обе.
| | |
| |
| 2.33, NameName (?), 17:56, 03/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Опыт разработки в наше время это ни о чём, увы. Каждый хвалит свой опыт.
| | |
|
| 1.37, Аноним (37), 09:42, 04/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Заюзал предыдущую версию как кэш json данных. По началу было не плохо. Данные сжимаются, бегают. Можно было слейвов натыкать, если бы в производительность стал упираться. Только не работает она. При одном живом мастере постоянно ругается на конфликты записей, при обновлении записи.
В общем не работает.
| | |
|
