LINUX.ORG.RU
ФорумTalks

Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес

 , , ,


6

2

ERP-шники из прошлого треда сдулись, а мой интерес к вопросу только разгорелся. Моя попытка нарыть что-то более-менее объемное по теме создает ощущение, что ERP — это как онанизм: все занимаются, но никто не обсуждает. Нашел забавную статью на хабре:

https://habr.com/en/post/447162/ - Не купитесь на ERP

Сразу скажу, что я не согласен с автором, но позиция интересна. Если слегка смягчить ее, то получится что-то такое: если на вашем предприятии бардак, то ERP за вас не сможет его организовать; если же вы навели порядок на своем предприятии, то ERP вам уже особо и не нужна.

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

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

https://www.sapdatasheet.org/abap/tabl/mara.html

Ну или просто позволяя вам выбрать из готового набора 110 000 (сто десять тысяч) табличек те, которые подойдут вашему бизнесу... или не подойдут. Остроумен с коммерческой точки зрения такой подход потому, что с позиции человека, который не разбирается в IT, то есть, типового клиента SAP, какой-нибудь SAP R/3 предоставляет собой крупную хорошо проработанную и проверенную систему, которая покрывает чуть ли не все на свете варианты бизнес-процессов предприятия. В такие моменты я люблю вспоминать покойного Дейкстру:

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

То есть, приходит менеджер, который отвечает за принятие решений, и спрашивает у продажника SAP: «у вас есть ${фичанейм} в системе? Насколько хорошо автоматизирует ${процесснейм} ваше решение?». Причем, говорить об этом до начала внедрения — это все равно, что спрашивать у женщины «вы можете родить мальчика или девочку? А мальчик будет гениальным?». Особенно если этой женщине 50 лет и ее маркетинговое преимущество — это что оба ее сына стали успешными учеными.

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

Пока что, из моего опыта разработки CRM/недо-ERP, мне видится, что одно из ключевых препятствий на пути заполнения данной ниши — это реляционные СУБД, которые используется к месту и не к месту — просто потому, что РСУБД есть готовые в большом количестве. Как правило, даже у достаточно конкретного клиента есть ни разу не конкретные требования по автоматизации, которые меняются день ото дня, вроде «мы узнали длину члена Василия Петровича — давайте сохраним эту информацию в CRM записи про Василия Петровича, в надежде, что со временем удастся собрать аналогичные сведения по другим клиентам и вывести кореляции». Происходит это не только из-за сиюминутных прихотей конкретного менеджера, но и из-за постепенной смены коньюктуры и технологий в фирме.

Реляционная же модель приводит к тому, что когда внезапно появляется необходимость сделать связь сущностей N-к-M вместо какой-нибудь 1-к-N, то приходится перекраивать базу верх ногами, создавая новую таблицу связей между сущностями и изменяя алгоритмы создания-чтения-обновления-удаления. А в случае перехода от 1-к-1 в N-к-M нужно создавать уже две дополнительные таблицы. У того же SAP по этому поводу из коробки для целой кучи атрибутов есть поддержка множественных связей, откуда и появилось астрономическое количество табличек — в реальности таблиц корневых сущностей там всего несколько сотен.

Апгрейды, поддержка, доработка — это, между прочим, основной доход вышеупомянутой SAP. Моя воображаемая цель проста: уничтожить SAP с ораклом. По крайней мере, такова она по состоянию на момент создания треда.

Есть много опенсорсных попыток писания ERP софта (например, Odoo, OpenERP, IDempiere/Compiere/Adempiere/Openbravo/metasfresh), но каждая из них, как правило, представляет собой одну и ту же попытку повторить SAP в мелком масштабе. У меня есть некоторые абстрактные зарисовки по этой теме, но, как показывает практика, публиковать их не имеет смысла, а пытаться сделать что-то конкретное прямо сейчас у меня тупо нет времени/желания, поскольку я работаю над релизом предыдущего незаконченного проекта питоньей многозадачности. Так что принимайте эстафету.

★★★★

Ответ на: комментарий от byko3y

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

Или сложные структуры данных и сложные внутренние схемы это последствия индусни и прочего аутсорса?

foror ★★★★★
()
Ответ на: комментарий от foror

Если я захочу создать международную корпорацию и поработить человечество, мне SAP или Odoo поможет плотить нологи и зарплаты в каждой стране индивидуально без найма армии бухгалтеров и юристов?

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

Или сложные структуры данных и сложные внутренние схемы это последствия индусни и прочего аутсорса?

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

ptarh ★★★★★
()
Ответ на: комментарий от byko3y

Какую-либо аналитику сложнее чем «вывести на экран как есть то, что было введено до этого» можно производить только если у данных есть структура. А дальше у тебя эта структура либо есть явно как, например, sql-схема, конфигурация 1С, заведённые на весь набор сущностей колонки в CRM и т.д.

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

PolarFox ★★★★★
()
Ответ на: комментарий от foror

Если я захочу создать международную корпорацию и поработить человечество, мне SAP или Odoo поможет плотить нологи и зарплаты в каждой стране индивидуально без найма армии бухгалтеров и юристов?

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

Или сложные структуры данных и сложные внутренние схемы это последствия индусни и прочего аутсорса?

Следствие бездумного следования мейнстриму. SQL и реляционные СУБД прежде всего, были созданы с единственной целью — создать язык, который бы давал возможность строить запросы к БД независимо от фактической формы хранения данных. Причем, этот язык не обязывал хранить данные в виде соотношений столбец или строк, но обязывал отвечать на запросы в такой форме. А форма это весьма и весьма куцая (ку́цый — с коротким, обрезанным хвостом), особенно в ее первозданном виде, которая без внешнего программирования не позволяла ничего сложнее простых агрегаций без порядка внутри группы и простых соединений таблиц. Из-за чего возникли расширения слияния таблиц от оракла, CTE для рекурсивных и иерархических запросов, и вообще отдельный язык MDX для многомерных запросов, которые совсем никак не влезают в реляционную модель, но крайне важны в аналитике.

В качестве совсем иного ответвления развития СУБД можно вспомнить NoSQL, которые, в свою очередь, призваны исправить тот факт, что SQL запросы в общем виде нельзя эффективно реализовать на распределенной системе. Случилось так потому, что фантазер-математик, который придумал изначальную математическую модель реляционных баз, в упор отказывался видеть тот факт, что его модель требует доступа ко всем данным сразу и с нулевой стоимостью доступа, а оптимизации подлежит только размер формы хранения данных и язык доступа к ним.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от ptarh

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

Тысяча человеколет — это, грубо говоря, порядка 100 млн долларов. Или стоимость нескольких крупных внедрений SAP. Короче говоря, копейки, даже если на секунду представить, что это была реально полезная работа, а не клепание фич ради фич.

byko3y ★★★★
() автор топика
Ответ на: комментарий от PolarFox

Какую-либо аналитику сложнее чем «вывести на экран как есть то, что было введено до этого» можно производить только если у данных есть структура. А дальше у тебя эта структура либо есть явно как, например, sql-схема, конфигурация 1С, заведённые на весь набор сущностей колонки в CRM и т.д

Вот ты сейчас неявно подразумеваешь, что «структура = реляционная модель», но это не так. Да, любые структуры данных чисто теоретически можно представить в виде реляционной модели, но на практике часто возникают ситуации, когда такое представление не имеет никакого смысла, потому что данные динамичны, их общая структура не определена заранее, но всегда сложна, и тогда работа с реляционной моделью оказывается намного сложнее и на много порядков медленнее, чем с естественным представлением исходных данных.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Тысяча человеколет — это, грубо говоря, порядка 100 млн долларов. Или стоимость нескольких крупных внедрений SAP. Короче говоря, копейки, даже если на секунду представить, что это была реально полезная работа, а не клепание фич ради фич.

Мы всем лором с нетерпением ждем твоих творений, где ты покажешь сапу, где раки зимуют. Yoba-кулер у нас уже был, пришло время yoba-ERP.

ptarh ★★★★★
()
Ответ на: комментарий от byko3y

Я в общем проводил разрез не по реляционности базы данных, а по месту где храним структуру, в самой базе, или подразумеваем в коде приложения.

А так говорим база данных, подразумеваем реляционная база данных, т.к. даже для хранения нереляционных данных традиционные РСУБД всё равно подходят лучше этой вашей монги. От простых табличек вида ключ-значение, до всяких hstore, json-полей и подобного.

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

PolarFox ★★★★★
()
Ответ на: комментарий от byko3y

Следствие бездумного следования мейнстриму. SQL и реляционные СУБД прежде всего, были созданы с единственной целью — создать язык

PS: первые РСУБД появились во время депрессии в штатах, рядышком с Си и Юниксом, когда новых разработок было мало и индустрия была готова подхватить любое халявное решение. А потом уже не смогла от них избавиться. Я когда-то говорил, что SQL — это язык для банковских транзакций, но я все-таки понял, что был неправ. Уже к концу 90-х SQL стал языком для вебсайтиков и бухгалтерии ларьков, потому что принципиально немасштабируем (распределенные вычисления) и при этом неудобен для работы с любыми сложными структурами данных или сложными представлениями. Теперь уже банки переходят на NewSQL, OLAP перешла давно на MDX, а SQL остается только для сайтиков, и то NoSQL СУБД его потихоньку вытесняют из ниши.

byko3y ★★★★
() автор топика
Ответ на: комментарий от ptarh

Мы всем лором с нетерпением ждем твоих творений, где ты покажешь сапу, где раки зимуют. Yoba-кулер у нас уже был, пришло время yoba-ERP

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от PolarFox

Я в общем проводил разрез не по реляционности базы данных, а по месту где храним структуру, в самой базе, или подразумеваем в коде приложения

Я тебе открою великую тайну, но никакие данные сами по себе не имеют смысла без кода, который сможет эти данные интерпретировать.

А так говорим база данных, подразумеваем реляционная база данных, т.к. даже для хранения нереляционных данных традиционные РСУБД всё равно подходят лучше этой вашей монги

А ничо, что табличка с составными значениями уже не является реляционной? Создатели РСУБД давным-давно поняли, что реляционная модель бесполезна, потому активно уходят от нее. Но как-то вяло.

А чтобы потом с этими данными сделать что-то полезное, их всё равно явно или неявно придётся приводить к табличному (читай реляционному) виду

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

byko3y ★★★★
() автор топика

Уф-ф-ф, начитался я тут всякого. Интересно, что сам SAP в своей HANA тоже отказывается от durability составляющей ACID, записывая все новопоступившие данные в отдельное двухступенчатое хранилище в памяти (DELTA), которое со временем сливается с основным хранилищем (MAIN), представляющим собой колоночную БД в памяти. По умолчанию раз в пять минут данные из колоночной БД сохраняются в постоянную память. То есть, данные проходят путь от строчного представления DELTA в колоночное представление DELTA в колоночное представление MAIN и только потом в диск. Соответственно, ни о каких гарантиях сохранности свежих данных при отказе сервера речи идти не может.

Я уже довольно давно писал, что база данных для ERP может работать с приемлимой скоростью только в памяти. К сожалению, при масштабах SAP это значит, что для крупных компаний база крутится на хосте с оперативой в несколько терабайт. Не то, чтобы SAP HANA не могла работать на меньшем объеме оперативы — просто, происходит выгрузка таблиц и база начинает тупить, как старая добрая диск-ориентированная СУБД.

Одна из первых вещей. которая мне вообще в голову пришла, когда я начинал творческие скитания: давайте хранить все данные в одном файле базы аля SQLite и копировать ее между конпами, при этом база будет целиком грузиться в оперативную память и потом читаться, например, через разделяемую память с доступом read-only, с произвольной гибкой и быстрой обработкой любых придумываемых пользователями и программистами типов данных. Такая схема весьма неплохо работает (при соблюдении некоторых условий) для каких-то мелких фирм, вроде тех же аптек с их 50-100 тыс наименований у поставщика и сотне поступающих единиц товара каждый день. Причем, даже на игрофоне. Тупо грузить в память этот файл с данными на несколько сот мегабайт, где его потом можно будет целиком прочитать за долю секунды для выполнения любого запроса чтения. Для внесения изменений в БД такой системы есть более одного подхода, но в любом случае такая упрощенная и упоротая архитектура имеет свои плюсы.

А вот на масштабах побольше такая схема потребует уже весьма солидную машинку. Соответственно, круг девайсов-клиентов резко сокращается. Эту проблему, однако, возможно решить, если выдавать клиенту частичный образ базы. В этом случае проблем рассинхрона с центром и отправки изменений клиент->сервер не меньше, но и не больше. Плюс, в любом случае есть смысл резать пользователю доступ к коммерческой инфе.

На самом деле подобную систему я уже знаю, и мне аж стыдно за то, что с начала этого сообщения я, по сути, не выдал ни одной серьезной собственной идеи — всё это минимальные адаптации давно существующих систем. К слову о существующих системах:

https://habr.com/en/company/marsis/blog/536764/

Одинцовская кондитерская фабрика Mars, которая выпускает «Коркунов», работала на локальной SAP, причём на старой версии, которая уже не поддерживается. Плюс, на фабрике существовало множество отдельных систем для управления разными направлениями работы, которые между собой взаимодействовали. IT-подразделение Mars не могло дальше всё это поддерживать — ввиду высокой стоимости и трудоёмкости процесса. Платформу надо было менять.
Кроме того, фабрике надо было встраиваться в глобальные процессы, например по прослеживаемости, качеству готовой продукции. В этом смысле работать в глобальной системе необходимо, чтобы следовать корпоративным стандартам и иметь возможность развиваться с поддержкой IT-систем.

Менеджеры нашли в старой системе управления фатальный недостаток — деньги под нее распиливали не они. Система работала-работала-работала, а потом херак — и нельзя больше так работать, нужно централизироваться. А я спрашиваю: зачем? Китайцы, например, наоборот не любят SAP как раз за то, что китайцев вполне устраивает некоторый локальный учет и планирование, и никакая централизация их не колышет.

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

Где-то в этом районе у меня появилось идея, что единственной универсальной платформой для реализации подобной БД из логики связанной с данными (но без представления) может быть WebAssembly. JS идет лесом, потому что не потянет столько низкоуровневых операций с байтами.

Это была одна сторона архитектуры системы. Вторая — это структура самих данных. SAP форсит жесткую структуру и жесткую формализацию, вплоть до того, что идентификаторы должны иметь конкретное число символов, не больше и не меньше. Такой подход был актуален в 1972, ну может в 1992, но уже сейчас ресурсов у рядового мобильного устройства достаточно, чтобы работать с динамическими данными. Менеджер хочет к заказу оставить коммент, а к комменту прикрепить документ/картинку. А потом оставить ссылку на другой связанный заказ. И потом всё это найти. Например, зайти в заказ, посмотреть связанных клиентов, посмотерть какие заказы обычно делают эти клиенты, сразу же залезть на в информацию про аналогичные ранее заказанным товары — и всё это буквально одним кликом. Куда там такой организации до классического SAP-а, где каждый чих и пук жестко формализован в системе, и ни одного лишнего поля в свойствах заказа ты себе позволить не можешь. По крайней мере бесплатно. А текстовый поиск в их демке S/4HANA почему-то выполнялся минуты две. На этом фоне я задаю вопрос: а нужна ли структура данных вообще? Да, она нужна для каких-то ключевых вещей, менее ключевые вещи могут быть опциональны, а остальное — по фантазии конкретного пользователя.

S4/HANA по-своему учитывает эту проблему большого числа необязательных свойств. Структура столбцов и связанных таблиц по прежнему жесткая, но умолчательные значения почти не занимают места в колоночном хранилище (MAIN и DELTA), за счет чего можно натыкать тысячу столбцов в одну табличку и это будет бодро бегать. В своей практике я сталкивался с ситуациями, когда пользователь насоздавал больше тысячи столбцов. А почему бы и нет? В каком-то смысле здесь названия столбцов — это скорее некое вольное выражение свойства сущности, а не строгий протокол отчетности. Все равно с этими данными будет работать только этот пользователь и пару его коллег — пусть работают так, как им удобнее.

Задача же системы состоит в том, чтобы потом организовать поиск во введенной информации, и боже упаси не потерять случайно эту информацию. Если же наложить гибкость организации данных на распределенность, то всплывают такие веселые вещи, как: менеджер сослался в заказе на запись о клиенте, а в то же время в другой копии другой менеджер удалил клиента. Выход — хранить информацию вечно, в том числе информацию обо всех изменениях. Что может внезапно оказаться выполнимым в рамках парадигмы частичных копий данных за счет того, что лишние хронологичные данные будут отбрасываться. Справедливости ради, SAP Cloud Application Programming Model тоже не забывает про такие плюшки, хоть и подразумевает центральную БД, и как бы намекает нам «покупайте SAP HANA, только там вы получите все плюшки от нашей свободной модели».

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Боюсь ты не осилишь новую ERP.

база данных для ERP может работать с приемлимой скоростью только в памяти

Создай гибридную СУБД, работающую с RAM+NVME и окончательной выгрузкой на кластер HDD. И ты получишь целостность данных и скорости чтения/записи до сотен гигабайт в секунду, при желании. Секрет к успеху последовательная запись на HDD.

Впрочем, можешь не заморачиваться, я уже работаю над такой СУБД.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от foror

Создай гибридную СУБД, работающую с RAM+NVME и окончательной выгрузкой на кластер HDD

Ну типа какой-нибудь мускуль или постгрес с асинхронной репликацией имеют ту же архитектуру хранилища. В чем отличие?

Впрочем, можешь не заморачиваться, я уже работаю над такой СУБД

Во, это уже взрослый разговор. Зачем делаешь и где можно будет скачать?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Ну типа какой-нибудь мускуль или постгрес с асинхронной репликацией имеют ту же архитектуру хранилища. В чем отличие?

В том, что это всё должно работать в реальном времени (чтение/запись) на скоростях под 50 ГБ/с на одном сервере без репликации. Мускуль и постгрес не умеет работать с RAM+NVME и кластером из HDD одновременно. Они не знают какие данные кешировать в NVME, какие оставить в RAM, а какие отложить на задворки HDD. Они не умеют в констрейнты на джаве в одной JVM с приложением и не знают текующие потребности этого приложения. Я уже не говорю о синхронизации схемы БД и домена классов на джаве.

Одним словом это устаревшие технологии 20 века, пользуемые по инерции из-за засилья копроэкономики.

Во, это уже взрослый разговор. Зачем делаешь и где можно будет скачать?

«Долго ждать придется, поскольку эта штука у меня не в приоритете» (c)

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 3)
Ответ на: комментарий от byko3y

Зачем делаешь

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

foror ★★★★★
()

Есть очень красивая и удобная ER-модель. На её основе созданы RDBMS. Современные RDBMS это очень надёжные и гибкие системы хранения и обработки данных.

Чтобы представлять «многие-ко-многим» без дополнительных таблиц, тебе нужно:

  1. Изобрести новую математику взамен ER-модели с её реляционной алгеброй.
  2. Написать DBMS на основе этой математики, качеством не хуже таких столпов, как sqlite, postgresql, mssql.
  3. Учесть современный тренд на кластеризацию.
  4. Подождать 30 лет, пока это всё достаточно заматереет для практического использования.

В итоге куда проще написать ORM-обёртку над RDBMS, у которой есть свои минусы, но задачу в итоге такая обёртка решает и там многие-ко-многим выглядят просто и естественно, а дополнительные таблицы это детали реализации.

Впрочем в последние годы появились какие-то новые нереляционные базы вроде mongo db, riac. Думаю, лет через 10 будет смысл на них смотреть, может быть там есть то, что ты хочешь?

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от byko3y

SQL ... принципиально немасштабируем (распределенные вычисления)

Но ведь SQL - это синтаксис... apache hue это ж из хадупа, очень распределённых вычислений.

Shadow ★★★★★
()
Ответ на: комментарий от foror

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от Shadow

Покажи мне бизнес-процесс с настолько динамичными данными, что 1 к N реляция не поможет

SAP? Да, у них много 1-к-1 и 1-к-N, но и N-к-M тоже валом.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Shadow

Но ведь SQL - это синтаксис... apache hue это ж из хадупа, очень распределённых вычислений

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от Legioner

Есть очень красивая и удобная ER-модель. На её основе созданы RDBMS. Современные RDBMS это очень надёжные и гибкие системы хранения и обработки данных

М-м-м... мне отвечать цитатами из конкретных работ Эдгара Кодда? Он замещал сетевые, иерархические, и навигационные базы, и оправдывал свой инструмент тремя факторами: независимость от порядка данных, независимость от индексов, независимость от путей доступа (главная-подчиненная сущность). Современные NoSQL тоже способны обеспечить подобную независимость, разве что DSL для выполнения этих запросов встроен в некий другой язык программирования, а не стоит обособлено сам по себе.

Ну и я еще раз повторюсь, что постгрес и тот же оракл — это не чистые RDBMS, у них есть объектные и темпоральные расширения. Но, к сожалению, на них тяжеловато крутнуть кастомную логику по гигабайту данных, которые при наличии пустых вспомогательных страниц будут занимать все 5-10 Гб на диске.

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

Raik, Cassandra, BigTable, HBase, DynamoDB — это всё семейство из братий и сестер, многие из которых, согласно теореме CAP жертвуют целостностью данных ради надежности. Они сделаны прежде всего для 24/7 big data систем, но ERP не входит в число таких систем, поскольку там данных хоть и много, но, как правило, в одну машину они умещаются, и поздней ночью-ранним утром аналитические запросы к базе делать никто не будет.

byko3y ★★★★
() автор топика
3 сентября 2021 г.
Ответ на: комментарий от byko3y

Одна из первых вещей. которая мне вообще в голову пришла, когда я начинал творческие скитания: давайте хранить все данные в одном файле базы аля SQLite и копировать ее между конпами, при этом база будет целиком грузиться в оперативную память и потом читаться, например, через разделяемую память с доступом read-only, с произвольной гибкой и быстрой обработкой любых придумываемых пользователями и программистами типов данных. Такая схема весьма неплохо работает (при соблюдении некоторых условий) для каких-то мелких фирм, вроде тех же аптек с их 50-100 тыс наименований у поставщика и сотне поступающих единиц товара каждый день. Причем, даже на игрофоне. Тупо грузить в память этот файл с данными на несколько сот мегабайт, где его потом можно будет целиком прочитать за долю секунды для выполнения любого запроса чтения. Для внесения изменений в БД такой системы есть более одного подхода, но в любом случае такая упрощенная и упоротая архитектура имеет свои плюсы.

А Tarantool случайно не подойдет?

sanyo1234
()
Ответ на: комментарий от foror

Создай гибридную СУБД, работающую с RAM+NVME и окончательной выгрузкой на кластер HDD. И ты получишь целостность данных и скорости чтения/записи до сотен гигабайт в секунду, при желании. Секрет к успеху последовательная запись на HDD.

Давно хотел узнать, может ли Java Hibernate в распределенное кэширование второго уровня, например в кластере Tarantool?

И имеет ли смысл такая архитектура доступа к данным:

Приложение -> Hibernate -> distributed Hibernate cache (Tarantool cluster) -> классическая РСУБД типа Db2/PG

?

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от foror

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

https://habr.com/ru/post/576106/

Tesla Bot Илона Маска

sanyo1234
()
Ответ на: комментарий от foror

В том, что это всё должно работать в реальном времени (чтение/запись) на скоростях под 50 ГБ/с на одном сервере без репликации. Мускуль и постгрес не умеет работать с RAM+NVME и кластером из HDD одновременно. Они не знают какие данные кешировать в NVME, какие оставить в RAM, а какие отложить на задворки HDD. Они не умеют в констрейнты на джаве в одной JVM с приложением и не знают текующие потребности этого приложения. Я уже не говорю о синхронизации схемы БД и домена классов на джаве.

Это не решается построением архитектуры с использованием различных компонентов, которые умеют в кэширование на соответствующих устройствах?

Самое простое - это уже готовая СУБД поверх ZFS, где включен L2ARC и SLOG на SSD, а остальные vdevs на HDD ? Про 50 GB/s не уверен и у ZFS есть проблема с относительно быстрой фрагментацией на рандомной нагрузке типа СУБД, но можно дефрагментировать через send | receive, если хватает железяк под это.

Почему-то я сомневаюсь, что ты сделаешь лучше.

Кроме того у нормальных СУБД есть так называемая feature: «multi-temperature storage».

https://www.ibm.com/support/producthub/db2/docs/content/SSEPGG_11.5.0/com.ibm...

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от Legioner

Подождать 30 лет, пока это всё достаточно заматереет для практического использования.

Дружище, зачем ждать так долго?

While data in a tables can also be related, as represented in relational databases, the relationship are somewhat simplistic when contrasted to graph data. Data that submits itself to complex many-to-many relationship is more rightly represented with graphs.

https://www.ibm.com/docs/en/db2/11.5?topic=deployments-db2-graph

https://leapgraph.com/graph-vs-relational-databases/

sanyo1234
()
Ответ на: комментарий от byko3y

Ну и я еще раз повторюсь, что постгрес и тот же оракл — это не чистые RDBMS, у них есть объектные и темпоральные расширения. Но, к сожалению, на них тяжеловато крутнуть кастомную логику по гигабайту данных, которые при наличии пустых вспомогательных страниц будут занимать все 5-10 Гб на диске.

А что мешает сжимать данные на диске? Db2 сама умеет, кто не умеет, для тех есть файловые системы со сжатием, например ZFS.

sanyo1234
()
Ответ на: комментарий от sanyo1234

Java Hibernate

Я этим поделием лет 10 не пользуюсь, из них 7 лет в прокрастинации.

И имеет ли смысл такая архитектура доступа к данным

Не у того спрашиваешь. Хотя мой ответ очевиден - не читал, но осуждаю (интуитивно).

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от foror

Я этим поделием лет 10 не пользуюсь, из них 7 лет в прокрастинации.

А чем вместо него?

Прокрастинация - это переосмысление опыта и поиск более оптимальных решений на форумах?

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Это не решается построением архитектуры с использованием различных компонентов, которые умеют в кэширование на соответствующих устройствах?

Это называется зоопарк. Можешь создать свой зоопарк если у тебя есть деньги на железо, софт и смотрителей зоопарка. Я же выше отметил цели «Создать международную корпорацию без единного мешка с мясом и поработить планету». Поэтому это не мой вариант.

Почему-то я сомневаюсь, что ты сделаешь лучше.

Сомневающийся подобен морской волне, ветром поднимаемой и развеваемой (c)

Кроме того у нормальных СУБД есть так называемая feature: «multi-temperature storage».

Я не Билл Гейтс с кровным родственником на руководящей должности в IBM. Поэтому свои игрушки строгаем сами, ибо на чужие нет денег. И сырцы не покажут.

foror ★★★★★
()
Ответ на: комментарий от sanyo1234

А чем вместо него?

https://jdbi.org + PostgreSQL

Прокрастинация - это переосмысление опыта и поиск более оптимальных решений на форумах?

Да. Под 5000 ссылок уже нагрёб, осталось всё это детальнее разобрать и погрузиться в работу над первым MVP.

foror ★★★★★
()
Ответ на: комментарий от foror

Это называется зоопарк. Можешь создать свой зоопарк если у тебя есть деньги на железо, софт и смотрителей зоопарка. Я же выше отметил цели «Создать международную корпорацию без единного мешка с мясом и поработить планету». Поэтому это не мой вариант.

С программным зоопарком легко управятся софтовые операторы.

А чем тебе не нравятся человеки? Своей недетерминированностью?

sanyo1234
()
Ответ на: комментарий от foror

Я не Билл Гейтс с кровным родственником на руководящей должности в IBM. Поэтому свои игрушки строгаем сами, ибо на чужие нет денег. И сырцы не покажут.

В PG вроде бы тоже есть multi-temperature storage? Но это не совсем то, в том смысле, что оно работает не автоматически (хоть в PG, хоть в Db2).

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

А чем тебе не нравятся человеки? Своей недетерминированностью?

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

foror ★★★★★
()
Ответ на: комментарий от sanyo1234

Один без спонсора? Open source?

Один, да, без ансамбля. Но изначально планируется простейшая СУБД с плотной интеграцией в JVM. Чтобы выйти из многолетней прокростинации и показать хипстерам как нужно зарабатывать в интернете.

foror ★★★★★
()
Ответ на: комментарий от sanyo1234

Давно хотел узнать, может ли Java Hibernate в распределенное кэширование второго уровня, например в кластере Tarantool?

По документации может.

И имеет ли смысл такая архитектура доступа к данным:

По-мне, чем меньше кешей, тем лучше. БД и сама прекрасно справляется с кешированием своих данных, зачем ещё какие-то кеши городить. Засунь на сервер хоть терабайты оперативной памяти, нынче это дёшево, если у тебя такие нагрузки.

Любые кеши вне БД это проблема их актуальности, если данные меняются другими приложениями (а они будут меняться, обязательно будут, как бы ты ни хорохорился, что у тебя всё через твой слой идёт). Ещё в Hibernate достаточно примитивная логика управления кешированными данными и если ты в ней не разбираешься, у тебя кеши постоянно будут инвалидироваться, то бишь толку будет немного. Ещё Hibernate можно обходить с помощью JDBC и тут ты уже должен сам инвалидировать что нужно, а это задача нетривиальная и ошибки в ней чреваты багами из-за неактуальных кешей (или проседанием производительности из-за слишком активной инвалидации). А БД умная, сама следит за своими кешами и всегда работает корректно.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от foror

Один, да, без ансамбля. Но изначально планируется простейшая СУБД с плотной интеграцией в JVM. Чтобы выйти из многолетней прокростинации и показать хипстерам как нужно зарабатывать в интернете.

Тогда, может быть, сделаешь сразу как у DevExpress XAF?

https://docs.devexpress.com/eXpressAppFramework/112559/overview/architecture

Чтобы с редактором модели (как в 1Це) и автоматическим обновлением структуры базы и ORM классов.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от Legioner

А БД умная, сама следит за своими кешами и всегда работает корректно.

Это конечно так, но IMHO масштабировать L2 Cache в кластере типа Tarantool проще, чем РСУБД?

sanyo1234
()
Ответ на: комментарий от sanyo1234

ORM не нужна, ее подобие должно быть встроено в СУБД, чтобы не заморачивать пользователей лишними сущностями. Именно поэтому плотная интеграция в JVM.

редактором модели

Для школьников. Разработчику нужна качественная IDE. Но пока обойдёмся имеющими поделиями типа intelij idea или eclipse.

foror ★★★★★
()
Ответ на: комментарий от sanyo1234

Не знаю, на офтопике я только с SOLIDWORKS работаю, ибо аналоги на линуксе совсем уж детские поделки. Но сама идея GUI редактора для модели выглядит ущербно.

foror ★★★★★
()
Ответ на: комментарий от foror

Вроде бы у них был и API для редактирования модели. Насчет декларативного описания целиком не уверен.

sanyo1234
()
Ответ на: комментарий от sanyo1234

У 1Це есть свои СУБД?

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

В том числе есть какая-то своя простенькая.

Речь вероятно о DBF формате? Он использовался в старинных Clipper, FoxPro и т.п., есть различные либы для работы с ним, в т.ч. в ODBC.

https://nastroyvse.ru/programs/review/kak-i-chem-otkryvat-dbf-fajl.html

К компании 1Це DBF имеет такое же точно отношение как MSSQL или Windows, т.е. почти никакое кроме того, что 1Це использует эти технологии.

sanyo1234
()
Ответ на: комментарий от sanyo1234

А Tarantool случайно не подойдет?

Tarantool — это реализация той самой первой идеи, которая мне пришла в голову для решения задачи. То есть, БД работает медленно? Кинем всю БД в оперативу. Тип данных не ясен изначально? Хорошо, сделаем динамический тип изначально. Дорого общаться через сокет с процессом сервера? Кинем логику в сам сервер.

Они там умудрились еще и сделать строго однопоточный, но асинхронный выполнитель транзакций. То есть, у них из коробки уровень изоляции serializable — что есть удобно с точки зрения простоты работы Тьюринг-машины, и полнейший провал с точки зрения производительности работы БД. Например:
https://www.tarantool.io/en/doc/latest/tutorials/lua_tutorials/
25-30 тысяч вставок в секунду. Курам на смех. Самый захудалый мускуль выдаст столько же на жестком диске при условии пакетной вставки.

Первые мои идеи были года 4-5 назад, но я уже в своих изысканиях уехал намного дальше, и прежде всего в необходимости отказываться от классического подхода реляционной БД и клиента в виде Тьюринг-машины. Я сейчас уже пытаюсь придумать что-то для сценария распределенной БД с требованиями строгой согласованности — это одна из самых упоротых ниш в сфере СУБД. Потому что классические требования Тьюринг-машины по неизменяемому старому состоянию-контексту приводят к дичайше медленной работе уровня двойной круговой задержки всей сети (и это только в самом-самом оптимистичном случае без сбоев) — потому большинство якобы ACID СУБД на самом деле даже близко не валялись рядом с ACID, им хотя бы CP из CAP выполнить в полном объеме — и то спасибо. Требования CP не могут выполнить CockroachDB, MongoDB, RethinkDB, Crate, VoltDB, Galera, и прочие бесчисленные выкидыши Big Data, которые все кричат чуть ли не про ACID гарантии.

byko3y ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.