https://opennet.dev/openforum/vsluhforumID3/119942.html Состоялся релиз распределённой документоориентированной базы данных Apache CouchDB 3.0, относящейся к классу NoSQL-систем. Исходные тексты проекта распространяются под лицензией Apache 2.0...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52463<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#46 Fri, 06 Mar 2020 21:14:37 GMT Зачем и для кого?<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#45 Fri, 06 Mar 2020 21:05:33 GMT Да, мы все очень злы к друг другу -- сразу бросаемся разоблачать и сомневаться. Объективно, в статье не достаточно исходных данных. Поэтому и включается опыт (и дремучие инстинкты). А мой опыт твердит, что NoSQL это совсем ни к чему. Это один из симптомов куда более выше расположившейся болезни.<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#44 Fri, 06 Mar 2020 15:59:30 GMT &gt; Это всё похоже на бла-бла-бла. Обчитался потциент Клипмана вот и произошёл такой <br>&gt; вот прецедент. В индустрии же важно быть модным. Чтоб движуха была, <br>&gt; а то динозавром заклеймят.<br>&gt; Из статьи не понял зачем там объективно NoSQL. Больной жаловался на то, <br>&gt; что "Оракл много транзакций не может". Может. До одури много может. <br>&gt; Потолок в ярд явно надуман. Не вижу что там в этот <br>&gt; ярд может упереться. И совершенно мне не ясно зачем там объектный <br>&gt; кэш для повышения оперативности реакции. Буквально, автор утверждает, что алгоритмы поиска <br>&gt; в памяти у Коуча быстрее, чем у Оракла. Что-то очень-очень сомнительно. <br><br>ну сделайте проект - докажите обратное, вы же "уверены" ;)<br>Мариот - тоже кучу всего перепробывал, ушел на коуч - SQL захлебывался, почитайет по ссылкам.<br>иБэй заюзал коуч https://www.youtube.com/watch?v=2GZA5SrWlvk&feature=youtu.be<br>Маркетинг - ну есть, не без этого, но это большой бизнес и просто на шару ввязаться в масштабный проект с заменой движка... звучит более сомнительно<br><br> https://opennet.dev/openforum/vsluhforumID3/119942.html#43 Fri, 06 Mar 2020 15:29:38 GMT Это всё похоже на бла-бла-бла. Обчитался потциент Клипмана вот и произошёл такой вот прецедент. В индустрии же важно быть модным. Чтоб движуха была, а то динозавром заклеймят.<br>Из статьи не понял зачем там объективно NoSQL. Больной жаловался на то, что "Оракл много транзакций не может". Может. До одури много может. Потолок в ярд явно надуман. Не вижу что там в этот ярд может упереться. И совершенно мне не ясно зачем там объектный кэш для повышения оперативности реакции. Буквально, автор утверждает, что алгоритмы поиска в памяти у Коуча быстрее, чем у Оракла. Что-то очень-очень сомнительно.<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#42 Thu, 05 Mar 2020 16:38:22 GMT &gt; Люди пишут, что в ряде случаев, "чтобы работало быстрее" они отказываются от <br>&gt; транзакционной надёжности. Есть большой накопитель "в памяти", с предельно денормализованный <br>&gt; моделью, который и принимает решения, а затем уже принятое таким образом <br>&gt; решение дублируется относительно медленной обычной реляционной транзакционной СУБД. <br>&gt; Решение вполне сносное: "накопитель в памяти" относительно их требований вполне надёжен, <br>&gt; "грязь" в случае сбоя редка и решается административно и персонально. Но <br>&gt; тут коуч используется не как СУБД, а как кэш (накопитель), персистируют <br>&gt; же данные вполне традиционно -- в толстый реляционный надёжный Оракл.<br><br>"написано" (в каментах) на предложение "другой" модели но с рсубд, что трудозатраты были бы выше, чем даже переписать под новый движок<br>https://habr.com/ru/post/436762/#comment_19640432<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#41 Thu, 05 Mar 2020 16:33:19 GMT &gt; Да, но тут скорее не спор, а то, что в документации просто <br>&gt; манипулируют понятием.<br><br>дык напишите прям там, развенчайте "манипуляцию", примерчики подкиньте - где не будет работать как написано<br>Сервер доступен дя скачивания, тулинг для многих ЯП<br>https://docs.couchbase.com/java-sdk/3.0/howtos/distributed-acid-transactions-from-the-sdk.html<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#40 Wed, 04 Mar 2020 14:40:56 GMT Сейчас PostgreSQL с типом jsonb и индексами GIS намного круче.<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#39 Wed, 04 Mar 2020 10:09:54 GMT &gt; Как она, по сравнению в MongoDB?<br><br>конкретно кочДБ ориентирован на несколько иные задачи (если так можно выразиться)<br>+ ограничение для "файла" помещенного в БД - 4Гб (ЕМНИП)<br><br>стоит сравнивать с кочбэйз...<br>https://www.couchbase.com/comparing-couchbase-vs-mongodb<br>бенчи еще для 5.5 версии (текущая 6.5 )<br>https://resources.couchbase.com/c/altoros-nosql-performance-benchmark?x=N-I_ik<br><br>единственный момент - файлы в базе хранить не получится (ограничение по размеру) и надо будет кастылить что-то своё<br>хотя с т.з. хранить "большие" файлы в БД - это не совсем "правильно" ;)<br> https://opennet.dev/openforum/vsluhforumID3/119942.html#38 Wed, 04 Mar 2020 07:50:19 GMT Бизнес не бизнес, а дело в том, что в статье (это, кстати, типично для евангелистов NoSQL) перевирается работа с реляционными СУБД. С ними есть проблемы, но совершенно другие. Т.е. текст статье орёт просто о том, что писавший её с реляционными СУБД не работал никогда, а труд его жизни это статейки обо всём на свете крапать (завидное умение).<br>