Пытаюсь на NoSQL базе данных (CouchDB) сделать аналог 1С-ных Регистров накопления (остатки и обороты).

К примеру банальная задача остатков товаров на складах и документов движения (приход/расход).

Если сделать остатки через reduce-функцию то проблема что при добавлении/изменении документа движения будет происходить полный пересчет по всем документам.

В 1С это решали например хранением промежуточных итогов на начало каждого месяца и на лету считаем документы с начала нужного месяца чтобы получить итог на требуемую дату.

Вот как бы красиво извратиться на CoudhDB?
Причем чтобы не потерять возможность распараллеливания (и ускорения) вычислений остатков на нодах кластера?

(0) Ну и сделай еще одну коллекцию (или как там оно называется) с промежуточными остатками

В записях придумай признак актуальности. При записи движений "задним числом" сбрасывай признак, и каким-нибудь регламентом пересчитывай.

(1) Ага, т.е. на каждый месяц создаем свою коллекцию а все последующие используют только одну предыдущую.

Т.е. поменяли в прошлом месяце документ, пересчитается только текущий месяц начало а прошлые не трогаются так?

(2) Там фишка что ничего придумывать не надо все встроено эти признаки ))

Операция filter там есть?

(5) Есть map-функции которые пересчитываются только для измененных доков, это и есть некий фильтр для reduce.

Они выдают готовую выборку, каждый документ превращается в 0 или несколько "записей" в этой "выборке".

(6)* 0, 1 или несколько

(6) Это как? По идеологии, map работает со всей коллекцией.

(8) Он работает по отдельности с каждым элементом и считается только для тех которые изменили ))

(9)+ Фишка в офигенной распареллеливании операции filter из коробки, на RDBMS один "select" фига с два так распараллелишь

(10)+ Недостаток оно место на диске жрет как не в себе и удаление данных не помогает почти

(10) nosql придуман совсем не для @filter@ и работает оно про определению хуже реляционных колоночных БД

а костыли с отдельными объектами-фильтрами, хранящими в себе ключи объектов, удовлетворяющих фильтрам - это намного хуже, чем индексы

(12) Не хуже/лучше, а просто "по другому".
Смотри вот у тебя есть 10 компов, попробуй используя их ускорить работу одной базы обычной реляционной БД?

(0) это как мартышке хобот пришить. Оно придумано не для этих задач

(14) в какой конкретно задаче?

(14) твоему велосипеду понадобятся эти самые 10 компов, чтобы только обеспечить сравнимую с реляцинной БД производительность...

(16) В задаче @filter@ - обычный select с условием

можно сделать кластеризацию таблиц по хеш-ключам какого-нибудь индекса основного или зеркалирование и распараллеливание на этапе запроса.

(17) Для одного юзера да, но особенность что даже 1000 юзеров будет работать так же как 1 на этих 10 компах-серврах ))

(19) Очень смешно, тут ничего специально делать на CouchDB не надо, как для одной ноды так и для кластера один код функций mapreduce

(20) ну, пока это просто слова.
Кроме того, в результате этой твоей деятельности получится эдакая машина руба голдберга, которую упорешься майнтейнить, мне кажется.

(18) вот именно, что nosql придуман для хранения неструктурированной информации, и отдельные признаки "структур" хранятся также - ключ - значение фильтра, значение - список ключей. из-за этого очень много накладных расходов именно на такое использование.
и если денормализация при увеличении нагрузки в реляционных БД делается очень просто, то материализрованные фильтры "mongo работают очень быстро, пока файл данных не превышает оперативныую память" - это очень смешно...

(22) Подумай как вк и прочие фэйсбуки считают лайки?

(23) У rdbms проблема что добавление памяти не сильно помогает, упираемся в cpu.
Тут же легкость заюзать нужное кол-во cpu как и сколько угодно памяти.

(21) ну, если СУБД изначально разрабатывалась для кластеров - то ничего делать и не надо. если нет - то надо. если реализация кластера коучдб скрыта от тебя, то это не значит, что её нет. точно также оракл/мсскуль/постгре/майэскуэль можно настроить в работе в кластере, используя стратегии, подходящие для конкретных задач.

(24) у них взрослые ЦОДы с взрослыми вычислительными ресурсами. Они на вот эти хороводы из десяти писюков, в едином порыве реализующих одну БД, водить не станут. Ибо это дороже и вообще - пороховая бочка.

а с самого начала автору надо посмотреть, что такое map/reduce, а потом покурить, например, про materialized view в постгре

(27) Речь не про "хороводы писюков", в этих "взрослые ЦОДы" никакие MSSQL|ORACLE не помогут без применения NoSQL в нужных местах.

(29) ну, а вот ты задумал хреновину, с помощью которой и nosql помогать перестанет

(28) Думаем что движок реляционной БД не заточенный для NoSQL, в который прикрутили "materialized view" справляется лучше чем заточенная NoSQL изначально с этими view?

тут я понимаю цель не в том чтобы победить реляционные дб, а просто изучить как работает носкл

(29) да, только реализация РН - это не то самое "нужное место". тебе нужно обеспечить ACID, так что используй подходящие средства

(30) nosql это не просто хранилище пар ключ/значение а много больше

(31) а materialized view - это не nosql, это типа таблиц итогов. nosql в задаче (0) вообще нафиг не нужен

(34) да, но зачем делать из апельсина грушу?

(33) ACID (точнее некий аналог) в данном представителе NoSQL есть "из коробки" в виде "ревизий документов".

nosql в постгре - это скорее json колонки

(31) Ну, вообще-то, для "всего такого" давным давно придумали OLAP. Который, суть, и есть хранилище заранее рассчитанных данных. И, да, пересчет кубов — это небыстрая и нечастая операция.

(37) ну давай, реализуй мне контроль остатков для двух параллельно работающих пользователей.

Для простого хранения пар ключ / значение есть более специализированные инструменты

(35) (36) ОК не получится груша, вернусь к апельсинам или даже яблокам ))

ну, да, - каким-то таким же образом придумали анальный секс

(40) А вот это был следующий вопрос )) Уже тоже подумал что прикольно получается

(44) стоя, в гамаке и под ёжин сбажин?

(44)+ Когда проводим документу - а реальные остатки видим по отчетам только через некоторое время.

Но есть в помощь что видно что остатки сча не совсем актуальные и еще считаются!!

(46) извините, я не могу сделать для вас резерв, так как не знаю, хватит ли товара на складе...

(47) гыгыгы - ага когда при прикидывании структуры вышла такая фигня ржал ))

(48)+ Но учитывая что дофига торговиков работают "закрывая минуса" уже отгруженные то?

(37) А можешь на пальцах объяснить как ACID реализован?
Я себе слабо представляю, как http-сервер (а CouchDB снаружи выглядит им, и работает через http) может выполнить insert/update + delete в два вызова, не сломав ACID?

(47) Это выглядит как сначала делаем резерв и работаем дальше без тормозов.
А потом оно сообщает через некоторое время - "резерв сделать не удалось".
И пущай юзер думает дальше ))

(49) молодцы. теперь давай придумаем wms, которой приходят задания на сборку с конкретных мест, но мы не знаем, сколько на конкретном месте лежит товара...

(50) Документы имеют "ревизии", при считывании дока ее получаем.
При попытке сохранить документу передаем старую считанную ревизию, если мы опоздали и кто то переделал док то выйдет ошибка.
Или док сохранится и получит новую ревизию.

(51) херовенький выход

(53)+ "Ревизия" это просто длинный номер-число который все увеличивается при каждом сохранении/изменении.

(54) Думаешь для юзеров лучше ждать сидя тоскливо перед экраном когда там документа проведется?

(53) Не, такой сценарий из реляционной жизни:
1. Открыли транзакцию;
2. update'нули запись в одной таблице;
3. delete'нули запись из другой таблицы, если в третьей таблице select'нулось нужное и подходящее.
4. Если чего-то не select'нулось, то все откатить, иначе зафиксироваться.

(53) ну собственно в 1с точно также для справочников/документов

(57) Прикинь нету транзакций, совсем нету... ибо они нафиг не нужны ибо плохо поддаются кластеризации ))

(59) А я же к этому и веду. А как тогда можно говорить про ACID?

ps: я не критикую, а присматриваюсь к этой субд.

(60) ACID это термин для реляционных БД, тут немного иное.

Суть что нельзя сделать кучу изменений "оптом" в одной транзакции. Каждый документ или "запрос" (в реальности функция map или reduce для view) могут обрабатываться на своей ноде совершенно параллельно и почти не зависимо.

(61)+ Тьфу точнее "запросы" как раз легко делятся на кучу узлов-нод в кластере где и параллельно выполняются

(62) А транзакции то вообще есть?

(62)+ Но это не запросы, это код функций на JS с входными и выходными данными.
Причем за пределы входных данных функция выйти не может, вот что есть на входе с тем и работай!

(63) А зачем?

(56) ну, "ждать" целых пол секунды - не так долго

ну и в термине асид нет ничего про то как устроена база.
Это про то, что транзакция неделима и либо применяется вся либо нет

(65) А как ты параллельность без транзакций хочешь делать?

(66) Гм а кто мешает в интерфейсе подождать тогда эти полсекунды (для NoSQL пусть оно как RDBMS по скорости условно пашет) и только потом отдать управлению юзеру?

(69) в том-то и дело, что не так оно по скорости пашет

(68) Смотри у тебя рота выстраивается в ряд.

Транзакции это когда каждого солдатика по очереди в нужное место ставим, сначала 1, затем 2-й и т.д.

А NoSQL это они сами одновременно все идут и становятся на нужное место ))

(70) Две кривые кол-во юзеров/мощность железа и когда пересекутся?
Для rdbms проблема что как железо не увеличивай один фиг пару лямов юзеров в одной базе не потянет...

(71) +ну или не становятся в ряд, ибо "не шмогла" ))

(71) то, что нужно сначала определить нужное место, естественно, забываем?
для лайков, тегов, комментов (да и то с ограничениями) это непринципиально, а для всего, что требует контроля - это ключевой момент.
и бизнес - это такая вещь, что без контроля - никуда. разве только касса с онлайн сканированием с помощью СШК может работать без контроля, да и то только в простейших случаях. а как только всякие маркетологи и егаисами появляются - всё, пц.

(65) Например, для этого в одной транзакции:
1. Записать расходный документ (шапка + тч);
2. Уменьшить остатки в спец. регистре;

(74) Ага то то в 1С многие начинают приходить к механизмам "отложенного проведения" в регламентных заданиях по ночам...

(71) Это если у всех есть свои места. или неважно где кто стоит.
А если в нужное место нужно каждого поставить, то будет конкуренция

(72) ну, пару лямов пользователей вряд ли будут собирать заказы с одного склада...

(76) если контроль остатков не нужен, то можно не проводить сразу, а отложенно вообще по всем регистрам.
Тогда транзакции не нужны

(75) В NoSQL все не так это разные операции без транзакции.
1. Запись расходного документа ACID
2. Уменьшение остатка - не ACID, сразу об этом можно узнать что "остатки кривые" оно в фоне считается, и когда будет готово об этом узнаем.

(78) Амазон?

(76) себестоимость можно и попозже посмотреть. а вот контроль остатков - нет.

+(78)  А два менеджера на процентах с продаж дефицитного товара запросто :)

(81) на одном складе? там десятки операторов и всё.

(82) Да блин кто мешает контроль остатков сделать через отдельный документ?

Если уж так нуна... Будут просто такие же тормоза как и в rdbms

(84) Речь про заказы и резервы товаров

(86) резервы в минус не всегда позволительны

(24)
Как-как - приблизительно, вот как. Лайки считать - не деньги в кассе, плюс-минус десяток всем пофиг.
Видал на ютубах, когда популярное видео выложат - просмотров 301, лайков 2000 ?

(85) Выбор такой?
1. Супербыстро, но не точно;
2. Точно, но не супербыстро.

(88) Прям описал картинку на типичном оптовом складе, а часто и розничном магазине ))

(89) угу

О, я хочу чтобы я когда деньги куда-то переводил, сначала там прибавляли, и только потом, когда-нибудь, проверяли, что они у меня есть :)

(92) Угадай как работают VISA с прочими Мастеркард ?

(92) :)
(93) Нет! Они так не работают.

(94) Раньше только так и работали, просто есть лимиты списания сумм без проверки/резервирования их наличия.

В нынешнее время когда каналы связи намного лучше без предварительной связи с банком-эмитентом и проверки обычно нифига не дают.

Исключения старые карточки (без чипов только магнитная полоска) или старые терминалы без чипов, там еще может произойти когда списывают в минус ))

(95)+ Учтите все (почти) банковские эквайринговые терминалы умеют работать в режиме "оффлайн кассы".

Т.е. обмен с банком и списания пройдет не в момент пробития чека а при связи с банком при "обмен данными".
Смотря как настроены, но так уже давно банки не настраивают, только онлайн.
Редкие исключения это зарубежные платиновые (ВИП) карты.

(0) РН от 1С вещь спорная.
предлагаю не заморачиваться и писать изменения только текущей датой и хранить только остатки на начало текущего дня.

Я вот просто не понимаю, какой же это должен быть СКЛАДИЩЕ и БАЗИЩЕ, чтобы там требовалась мощь десятка современных серверов?
В 2004 годе у меня на атлонишке гигагерцевом с одним гигом оперативы и 80гектарным винтом крутился терминальный сервер, на котором 30-40 юзеров работали на оптовом складе в семёрке. Где, на минуточку, не то что параллельности не было, а единовременно мог проводится только ОДИН документ.
А на современном железе на одом компе при правильных алгоритмах работы не знаю, до тыщи народу наверное смогут работать без тормозов, а вся база в оперативке будет сидеть.
То есть если для задачи потребно уже десять компов, то один хрен там какие-то доморощенные самописки не будет юзать.

(97) А задним число изменения запретить

(96)
Ты вообще не понимаешь, о чём речь.
В те времена, о которых ты говоришь, карта была вещь для элиты, и была она КРЕДИТНАЯ. Поэтому там проверка не выполнялась потому, что банк-эмитент давал гарантию, что счёт будет оплачен по-любому. Поэтому и карты банк кому попало не выдавал. А массовое распространение карт как средства обычного платежа началось именно тогда, когда появилась возможность проверять на них бабки в реальном времени.

(100) Ха, любая дебетка де факто "кредитная" и иногда при редких сбоях владелец карты об этом узнает ))

(99)
Кстати, забугорные системы так и работают. Все правки только через сторнирование. В ТЗ так и пишут - возможность изменить проведённый документ должна быть исключена.

(102) Да убирание работы задним числом конечно слегка облегчает реализацию, но что делать с мелкими исправлениями когда 10-20 раз документ "перепровели".

(101)
Не при сбоях, а при оплате за бугор, когда через пару дней могут досписать курсовую разницу. Или доначислить. Всяко у меня бывало. Но один фиг - в момент платежа проверяет, что денег хватает. Так что здесь как-раз тоже проблема работы "задним числом".

(103)
У них пока документ правят, он как бы "проект документа", и остатки двигает исключительно текущие, актуальные. Даже дата бывает открытая, "скользащая". Но как только приняли и зафиксировали сделку - всё, аля-улю. Что написано пером, не вырубишь топором.

(104) Нет у меня был вполне себе тут на местной заправке конкретный такой сбой.
Когда транзакция сначала прошла, потом почему то отменилась, а потом через неделю списали в минус (на карте денег столько не было).

Карта чистая дебетка, если бы не было этого сбоя с оплатой заправки в пару тыщ то пошел бы в банк разбираться ))

(106)+ Еще хорошо что это их сбой был и % за пользование овердрафтом не начислили.

+(104) (106)
Так бывает, и это не кредит, а овердрафт. Банк по нему может потом тебе адские проценты выкатить.

(105) Т.е. делаем два вида остатков, одни постоянные и другие временные.

Временные становятся постоянными когда?

(108) Эээ овердрафт это по нашим законам и есть кредит...

(106)
Кстати, тоже на одной лукойловской автоматической заправке постоянно - списание, отмена и тут же снова списание. Заговор у них какой-то...

(110)+ "1. В случаях, когда в соответствии с договором банковского счета банк осуществляет платежи со счета несмотря на отсутствие денежных средств (кредитование счета), банк считается предоставившим клиенту кредит на соответствующую сумму со дня осуществления такого платежа."
http://www.consultant.ru/document/Cons_doc_LAW_9027/cd4e8de1e04a7d8f27dd2d94f981bf2031494d0b/

(111) Хм тоже на Лукойле было - точно заговор ))

(105)+1
док при проведении остатки на начало дня не двигает никак.
хоть сколько раз перепроводи

а вот при закрытии дня - остатки посчитали и тогда уже всё- день закрыт - работа задним числом запрещена.

(109)
Какой смысл делать разные типы остатков, если задним числом документы не меняются? Они всегда одни, текущие.

(115) Не разные а отдельные, постоянные остатки вместе хранятся и это вьюха, временные за текущий период, которые еще не перешли в постоянные отдельная вьюха.

Полные текущие остатки это постоянные + временная дельта

(116)
Что ты имеешь ввиду под "постоянные остатки"?
Предпросчитанные промежуточные итоги по периоду что-ли?
В системах, где работа задним числом исключена - остатки - это просто таблица, в которой записано текущее значение остатка. Там даже поле "период" не нужно. Товар, склад, количество, грубо говоря. Документ провели - запись в таблице изменили.
Для отчетов считают по документом, можно регламентом с нужной периодичностью предпосчитать промежуточные итоги.
Но это просто регламент, и если его не сделать - просто отчёт будет считать итог на дату дольше. Но никаких разных остатков нет.

(117) В CouchDB view это не таблица (доступная пользователю на запись) а некие "итоги" доступные только на чтение.

Фактически остатки чего то или обороты это и есть такие итоги, которые зависят от записанных документов.

(118)+ В смысле не хочется изобретать нечто свое с хранением остатков в документе и вручную очень медленно с этим работать.

Хотя параллельное чтение одного дока это вполне шустро, короче буду экспериментировать.

(118)
А зачем это тебе, считать каждый раз всю сумму по документам?
Записывай куда-то просто пару товар - остаток.
Если по складам, то ключ будет "Товар/Склад", значение - "Остаток".
Документ провели - прочитал ключ-значение, изменил значение остатка, записал обратно.

(119)
А, понял, ты хочешь чудо-средство, что "я туда только движения пишу, а оно мне вжих, волшебным образом по движениям потом итоги выдавало".
Тогда да, надо будет на десять сервером распаралеливавать, чтобы на-лету остатки считать. Вместо того, чтобы алгоритм хранения продумать, и тогда этой хваленой возможности считать параллельно просто не понадобится, ибо и считать то не надо.

+(121)
Все думаете, что в NoSql какая-то магия есть. Нет там ничего, обычное хранилище ключ-значение, по-сути откат к старинной Berkley DB, в грамотной маркетинговой обёртке. Вся скорость только за счёт того, что всю базу данных в оперативку засасывает. Ну так можно и sqlite в memory затянуть - там такая скорость будет, закачаешься.

+(122) *Berkeley DB*

(121) (122) Чудо-средство это обычная видяха с GPU ))

Догадайся что будет от распараллеливания?

(124)
Тут должна быть картинка с Джеки Чаном, хватающимся за голову
Затем картинка facepalm.jpg
Насчёт Лаврова - не знаю, может быть, не хочу никого обижать.

(125) Глянь ссылки из Ускорение СУБД с помощью GPU и CUDA, сча еще Map-D появилась
http://www.nvidia.ru/object/blog-big-data-gpu-database-ru.html

GPUDB это дело ближайшего будущего, фишка что обычные реляционные плохо работают исключая случаи сложных запросов, много простых смысла нет.
А вот NoSQL это тема на GPU!

(120) только коучдб и прочие носкули так не работают, и по этому оперативных остатков там не бывает

(126)+ http://www.infoworld.com/article/3123747/data-center/faster-with-gpus-5-turbocharged-databases.html

(127) Если сделать очень-очень быстрый "подсчет остатков" то будет казаться что они вполне оперативные.

(126) в 2013 году. И где они сейчас?

(130) Тут https://www.mapd.com/

(131) подожди. это реляционка. и без кластера.

(126)
Это "ускорение ради ускорения".
Тому, у кого в руках молоток, всё вокруг кажется похожим на гвозди. Твое поведение напоминает неофитов, только что узнавших какую-ту хрень, и носящихся с ней, как с писаной торбой, пытаясь приткнуть её где надо и не надо.
Так вот в этой задаче - не надо. Она прекрасно решается простыми и понятными структурами хранения данных, без всякого топового железа и параллельных алгоритмов.
Вместо того, чтобы тупо при фиксации факта посчитать остаток и ЗАПИСАТЬ посчитанное, ты предлагаешь каждый раз загружать на видеокарту весь массив документов и считать всё сначала?
В чём профит? В том, что ты вместо избавляешься от одной лишней записи в момент проведения? Но ради этого придётся городить целый огород с параллельными расчётами, точно также организовывать запись промежуточных итогов для ускорения, да еще и думать, как это всё синхронизировать? На мой взгляд, крайне сомнительная выгода.

(133) после (132) вообще интересно, как автор гуглит...

(132) Угу самый идиотизм это пытаться делать виртуальную реляционку и эмуляцию sql на gpu.

Когда там самое то для NoSQL баз, прям просятся.

(127)
Что значит "NoSql так не работают?" Они не разрешают мне хранить в базе то, что я захочу? Зачем они тогда мне?

господи, да параллельный тэйбл скан там...

(134) Блин это просто примеры реальных "реляционных" баз данных "ускоренных" на GPU.

Если на GPU запускать NoSQL базы с MapReduce выигрыш в скорости будет просто офигительный!

из-за кучи ядер и наличия всего в оперативе получается быстро...

(133) >Вместо того, чтобы тупо при фиксации факта посчитать остаток и ЗАПИСАТЬ посчитанное, ты предлагаешь каждый раз загружать на видеокарту весь массив документов и считать всё сначала?

Если внимательно прочитаешь вопрос в (0) то поймешь что как раз хочу этого избежать.

вообще стандартные физические sql операторы параллелятся очень хорошо, проблема всегда в блокировках. nosql как раз "избавились от блокировок" путем отказа от оперативности. но и в sql также это есть, версионный режим, когда если запросу не принципиаольно - возвращается предыдущее зафиксированное состояние.

nosql - это реально не для бизнеса, это лайки считать.

Блин как обычно отклонились от темы и вместо "как это сделать" начинаем "нафига это делать" ))

Короче на данный момент меня не сильно волнует вопрос ускорения на GPU, это дело пока будущего.

Сейчас просто пытаюсь переложить конфу 1С на NoSQL (конкретно CouchDB) БД и все.

(138)
Тебе пытаются втолковать, что задача подсчета остатков не требует mapreduce.
(140)
Тогда тоже не вижу плюсов от замены на NoSql. Ты в итоге придешь к такой же структуре хранения данных, что и в реляционной базе, только на самодельных костылях. Закат солнца вручную через key-value pairs получится.

(144) А те кто пытаются это втолковать хотя бы VIEW в классических SQL серверах/бд используют?

Суть не 1С учетных систем тех же SAP'ов и прочих OEBS/Axapta как раз в полноценном использовании возможностей SQL сервера.

Я же просто пытаюсь использовать полноценно возможности NoSQL сервера.

(144) Плюсы есть, и в принципе проблема уже решена еще на 1-й странице и без всяческих "тех же структур".

Вообще, обычно обсуждение NoSql идёт по одному сценарию:
- Йоу, смотрите как быстро я в неё документ пишу и извлекаю!
- А выберите ка мне всех клиентов, купивших одеколон за месяц на сумму более 10 тыр.
- Ээээ, а зато тут можно всё параллельно

(147) Скажи вот у тебя 100 пользователей одновременно запустили отчет который "выберите ка мне всех клиентов, купивших одеколон за месяц на сумму более 10 тыр. "

Что будет? И что будет в NoSQL ?

И да я совсем не против обычного SQL, совсем не собираюсь от него отказываться и не призываю это делать других.

Суть применять NoSQL в тех задачах где он лучше работает.
Не выйдет чисто на CouchDB ну заюзаю Posgtres для актуальных остатков, где будут чисто ссылки-гуиды на доки, а сами доки буду в NoSQL хранить.

(149) *Postgres

(148)
Для начала окажется, что клиент не входит в ключ по документам. Потом окажется что вообще, клиент записывается просто строкой в данных документа. И т.д и т.п. Короче, решить можно, но надо неделю на программирование и десять серверов в параллель. Только и всего.
Если ты будешь говорить, что у тебя и документы по клиенту индексированы, и они отдельной сущностью сделаны, с включением в документ только ссылки - то чем это в итоге отличается от SQL баз?
SQL базы - это по сути надстройка над key-value хранилищами, и всё, что можно сделать на NoSql - точно так же можно сделать и в реляционной базе.

(151) Документы да отдельная сущность, вот их содержимое нет, внутри.

(152)
То есть чтобы отобрать все доки по конкретному клиенту нужно все доки перебрать?

(153) параллельно!!!111одиодин в кластере!!!одинодин

(153) Не нужно, они уже все заранее отобраны и сложены во view.

(154) Очень смешно...

Прикольно когда обсирают осуждают нечто слыша об этом по верхам ))

(0) я тут маленькую базку писал, с sqlite уткнулся в транзакции параллельно записать не получается. Открыто соединение должно быть только в 1 месте и если идет команда sql происходит блокировка.

Короче перевел на MS SQL LocalDB
Зачем велосипед изобретать..
NoSQL только для хранения документов,картотек, не для вычислений и тем более уж параллельных.

(155) да понятно, что по факту создается еще одна табличка по типу олапа, в которую демоны складывают периодически данные. эта периодичность в общем случае непрогнозируема. место, занимаемое данными - растет прямо пропорционально основным табличкам и в геометрической прогрессии по количеству разрезов информации.

(158) Угадал, но "код демона" пишется на том же языке что и и сама система ))

(159)
Это я как-раз и называю - "закат солнца вручную на костылях вокруг key-value pairs".

(160) Главную фишку знаешь? "Программисту" не обязательно будет нуна учить SQL ))

(161) не уж то это так сложно?

(162)  не ужто какой нибудь LINQ проще чем селект на обычном SQL?

(157)
В sqlite в один момент может писать только один писатель, блокируется вся база. Хотя, если для записи использовать только один процесс, которому другие шлют запросы на запись, и включить WAL - он пишет с охренительной скоростью. На своей машинке Corei5 3.2GHz с SATA винтом делал тест - начать транзакцию, записать десять строк в таблицу с тремя полями, зафиксировать транзакцию - в среднем 70000 транзакций в секунду. Периодически, когда скидывало кэш на диск, падало до 3000 транзакций в секунду.
При этом в WAL режиме записывающие не мешают читающим нисколько, то есть запросы других клиентов на чтение выполнялись во время транзакций записи.

(162) (163) Никаких LINQ'ов обычный JavaScript код.

ну и к вопросу о сложности...

(165) Блин я им про фому а они мне про ерёму...

Не считайте меня дурным и не знающим про "индексы".

Никакой "индекс" не поможет когда у вас данные новые колбасят и тут же хотят видеть остатки, пускай и не совсем актуальные но быстро-быстро, еще быстрее...
И если тыщщи юзеров в одной базе.

(170) (170) Эээ к вопросу о сложности а кто понял что справа вообще то много независимых штук?

1. есть функция MAP
2. есть функция REDUCE которая работает по результатам MAP но ей глубоко пофиг что там внутри, лишь бы структуру получить верную по полям
3. есть финализе которому тоже пофиг что там ранее
4. ну и фильтр на входе который можно менять не трогая функции!

(172)+ Короче любую часть можно независимо переписать (это разные модули и они выполняются независимо и даже на разных нодах) и оно будет работать!!!

А терь попробуйте исправить запросик SQL...

(173) У тебя js головного мозга. Как у одного товарища с .net

(174) Инструмент/технологию товарища с .Net вполне успешно использую. А вы?

(175) А нам-то зачем?

(173) по факту, то же самое можно сделать и со скулем в виде
mysql.query("select dim1,dim2").then((queryresult)=>{ result = queryresult.filter(/*тут то, что в where*/).map(/* тут преобразования полей из select*/).reduce(/* тут аггрегация*/).filter(/*тут фильтр having*/); return resolve(result)});

и никакой большой заслуги именно nosql движка тут нет. при этом map и filter параллелятся и так. reduce по сути своей однопоточен, так что преимуществ никаких у nosql нет

не, когда я изучал js и дошел там до методов массива - я в очередной раз пожалел, что в 1с нет лямбд, да. но наличие map/reduce никак нельзя признавать "киллер фичей"

(157)
sqlite - это кстати не NoSql. Это самая натуральная встраиваемая реляционная БД.

тем более, что далеко не факт, что map и reduce функции исполняются сервером субд, а не клиентским приложением ;)

(176) Действительно "а зачем?"

(177) У CouchDB из коробки отказоустойчивость кластера.

Попробуй на SQL взять допустим 10 компов (без выделенного главного/сервера) и на них поднять шустро работающую учетную систему.
Которая продолжает работать пока хотя бы один комп включен и ускоряет работу когда они назад включаются/добавляются.

(181)+ Суть что то что 1С получается путем написания сервера 1С с разворачиванием кластера и т.д. тут все работает из коробки на "бесплатных" технологиях.

Короче для неких ниш решение вполне оптимальное и наилучшее. Представьте кассы которые без сервера шустро-шустро пашут без тормозов.

(181) Вот.

(183) "Вам" не зачем )) Зачем мне это моя дело )))

(181)
Даже не знаю, как еще объяснить. Ты пытаешься оправдать вещь возможностью самой вещи, не пытаясь подумать, а ценна ли эта возможность сама по себе?
Что например, если сделать традиционную бд с грамотно организованным хранилищем, то сама необходимость в кластере из десяти серверов отпадёт?
Ты же не знаешь, как внутри их кластер реализован?
Поэтому, допустим, чем он отличается от десятка серверов с MS-SQL с настроенной авто-репликацией - не сможешь объяснить?

(182)
У меня на работе кассы шустро-шустро пашут без тормозов.
Без NoSql и кластеров. На sqlite :)

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

Тут это "из коробки".

(187)+ Отдельного сервера кроме касс нету

(187) Ты хочешь базу между клиентами распределять?

Ты немного не понимаешь требования к кассам. Она не должна отчитываться за других. Она должна человеку чек пробить, даже если сеть пропала. А когда сеть есть, скинуть продажу в учётную систему. Или у тебя это магия и при отсутствии сети работает? Через астрал?

(187) ну потеряются часть транзакций, да и буй с ним, да...

"оставшаяся будет сообщать о продажах" - в этом месте предвидится затык

(189)
Ага. Всю базу всех продаж реплицировать на каждую кассу. Понял, да. На каждой кассе поставим Xeon + 128Gb RAM + 1TB винт :)

"В качестве домашнего задания можете провести такой эксперимент. Уроните одну ноду. Убедитесь, что документ можно обновить, используя только оставшиеся две ноды. Затем поднимите упавшую ноду и быстро-быстро запросите с нее документ. Убедитесь, что никакого конфликта не происходит и вы получаете последнюю ревизию."
http://eax.me/couchdb/

Это если кто по английски не может

+(193)
А, еще крутой GPU нужен, обязательно. Будет остатки в паралель считать. А когда затишье, кассир в думчик поиграет :)

(193) 4 а лучше 16 Gb RAM хватит за глаза
https://developer.couchbase.com/documentation/server/current/install/pre-install.html

(194) Это всё хорошо. Ноды у тебя где будут?

(197) на планшетах/мобильных кассах

(194) для одного документа и локальной сети - предполагаю, что время синхронизации пренебрежимо мало.
а теперь представь ситуацию нарушения связности между нодами вместо падения, с одновременным исправлением одних данных в двух нодах. или когда канал между нодами - не 1гбит сеть, да и данных с сотню мегабайт накопилось

(198)+ и еще на ТСД по складу бегать... и стоять на десктопах менагеров

(196) На каждую кассу по 16 гиг?

сферические примеры кластеров в вакууме часто разбиваются о реальность каналов связи

И на ТСД держать реплику все базы????

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

Блин мне нужна некая технология, я ее нашел и пытаюсь заюзать как нуна. Так как 1С без плясок с бубнами и разного программного шаманства не позволяет.

(203) Шутки сча понимать надо, в будущем это будет не шутка

(204) получение оперативных данных - это не "как нуна"

(206) Если мы знаем что "вот эти данные не оперативные" то легко можем подождать или сделать спецзапрос оперативных.

(204) Ну чтож дерзай, как сделаешь расскажешь

У меня такое подозрение что адепты FTP спорят с любителем торрентов...

В теме слишком мало блокчейнов...

(210) ты сделал мой день!

(209) Только вот по фтп каждый берет ровно свой файлик в 100к, а через торренты вся база мигрирует в 100г

(210) (211) шшш тут нельзя про это...

(207) а как ты поймешь, что данные не оперативные при нарушении связности?

(212) Странно... почему я через торренты беру (и раздаю) только тот файлик хоть пару байт (на самом деле захватываю и соседние ибо блоки) а?

(215) да нет, при запросе select from where ты получишь только нужные тебе данные, при репликации - ты вынужден получить все + постоянно отслеживать изменения. это на самом деле большая проблема. например при попытке изменить одновременно документ в двух местах, когда тебе пофиг, все хорошо, а вот "объект уже захвачен для редактирования" когда не пофиг, уже не получится.

(214) Там немного интереснее и проще есть встроенный механизма разрешения конфликтов с сохранением конфликтующих копий
http://guide.couchdb.org/draft/conflicts.html

(217)+ И да нарушение связности так же легко определяется и можно это вручную отработать уже.

Но блин это полезли в моменты которые пока даже не думал, мне бы пока просто падение 1-2 серверов исключить.

Кстати! Там же через http прокси обращение к CouchDB работает, короче что кластер развалится на несколько "работающих" групп нод маловероятно.
Суть что да можно настроить напрямую на ноды связь, а можно через прокси который нагрузку между нодами разруливает

(218) ну так тогда нафиг этот "кластер", если прокся упадет?

(219) проксю легко и на лету поменять же прямо из клиента