Понимаю что сабж это пока из разряда фантастики но насчет подумать?

Вот есть такая штука как https://ru.wikipedia.org/wiki/ZeroNet
Можно ли каким то образом заставить обычные php+mysql и даже 1С конфы работать в подобном режиме?

Когда база данных, "сервер приложений" и сам веб-сервер размазан по множеству узлов с дублированием.
И между ними происходит синхронизация данных.

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

нефига не понял, что значит подобный режим? Чем уриб не нравиться?

(1) Фреш надо по сути но на своих серверах, причем даже если один упал то похрен есть другие и данные на них.

(0) я так понимпю что это идея самого WWW

(3) Не совсем так, развитие этой идеи.

WWW предполагает сервер с которого получает данные клиент.
Я же хочу много сервером с дублированием-размазыванием данных и клиент получает с ближайших но самые актуальные.
Сочетание CDN и блокчейна для баз данных.

(4)+ Главная проблема это распределенная база данных и каким образом в ней транзакции будут идти.
Если узлов-серверов не десяток а сотни и тысячи по которым БД размазана с неоднократным дублированием.

(5) А это идея блокчейна. Мы живем в такое время что самое полезное и хорошее уже придумано до нас ))

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

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

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

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

(7) Реализовать по сути единую вычислительную среду вместо отдельных серверов, где каждый участник получает свою капельку вознаграждения в зависимости от того сколько он ресурсов свободных выделил. Это как вариант GRID-вычисления, например платформа BOINC. С хранением данных пока такого не знаю.

(8) Ну да про разные отдельные частные варианты давно слышал, но хочется то именно базу данных распределенную.
Вот распределенная файловая система уже есть https://ru.wikipedia.org/wiki/Google_File_System

Осталось это провернуть для учетных систем в т.ч. для 1С и будет то что хочется.

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

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

(7) Это слишком масштабная работа которую одиночка не осилит. И на первый прототип уйдут годы

(11) Неа, как раз первый рабочий прототип сваять не проблема.
Но вот успешно его "продать" одиночка не сможет, как и довести до востребованного другими состояния.
Будет очередная разработка в стол, никем не востребованная.

(12)+ Причем когда нечто похожее уже давно пилят другие типа https://mariadb.com/products/clustrixdb/
Но блин они пока пилят отдельные куски а не цельную систему.

(12) То есть ты хочешь сказать что ты легко наваяешь прототип а другие пилить еще долго будут ?

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

(15) Я думаю что касается 1с то более реалистичная задача переделать КД3 по принципу КД2. Было бы полезная штука для использования распределенных систем. КД3 слишком проблемная.

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

"Когда база данных, "сервер приложений" и сам веб-сервер размазан по множеству узлов с дублированием"

Как ты себе это представляешь? Формируешь ОСВ, а система оббегает 100500 клиентских машин, чтобы собрать все данные для отчета?

(17) Система не оббегает 100500 машин а дает им команду.
Выстраивается подграф в виде расходящейся сети, и машины с самых дальних начинают возвращать данные, причем обрабатывая по пути, получив от дальних совмещают со своими и пересылают еще более ближайшим.
Пока готовые данные от малого числа самых ближних узлов не попадут на конечную и не будут тут окончательно собраны.

Для ОСВ выглядит как совмещение таблиц с правилами операций в ячейках (строках/столбцах), чтобы в результате получалась готовая полная.
Для статического контента уже все давно так и работает по сути, вот для динамического пока только MapReduce более менее подходит, классический SQL хреново ложится в эту модель.

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

(19) Тормоза будут и несколько повторных циклов формирования ОСВ чтобы когда данные совпадут 3 раза точно готово и правильно :)

(20)+ Система дешевая и надежная, насчет быстроты извините.
На большинстве задач где может справиться один комп будет тормознее, и только редкие задачи где один комп очень долго будет считать сеть справится быстрее.

Например для расчета зарплаты это супер применять или нечто подобное, где хорошо распараллеливается.
Там где надо получить одну цифру итого с отборами все сильно хуже.

(22) так "получить одну цифру итого" самая популярная задача в этих самых бизнес-системах

(23) Особенность MapReduce что все эти цифры итого автоматом пересчитываются при изменении первички если нужные функции Map и Reduce написаны.
Короче ввели данные - ждем пока считается, сразу будет выдавать старое итого, как система посчитала любой узел из хранящих нужные данные мгновенно выдаст это "итого".

(24)+ Это похоже на отложенное проведение документов по регистрам, где затем формируются все возможные отчеты во всех возможных видах (да для хранения это занимает дохера места и считается долго но у нас же сеть которая параллельно считает каждый отдельный отчет).

И затем мгновенно выдается отчет по старым данным, по новым или исправлениям старого периода придется подождать пока система пересчитает, в процессе пересчета выдает старую неверную инфу.

(25) т.е. ты предлагаешь к этой системе сразу прикрутить OLAP-кубы на все случаи жизни?

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

Да MapReduce очень непривычна после классической реляционной модели и итогам по запросу, легко накосячить положив систему лишними или неправильными итогами.

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

(28) так в чем профит-то от этой системы, если при прочих равных она будет дороже и тормознутее? К тому же всегда дешевле купить/апгрейдить один сервер, чем сотню клиентских компьютеров

(29) Если клиентских компов не сотня а сотни тысяч или даже миллионы?
Причем они большую часть времени тупо простаивают?

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

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

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

С сервером всё почти просто. Оградил сервер всякими там фаерволами, антивирусниками, групповыми политиками, и пускаешь туда клиентов под ограниченными правами. А для зоопарка компьютеров как защитить информацию?

Представляешь, как шустро будет собираться отчёт, когда исходные данные раскиданы по десятку машин на разных континентах?

(0) Народ кучу технологий изобретает, чтобы актуальные данные рядом лежали - начиная от партиционирования таблиц на быстрые файловые ресурсы и кончая базами в памяти. А тут хоба, и твои итоги лежат на кофеварке в Никарагуа.
Зато модно, стильно, молодежно, стартапчик там...

(33) Представляю, поэтому отчет уже должен быть посчитан заранее (24)(25)

(35) А теперь представь оперативный контроль отрицательных остатков.

(36) Прекрасно представляется через блокировки (резервирование нужного количества единиц чего надо) перед проведением.
Если блокировка не прошла то документ не проведется.

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

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

(37) Msg 1205, Level 13, State 51, Line 6
Transaction (Process ID 62) was deadlocked on lock resources with Dutch teaspot and has been chosen as the deadlock victim. Rerun the transaction.

(39) Речь про тупиковую блокировку? Это давно разрешается в рамках блокчейна голосованием.

(40)+ Хотя прикол что пока два больших документа с большим кол-вом единиц борются, мелкий док с маленьким количеством может вперед проскочить ))

(40) Напомни, сколько там по времени транзакция в том же биткоине подтверждается?

(42) Ты не путай майнинг с блокчейном это совершенно разные вещи по сути.
Тут голосование для прохождения транзакции будет секунды занимать.

(43) А я и не про майнинг, а про подтверждение транзакции

(43)+ Никому в голову не придет прикручивать защиту (в учетной системе) от подделки кол-ва единиц на остатках ))

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

(45) А вот тут ты ошибаешься.
Самая распростоненная схема мошенничества - манипуляция с остатками в БД.
Когда реальное значение знает только один человек, а в БД фикция, а разница спижжена.

(47) И каким местом тут помогут текущие реляционные системы и как узнают про фикцию?

(48) К тому что можно отследить по цепочке, в той же 1с - без допила доказать что то сложно

>>
Чтобы создать децентрализованный облачный сервис для клиентов с надежным резервированием пусть и в ущерб скорости работы.

Почитав ветку возникло ощущение, что речь все таки идет о том, что бы задействовать "чужие" мощности для своих задач, нежели о том, что бы иметь "резервные данные" так?

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

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

(46) Если бы у бабки был уй, она была бы дедкой.
Нормального высокопроизводительного решения на базе технологии блокчейн пока нет. Там дуров обещает "миллионы в секунду", но будет так или нет - время покажет. Пока скорость - такое себе.
(51) В первый день на мисте?)

(52) Идея сама по себе конечно интересная, но вот специфика в том, что "делиться" своими данными никто не хочет (это одна из основных причин почему народ не идет в облака)

(51) нетворк фс нетривиально, репликация нетривиально, а вот контроль остатков тривиально

(53) Да есть и давно те же MapReduce умеют и MongoDB и CouchDB.

Особенно Mongo интересен ибо:
"Система масштабируется горизонтально, используя технику сегментирования (англ. sharding) объектов баз данных — распределение их частей по различным узлам кластера. Администратор выбирает ключ сегментирования, который определяет, по какому критерию данные будут разнесены по узлам (в зависимости от значений хэша ключа сегментирования). Благодаря тому, что каждый узел кластера может принимать запросы, обеспечивается балансировка нагрузки."

(55) Да но только после решения двух предыдущих нетривиальных задач.

(54) Есть такое и что данные хранятся в зашифрованном виде и раздельно мало поможет, ибо система один хрен должна их расшифровывать для обработки на узлах.

(56) в линукс ничего не работает, а если работает то это или фейсбук или гугл

(59) или Яндекс)

(59) Очень смешно, особенно когда 1С давно на линуксе пашет

(59) а как (56) связан с линукс?

Короче есть у меня мысль написать на основе MongoDB нечто похожее на такую учетную систему и проверить как она в реальной работе, хотя бы на многих компах внутри локалки.

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

Останавливает пока только что писать, повторять платформу 1С или аналоги не выйдет, совсем другая архитектура не обычная sql с табличками.

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

Я ведь правильно понимаю, ты хочешь все движения (а точнее вообще все) писАть во монго?

(64) К документу который проводится все обратно стекается (записывается в него) в т.ч. сообщения о его проведении и ошибках.
Выглядит с точки зрения 1С смешно, когда вместо статусов документов в отдельном РС просто реквизиты в самом документе меняются в т.ч. уже проведенном.

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

(65)+ Важное замечание что каждый документ в себе хранит копии элементов справочников выбранных в своих реквизитах.
Даже если потом поменять элемент справочника, то в старых документах ничего не изменится само.

(65) я понимаю, что в итоге все вернется в документ (вопрос только когда это произойдет?! после того как пользователь нажал кнопку "Провести и закрыть" и сразу не увидел сообщения - он их уже никогда не увидит).

>>движений как таковых не будет, только исходные документы и отчеты по ним построенные.

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

(66) я  знаю как работает CouchDB (сам им пользуюсь с удовольствием)

(67) Нажатие кнопки провести всего лишь означает подпись и передачу документа на исполнение куда то вниз или в сторону, это совершенно не означает что отгрузку произведут и т.д.
Если не смогли то в документе это будет отражено и каким то образом сообщено пользователю.
Прямая аналогия с бумажными документами когда оно возвращается назад с пометкой "не смогли сделать ибо товара нетути".

Отчеты строятся по справочникам, документам и результатам других отчетов. Промежуточных регистров нет их роль играют сами отчеты.
Короче регистры накопления = отчеты.

(68) MongoDB очень похож на CouchDB, но через свой драйвер а не только по rest и Reduce с ограничениями для шардинга, раздельного выполнения на разных узлах.
Среднее арифметическое можно посчитать только на одном узле куда все стечется, в отличие от процента.
Точнее разбивают на две MamReduce и второй передают результат первой как параметр (общее количество/сумму)

(70) *на две MapReduce

(69) >> Прямая аналогия с бумажными документам....

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

>> Отчеты строятся по справочникам....

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

(70) именно из-за rest  я и выбрал CouchDB

(72) >в момент проведения будут сформированы нужные отчеты и записаны "как результат" и так после каждого проведения документа так?

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

(74)+ Это кстати решает проблему "провести_закрыть" ибо остатки не поменяются по отчетам сразу же, только когда документ реально проведется, получит статус нужный и отразится в отчетах

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

(74) Мне нравится сама идея (особенно с внешними базами типа СouchDB ну или MongoDB), но я даже не представляю как (а точнее какой объем работы будет связан с отчетами). Учитывая, что собираться они будут на ходу и такого понятия как "переформировать отчет" в принципе не будет то...

(77) Да с отчетами будет не привычнее всего, их придется жестко ограничивать рядом стандартных без той гибкости как в 1С (да и в целом в sql) сейчас.
Это ближе к стандартным регламентированным отчетам, где все одинаково по форме.

Т.е. вот на каждого контрагента сверка расчетов, хотите сделать одну сверку на двух контрагентов - хрен вам.

(78)+ Можно конечно делать полные общие формы отчетов и затем показывать только часть записей (или полей) фильтрами/отборами уже на конечной системе.

(78) >>  ... хрен вам.

не поймут :)

(79)+ И да это будет сравнимо по скорости, ибо полный отчет по всем допустим контрагентам хранится уже готовый и просто происходит фильтрация/отбор для нужных контрагентов.
Не как в 1С где из регистров данные по нужному отбору нужных контрагентов выцепляют.

(80) Да это будет сложно объяснить, что добавление новой очередной формы отчета замедлит формирование всех отчетов одновременно ))

https://cs6.pikabu.ru/post_img/2014/10/15/11/1413392884_1215561599.png
в итоге получится

(83) Не не это ближе к https://360tv.ru/news/mir/malchik-postroil-jadernyj-reaktor-v-komnate-i-objasnil-zachem/

(84) Ибо можно но науя? Когда везде 1С стоит и куча спецов по ней.

Т.е. нужен редкий случай когда форм отчетности мало, но пользователей очень-очень много и данные колбасят так что 1С не успевает и тормозит зверски.
В этом случае подобная описанной мной учетная система может себя показать на 200%.

(85) Но это уже не 1с, а решение совсем другого класса и задач

и денег

(87) Вот насчет денег вопрос интересный.

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

(88) Конечно же фейсбук.
А если серьезно, то на моем уровне я пока не вижу потребности в чем то другом, что есть на текущий момент.

(89) Ну я вменяемый и учетную систему подразумеваю.

(90) На бытовом уровне с 1С тягаться бессмысленно.
А так - что то типо консолидации думаю было бы восстрребовано.
На вход много мусора.
Внутри правила.
На выходе МСФО

Вот там да, на входе данных много, даже может быть очень много.
На выходе - аггрегированная информация

(91) Ну или не МСФО, а комплект управленческой отчетности, но он как правило стандартизирован

(91) (92) Интересно, по сути интеграция с 1С для импорта данных и выдача отчетности по формату.
Причем правила внутри системы настраивается из 1С сырые первичные данные.

(94) Ну да.

(94)+ Может XBRL еще заняться, интересно Охотница за головами не прибьет?

(96) они не единственные и не первые, но на сколько мне известно поздновато уже туда, проекты пошли

(97) И хрен с ним, если навять нечто универсальное куда любую конфу можно засунуть в качестве источника данных первички.
Хоть 1С 77

А вот по поводу УХ - благодатная тема.
Там код внутри и архитектура уровня хуяк хуяк и в продает. По факту без доработки напильником - не летает.

(98) Как то тема создания глобальной распределенной вычислительной системы из (0) перескочила на тему бытовой учетной задачи. Дауншифтинг какой то ))

(0) Делали как-то эксперименты со своим веб-клиентом, когда базу данных делили на две, за "условно статическими" запросами ходили в копию базы (например, за списком номенклатуры и ее иерархией, или за списком контрагентов), а часто изменяемые данные - остатки товаров, скидки из индивидуальных соглашений - брали из рабочей базы. Таким образом снижается нагрузка на рабочую базу и есть возможность создать заказ, не видя реальных остатков товаров, если рабочая база недоступна. Веб-клиент компоновал данные из двух баз и отображал на одной веб-странице.
https://www.youtube.com/watch?v=ZO2xIt5dguI&feature=youtu.be&t=1310

(101) Копия базы была РИБ?

(102) Все изменения в онлайне подгружались из основной базы в копию через веб-сервисы. Из копии в рабочую данные не мигрировали.