Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск документоориентированной СУБД Apache CouchDB 3.0 "	+/–
Сообщение от opennews (??), 02-Мрт-20, 12:22
Состоялся релиз распределённой документоориентированной базы данных Apache CouchDB 3.0, относящейся к классу NoSQL-систем. Исходные тексты проекта распространяются под лицензией Apache 2.0... Подробнее: https://www.opennet.me/opennews/art.shtml?num=52463
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Василий (??), 02-Мрт-20, 12:22	–2 +/–
Полнотекстовый поиск добавили?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #24

2. Сообщение от Ан (??), 02-Мрт-20, 12:34	+/–
Апаче могильник, апаче могильник, повторяют постоянно на опеннете. Пилится и шиперится....
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

3. Сообщение от Аноним (3), 02-Мрт-20, 12:41	–2 +/–
Ну ладно, колумбарий
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

4. Сообщение от none_first (ok), 02-Мрт-20, 13:12	+1 +/–
> Полнотекстовый поиск добавили? >>В состав включён поисковый движок 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от none_first (ok), 02-Мрт-20, 13:17	+1 +/–
интересная БД, учитывая историю её появления, создателя (Damien Katz) и развитие в виде couchbase
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от NameName (?), 02-Мрт-20, 17:23	–1 +/–
А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением документов в том же Слоне?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #25

7. Сообщение от none_first (ok), 02-Мрт-20, 17:26	–1 +/–
> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением > документов в том же Слоне? попробуйте в jsonb с запросами и возможно вопросы отпадут ;) и хотя couchbase несколько другой продукт https://query-tutorial.couchbase.com/tutorial/#1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8, #12

8. Сообщение от NameName (?), 02-Мрт-20, 18:15	–1 +/–
Так а преимущества-то в чём? Как я понял, в том, что, если в Слоне хранить jsonb, то как-то не так будут работать запросы? Сомневаюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от none_first (ok), 02-Мрт-20, 18:31	+/–
> Так а преимущества-то в чём? > Как я понял, в том, что, если в Слоне хранить jsonb, то > как-то не так будут работать запросы? Сомневаюсь. сложнее обслуживание и масштабирование, синтаксис "несколько сложноват", с ключами есть свои особенности, тулинг ещё не весь не везде, с документацией по jsonb не шибко, нужно описывать данные... https://blog.couchbase.com/postgres-jsonb-and-nosql/ бенчей нет - скорость сравнить проблематично и кочбэйз мастер-мастер, с достаточно простой клатеризацией и прочими плюшками НО это все не про кочДБ ;) там тоже мастер-мастер, но нет мемори-фёст и нет n1ql
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10, #11

10. Сообщение от NameName (?), 02-Мрт-20, 18:40	+/–
Понятно, это для тех, у кого json головного мозга. И, соответственно, главное требование к "СУБД", чтоб яваскриптик и ясон. И, да, мемори фёст. Можно подумать где-то мемори не фёст. Мастер-мастеров не бывает. Ну не бывает. Мастер-мастер это как сказать ребёнку, что пальцы можно пихать в розетку, главное их сначала заточить, чтобы они в эту розетку влезли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #17

11. Сообщение от NameName (?), 02-Мрт-20, 18:43	+/–
К слову, там в статье такая дичь дикая написана. Какие-то миллионы миллиардов join-ов в РСУБД. Что за чушь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13, #36

12. Сообщение от NameName (?), 02-Мрт-20, 18:50	+3 +/–
В общем, преимущество одно -- если у вас есть специалист, который что-то там лабал на яваскрипте или пехепе, то ему не нужно будет разбираться в особенностях реляционного моделирования и декларативных языках запросов. Что, в общем-то, неплохой такой плюс. А минусы? Типичны. Нет транзакционной и структурой целостности, нет изоляций, модель "не защищает себя сама".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #14

13. Сообщение от NameName (?), 02-Мрт-20, 18:52	+/–
... да и нет никакой проблемы хоть в квинтиллионе joins-ов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

14. Сообщение от none_first (ok), 02-Мрт-20, 19:15	+/–
> В общем, преимущество одно -- если у вас есть специалист, который что-то > там лабал на яваскрипте или пехепе, то ему не нужно будет > разбираться в особенностях реляционного моделирования и декларативных языках запросов. > Что, в общем-то, неплохой такой плюс. А минусы? Типичны. Нет транзакционной у кочбэйз ACID https://blog.couchbase.com/couchbase-brings-distributed-mult.../ > и структурой целостности, нет изоляций, модель "не защищает себя сама". "реляционное моделирование" не всегда нужно (чаще не нужно), зачем оверинжиниринг?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15, #16

15. Сообщение от Ээээ (?), 02-Мрт-20, 19:25	+/–
Нет. ACID-а там в принципе быть не может. Обеспечивается целостность только на уровне записи, но не документа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #19

16. Сообщение от Ээээ (?), 02-Мрт-20, 19:31	–3 +/–
Не нужно кому и для чего? Если у вас есть ОО-модель, то ОРМ сам вам всё разложит. И поэтому никакое моделирование и не потребуется. Другое дело, что реляционные модели просто эффективней. Т.е. надёжно хранить что-то, надёжно изменять что-то, искать что-то или агрегировать что-то куда проще по реляционной модели (даже если вы никак с ней напрямую не работаете). Поэтому мне и не ясно зачем хранить сериализацию состояний объектов (пусть и в ясон-представлении), вместо того, чтобы давать указания "проигрывать" реляционную модель. Ведь выгоды никакой вообще, а издержек масса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #20

17. Сообщение от Аноним (17), 02-Мрт-20, 19:36	–1 +/–
> не бывает Вот это новость. Плохой опыт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

18. Сообщение от qsdg (ok), 02-Мрт-20, 19:45	+/–
Таки выпилили совсем Erlang?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21

19. Сообщение от none_first (ok), 02-Мрт-20, 20:17	+2 +/–
> Нет. 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...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #31

20. Сообщение от none_first (ok), 02-Мрт-20, 20:24	+1 +/–
> Не нужно кому и для чего? Если у вас есть ОО-модель, то > ОРМ сам вам всё разложит. И поэтому никакое моделирование и не > потребуется. Другое дело, что реляционные модели просто эффективней. Т.е. надёжно хранить > что-то, надёжно изменять что-то, искать что-то или агрегировать что-то куда проще > по реляционной модели (даже если вы никак с ней напрямую не > работаете). Поэтому мне и не ясно зачем хранить сериализацию состояний объектов > (пусть и в ясон-представлении), вместо того, чтобы давать указания "проигрывать" реляционную > модель. Ведь выгоды никакой вообще, а издержек масса. ну как-то вот живут ;) https://habr.com/ru/post/436762/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #32, #34, #35

21. Сообщение от none_first (ok), 02-Мрт-20, 20:44	+/–
> Таки выпилили совсем Erlang? стесняюсь спросить первоисточник такого предположения ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23

22. Сообщение от YetAnotherOnanym (ok), 02-Мрт-20, 21:37	+/–
Понимаю, что надежды мало, но спрошу: кто-нибудь пробовал запихнуть в неё ФИАС (к чему соблазняют шардинг и кластеризация) и делать поиск по нему?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

23. Сообщение от qsdg (ok), 02-Мрт-20, 22:44	–1 +/–
>> Таки выпилили совсем Erlang? > стесняюсь спросить первоисточник такого предположения ;) Ну в статье этой ни одного упоминания
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29

24. Сообщение от GentooBoy (ok), 03-Мрт-20, 04:07	+/–
добавили простое взаимодействие с lucene, в коммерческом продукте Cloudant lucene  идет из коробки. Так что фактически подтянули функциональность до приемлемого уровня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

25. Сообщение от GentooBoy (ok), 03-Мрт-20, 04:20	+1 +/–
> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением > документов в том же Слоне? Сейчас нету смысла, 12 лет назад да эта БД считалась как прорыв, а сегодня остальные технологии подтянулись в то время как CouchDB все еще полируют изначальную задумку. Отличие от слоника в том что CouchDB это AP  база, слоник CA.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #30

26. Сообщение от GentooBoy (ok), 03-Мрт-20, 04:30	+/–
> Понимаю, что надежды мало, но спрошу: кто-нибудь пробовал запихнуть в неё ФИАС > (к чему соблазняют шардинг и кластеризация) и делать поиск по нему? Запихнуть конечно можно и даже работать будет, она даже будет в нормально синхронизироваться между регионами. Только учтите что нужно 2 раза больше места на диске чем сама база, запись медленная. можете еще посмотреть на riak  если вам так нужна распространенность. А лучше опишите свои требования и спросите в tg  на канале тарантула сможет Tarantool то что вам нужно или нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27

27. Сообщение от YetAnotherOnanym (ok), 03-Мрт-20, 11:30	+/–
> riak > Tarantool Спасибо, пощупаю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

28. Сообщение от qq (??), 03-Мрт-20, 12:11	+/–
Как она, по сравнению в MongoDB? Интересно послушать тех, кто имеет опыт разработки под обе.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #39

29. Сообщение от none_first (ok), 03-Мрт-20, 12:45	+/–
>>> Таки выпилили совсем Erlang? >> стесняюсь спросить первоисточник такого предположения ;) > Ну в статье этой ни одного упоминания вы точно читали? >> Для запуска CouchDB теперь требуется Erlang/OTP 20.3.8.11+, 21.2.3+ или 22.0.5. Теоретически сохранена работоспособность с веткой Erlang/OTP 19, но она не охвачена тестами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

30. Сообщение от none_first (ok), 03-Мрт-20, 12:49	+/–
>> А зачем оно? Кто-то может объяснить в чём преимущества, скажем, перед хранением >> документов в том же Слоне? > Сейчас нету смысла, 12 лет назад да эта БД считалась как прорыв, > а сегодня остальные технологии подтянулись в то время как CouchDB все > еще полируют изначальную задумку. больше - "ушли" в кочбэйз и его пилят активно > Отличие от слоника в том что CouchDB это AP  база, слоник > CA.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

31. Сообщение от Ээээ (?), 03-Мрт-20, 16:50	+/–
Да, но тут скорее не спор, а то, что в документации просто манипулируют понятием.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #41

32. Сообщение от Ээээ (?), 03-Мрт-20, 16:50	+/–
хабр? фу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

33. Сообщение от NameName (?), 03-Мрт-20, 17:56	+/–
Опыт разработки в наше время это ни о чём, увы. Каждый хвалит свой опыт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

34. Сообщение от Масса (?), 03-Мрт-20, 19:07	+/–
Это просто модно так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

35. Сообщение от Масса (?), 03-Мрт-20, 19:14	+/–
Люди пишут, что в ряде случаев, "чтобы работало быстрее" они отказываются от транзакционной надёжности. Есть большой накопитель "в памяти", с предельно денормализованный моделью, который и принимает решения, а затем уже принятое таким образом решение дублируется относительно медленной обычной реляционной транзакционной СУБД. Решение вполне сносное: "накопитель в памяти" относительно их требований вполне надёжен, "грязь" в случае сбоя редка и решается административно и персонально. Но тут коуч используется не как СУБД, а как кэш (накопитель), персистируют же данные вполне традиционно -- в толстый реляционный надёжный Оракл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #42

36. Сообщение от ананчик (?), 04-Мрт-20, 04:15	+/–
Denis Rosa, Developer Advocate, Couchbase on August 6, 2019 Просто бизнес, в раше кстати кто то из опсосов пользует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #38

37. Сообщение от Аноним (37), 04-Мрт-20, 09:42	+/–
Заюзал предыдущую версию как кэш json данных. По началу было не плохо. Данные сжимаются, бегают. Можно было слейвов натыкать, если бы в производительность стал упираться. Только не работает она. При одном живом мастере постоянно ругается на конфликты записей, при обновлении записи. В общем не работает.
Ответить | Правка | Наверх | Cообщить модератору

38. Сообщение от Люся (?), 04-Мрт-20, 10:50	+/–
Бизнес не бизнес, а дело в том, что в статье (это, кстати, типично для евангелистов NoSQL) перевирается работа с реляционными СУБД. С ними есть проблемы, но совершенно другие. Т.е. текст статье орёт просто о том, что писавший её с реляционными СУБД не работал никогда, а труд его жизни это статейки обо всём на свете крапать (завидное умение).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

39. Сообщение от none_first (ok), 04-Мрт-20, 13:09	+/–
> Как она, по сравнению в MongoDB? конкретно кочДБ ориентирован на несколько иные задачи (если так можно выразиться) + ограничение для "файла" помещенного в БД - 4Гб (ЕМНИП) стоит сравнивать с кочбэйз... https://www.couchbase.com/comparing-couchbase-vs-mongodb бенчи еще для 5.5 версии (текущая 6.5 ) https://resources.couchbase.com/c/altoros-nosql-performance-... единственный момент - файлы в базе хранить не получится (ограничение по размеру) и надо будет кастылить что-то своё хотя с т.з. хранить "большие" файлы в БД - это не совсем "правильно" ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

40. Сообщение от Аноним (40), 04-Мрт-20, 17:40	+/–
Сейчас PostgreSQL с типом jsonb и индексами GIS намного круче.
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от none_first (ok), 05-Мрт-20, 19:33	+/–
> Да, но тут скорее не спор, а то, что в документации просто > манипулируют понятием. дык напишите прям там, развенчайте "манипуляцию", примерчики подкиньте - где не будет работать как написано Сервер доступен дя скачивания, тулинг для многих ЯП https://docs.couchbase.com/java-sdk/3.0/howtos/distributed-a...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #46

42. Сообщение от none_first (ok), 05-Мрт-20, 19:38	+/–
> Люди пишут, что в ряде случаев, "чтобы работало быстрее" они отказываются от > транзакционной надёжности. Есть большой накопитель "в памяти", с предельно денормализованный > моделью, который и принимает решения, а затем уже принятое таким образом > решение дублируется относительно медленной обычной реляционной транзакционной СУБД. > Решение вполне сносное: "накопитель в памяти" относительно их требований вполне надёжен, > "грязь" в случае сбоя редка и решается административно и персонально. Но > тут коуч используется не как СУБД, а как кэш (накопитель), персистируют > же данные вполне традиционно -- в толстый реляционный надёжный Оракл. "написано" (в каментах) на предложение "другой" модели но с рсубд, что трудозатраты были бы выше, чем даже переписать под новый движок https://habr.com/ru/post/436762/#comment_19640432
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #43

43. Сообщение от Нама (?), 06-Мрт-20, 18:29	+/–
Это всё похоже на бла-бла-бла. Обчитался потциент Клипмана вот и произошёл такой вот прецедент. В индустрии же важно быть модным. Чтоб движуха была, а то динозавром заклеймят. Из статьи не понял зачем там объективно NoSQL. Больной жаловался на то, что "Оракл много транзакций не может". Может. До одури много может. Потолок в ярд явно надуман. Не вижу что там в этот ярд может упереться. И совершенно мне не ясно зачем там объектный кэш для повышения оперативности реакции. Буквально, автор утверждает, что алгоритмы поиска в памяти у Коуча быстрее, чем у Оракла. Что-то очень-очень сомнительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #44

44. Сообщение от none_first (ok), 06-Мрт-20, 18:59	+/–
> Это всё похоже на бла-бла-бла. Обчитался потциент Клипмана вот и произошёл такой > вот прецедент. В индустрии же важно быть модным. Чтоб движуха была, > а то динозавром заклеймят. > Из статьи не понял зачем там объективно NoSQL. Больной жаловался на то, > что "Оракл много транзакций не может". Может. До одури много может. > Потолок в ярд явно надуман. Не вижу что там в этот > ярд может упереться. И совершенно мне не ясно зачем там объектный > кэш для повышения оперативности реакции. Буквально, автор утверждает, что алгоритмы поиска > в памяти у Коуча быстрее, чем у Оракла. Что-то очень-очень сомнительно. ну сделайте проект - докажите обратное, вы же "уверены" ;) Мариот - тоже кучу всего перепробывал, ушел на коуч - SQL захлебывался, почитайет по ссылкам. иБэй заюзал коуч https://www.youtube.com/watch?v=2GZA5SrWlvk&feature=youtu.be Маркетинг - ну есть, не без этого, но это большой бизнес и просто на шару ввязаться в масштабный проект с заменой движка... звучит более сомнительно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #45

45. Сообщение от Айяйяй (?), 07-Мрт-20, 00:05	+/–
Да, мы все очень злы к друг другу -- сразу бросаемся разоблачать и сомневаться. Объективно, в статье не достаточно исходных данных. Поэтому и включается опыт (и дремучие инстинкты). А мой опыт твердит, что NoSQL это совсем ни к чему. Это один из симптомов куда более выше расположившейся болезни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

46. Сообщение от Айяйяй (?), 07-Мрт-20, 00:14	+/–
Зачем и для кого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема