Comments 34
не люблю я этот love code
сплошной vendor lock
нас вот бросил вендор и теперь от системы сплошная отрыжка и несварение
Да, бывает, сочувствую. Хотя это не порок лоукода, это в другой плоскости проблема.
у вас там Сбер на одном скриншоте )
Глаз-алмаз. Так назвали базу для презентации для коллег из Сбера по их тематике - карточные операции.
Здесь есть демка на тему больших таблиц и поиска по любому полю, скрины из её копии
https://ideav.pro/sber
После появления разных копилотов AI необходимость в классических NoCode-решениях стала под большим вопросом. Фактически, AI становится новым NoCode/LowCode для обычных сред разработки.
Я тоже использую gigachat для небольших задач, типа написать скрипт для нагрузочного тестирования или вроде того. Но тут проблема в том, что копилоты AI не имеют архитектурного видения и не могут создать архитектурный креатив, потому что переиспользуют что есть.
Кстати, покликать одну из последних версий конструктора Интеграм можно здесь:
IDEAV действительно интересный подход, особенно для no-code решений, где масштабируемость — больная тема. Партиции в PostgreSQL — мощный инструмент, но важно помнить, что эффективность зависит от нагрузки и структуры запросов.
Да, no-code ≠ «без архитектуры». Без понимания данных даже лучшие инструменты дадут слабый результат.
Современные СУБД разрабатывались для реализации Реляционной модели данных. И для этого они хороши. Разрабатывая ERP-решения году так в 2002-2003, я тоде пытался приспособить СУБД под работу с Расширяемыми Объектами, в которых добавление новых атрибутов, изменения поведения Объектов, их визуальное представление и т.д. было бы версионируемым и проводилось бы в один клик на визуальной формочке без написания кода. Но пришел к выводу, что "натягиваю Сову на Глобус" и что для моей идеи надо что-то другое, а не СУБД Реляционной модели. Вы над этим не задумывались?
Неоднократно задумывались, да. Это что-то другое всё равно должно быть реляционным, и лучше реляционной СУБД мы ничего не придумали. Есть мысли, как сделать РСУБД более приспособленной под эту задачу, а именно, редуцировать её движок и добавить в него немногочисленные доработrи для поддержки IDEAV.
Одна из идей — сделать все 3 индекса покрывающими на все 4 поля, что позволит вообще не хранить данные в таблице, а выбирать их исключительно из индексов. Это заметно ускорит работу базы при приемлемых накладных расходах.
Иллюстрация про покрывающие индексы
У нас свой вариант EAV, часто очень привлекательно для клиентов: "вот смотрите, вы всё сами сможете, без привлечения разработчиков" - продавцы довольно успешно охмуряет клиентов. Реальность ВСЕГДА оказывается сложнее простых примеров от продавцов, и попавшие в ловушку клиенты привлекают нас, разработчиков. А уж мы вовсю страдаем, натягивая сову на глобус. Масштабируемость, нестандартные бизнес - правила, сложность интеграции с существующими фреймворками (например, с системой отчетов), проблема автоматизации переноса метаданных, трудности с поиском специалистов, готовых во всем этом вариться...
... а вы не думали сохранить low-code генератор, но генерировать не eav - структуры, а живые, настоящие таблички и др. объекты конкретной СУБД? Имхо, можно было бы многое упростить.
... а вы не думали сохранить low-code генератор, но генерировать не eav - структуры, а живые, настоящие таблички и др. объекты конкретной СУБД? Имхо, можно было бы многое упростить.
Настоящие таблички требуют совсем другой уровень сопровождения. В IDEAV проиндексировано всё и это работает под капотом, не требуя оптимизации программистом. Можно создавать вообще любые структуры.
В простых табличках с ростом данных это превращается в реальную проблему, и, я так понимаю, это один из стопперов , с какими вы сталкивались.
Для оптимизации при работе с нативными обьектами вовсе не нужно быть академиком, достаточно знать SQL, особенности конкретной СУБД и иметь некоторый опыт. А ваша система - лишние уровни абстракции, и всё ради борьбы с выдуманной проблемой. Где, например, вы возьмёте специалистов, готовых броться с IDEAV?
достаточно знать SQL, особенности конкретной СУБД и иметь некоторый опыт.
Не спорю. Однако у малого и среднего бизнеса таких людей в распоряжении нет, равно как и бюджета на них. Им нужен быстрый старт, и чтобы в течение дня-двух уже что-то можно было использовать: базу данных, отчеты, дэшборды. Весь ноукод заточен под это, и иногда можно сделать несложное приложение достаточно быстро, например, как здесь, где бэк и фронт сделаны буквально за 15 минут (хотя ролик занял часов 5):
https://rutube.ru/video/c85b3e7e11dc9f96f0f091d308968126/
Знаток SQL и особенностей СУБД, а также Python и Apache будет вам 1-2 дня только «проект разворачивать». Поэтому эксель до сих пор живее всех.
Где, например, вы возьмёте специалистов, готовых броться с IDEAV?
IDEAV создавался как самодостаточное решение, с ним не надо бороться. Конечно, придется вникнуть в суть визуальной разработки и особенности интерфейса, но вот в код залезать не придется, если вы про это.
У заказчика собственные требования и к графическому интерфейсу, и к формату/форме отчетов, и к принципам разграничения доступа к данным - в код залезать придется. ...а для для примитивных случаев есть Excel.
Если позволите, поделюсь опытом. Я участвовал в более полусотни проектов на конструкторе Интеграм, у которого под капотом IDEAV, и могу сказать, что в код конструктора залезать нет необходимости.
Графический интерфейс можно натянуть любой — на реакте, Vue или обычном HTML+js+css. Можно делать SPA с бэкендом в Интеграме, но также в конструкторе есть шаблонизатор, который можно использовать для server-side rendering.
Разграничение доступа делается ролями в несколько кликов, с точностью до атрибутов по маске или вычисляемому значению.
Масштабируемость, нестандартные бизнес - правила, сложность интеграции с существующими фреймворками (например, с системой отчетов)
Кстати, про системы отчетов: Power BI
Позвольте вставить свои 5 копеек.
Бум No-code начался в 2022 году, и сейчас многие компании стараются так или иначе внедрить функционал «low-code» в свои продукты
На самом деле "бум" low/no-code платформ продолжается еще с прошлого века. Каждый год появляются новые платформы, которые амбициозно спешат изменить мир ИТ.
В своей компании мы успели попробовать ELMA, PEGA, и разработали 2 собственных low-code платформы, почерпнув якобы "лучшее". Это я упоминаю к тому, что я не противник подхода, но нужно понимать, что у каждого инструмента своя сфера применения.
Хранение данных в виде key-value (EAV) безусловно имеет свои преимущества, но также имеет серьезные недостатки (особенно в случае postgresql):
пропадает типизация, все значения представляют текст;
индекс строится по тексту, а значит в общем случае будет неверный ( 2 < 11, но '2' > '11' );
в общем случае планы запроса будут "плохие", т.к. планировщик пытается применить эвристики на основе статистики значений в колонках таблицы, а колонка значений у нас одна и в ней полный мусор;
пропадает локализация данных, если в широкой табличке кортеж "обычно" помещается в блок данных, то в случае EAV он может быть раскидан по всему сегменту;
при частом изменении данных будет расти фрагментация, и даже автовакуум тут не поможет на 100%;
можно конечно попытаться в значении хранить jsonb, строить по нему индекс и в целом пытаться из postgres сделать no-sql бд, но возможно проще сразу использовать no-sql;
к слову, в своих наработках мы экспериментировали с разными способами хранения, и в конечном итоге пришли к созданию честных таблиц.
FUNCTIONpublic.post_objects
Очень надеюсь, что это функция чисто для теста, поскольку в ней чистой воды SQLi. Вообще в коде стоит использовать только prepared-statement-ы, никакого ручного sql.
Результат выборки хуже предсказанного планировщиком, потому что база серьезно нагружена
План запроса никак не зависит от нагрузки на бд, только от "статистики" значений. А план с миллиардом читаемых строк выглядит мягко говоря "не очень".
Спасибо за ваши 5 копеек! Чувствуется, мы шли одинаковыми путями время от времени.
Обычно любое удобство подразумевает плату, так и в случае ноукода в общем и IDEAV в частности. Приходится идти на некий компромисс и всё равно удается оставаться в значительном плюсе.
пропадает типизация, все значения представляют текст;индекс строится по тексту, а значит в общем случае будет неверный ( 2 < 11, но '2' > '11' );
Достаточно редко в БД используется поиск по диапазону, и тогда есть 2 варианта:
а) (по умолчанию) числовые значения преобразуются из текста в число, при этом индекс не работает, но на быстродействии это не сказывается сколько-нибудь заметно.
б) определить размерность числовому полю в метаданных, дополнять все числа нулями до этой размерности и тогда они корректно сравниваются с применением индекса: '002' < '011'
основе статистики значений в колонках таблицы, а колонка значений у нас одна и в ней полный мусор;пропадает локализация данных, если в широкой табличке кортеж "обычно" помещается в блок данных, то в случае EAV он может быть раскидан по всему сегменту;
Полностью согласен. Однако, негативный эффект от этого практически незаметен. Есть клиенты, кто пользуется такими решениями 10 лет и больше и даже не подозревают о существовании этой проблемы.
Стоит оговориться, что мы пока не работали с БД свыше 20-30ГБ, а в этой статье мы замахиваемся на терабайты, и тут нас ждет уже какое-то количество новых вызовов, к которым мы готовы, в отличие, например, от ситуации 5 лет назад.
На самом деле "бум" low/no-code платформ продолжается еще с прошлого века. Каждый год появляются новые платформы, которые амбициозно спешат изменить мир ИТ.
Полностью согласен - инструменты RAD (Borland Delphi, Clarion, Ms Visual Basic, Oracle Forms, Sybase Power Builder) появились еще в начале-середине 1990-х годов того века. Кроме того были такие инструменты как "Oracle Designer" - где разработчик определял модель данных (таблицы, связи между ними) и на основе нее автоматически генерировались GUI-формочки для Oracle Forms и отчеты для Oracle Reports (MVP продукт, который можно было дальше самостоятельно доработать напильником). Примерно также мог Sybase PowerDesigner для PowerBuilder. С приходом Web-интерфейсов эта тема почему-то заглохла. Текущий Oracle APEX, который представляют как LOW-Code решение, сильно не дотягивает до своих предшественников - Forms & Designer. Хотя... в последние версии, вроде бы завезли автоматизацию Бизнес-Процессов (пристально не смотрел)
Хранение данных в виде key-value (EAV) безусловно имеет свои преимущества, но также имеет серьезные недостатки (особенно в случае postgresql):пропадает типизация, все значения представляют текст;
Не обязательно все значения в EAV должны быть текстовые. Есть и такой вариант организации таблицы значений объектов (в псевдокоде)
CREATE TABLE OBJECT_ATTRIBUTE_VALUE
(
-- идентификация атрибуат объекта определенного типа
, object_id INTEGER NOT NULL -- ID объекта (экземпляра объекта)
, object_type_id INTEGER NOT NULL -- ID типа объекта (класса объекта)
, attribite_id INTEGER NOT NULL -- ID типа атрибута
-- значения атрибута в зависимости от типа данных (одно из полей)
, num_value NUMBER
, text_value TEXT
, date_value DATE
-- ... еще какие-либо типы значений....
-- историчность изменения значения
, time_start DATETIME NOT NULL DEFAULT CURRENT_DATETIME
, time_end DATETIME NOT NULL DEFAULT LAST_DATE_TIME_FOR_DB
);И из этой таблицы извлекать нужные нам атрибуты экземпляров объекта определенного типа, на определенную дату или диапазон.
Но как я и вы выше правильно отметили, что это действо превращается в "одевание трусов через голову" с плохими показателями производительности, и не совсем соответствует принципам Реляционной модели.
Это простой пример (я с 2003 года уже подзабыл все свои решения на эту тему), который конечно же можно улучшить, но это не будет кардинальным улучшением и решением проблемы.
Это простой пример (я с 2003 года уже подзабыл все свои решения на эту тему), который конечно же можно улучшить, но это не будет кардинальным улучшением и решением проблемы.
В статье выше описано кардинально е улучшение, если вдуматься: метаданные + данные на 700 млн строк и оно работает.
До законченного кейса с масштабированием таких проектов ещё надо дожить, но техническая подоплёка вполне на достойном уровне, чтобы всё получилось.
Не хватает сравнения производительности по сравнению с таблицей в классическом стандартном виде. И я правильно понимаю, что если запрос занимает 1 секунду выполняясь на всех ядрах, то производительность системы составляет 1 запрос в секунду?
Не хватает сравнения производительности по сравнению с таблицей в классическом стандартном виде.
Ранее мы делали такое сравнение, и читателями оно было воспринято скептически. Материал есть здесь: https://habr.com/ru/articles/414255/
И я правильно понимаю, что если запрос занимает 1 секунду выполняясь на всех ядрах, то производительность системы составляет 1 запрос в секунду?
На нагруженной системе это означает, что запрос ждет своей очереди на выполнение, а параллельно выполняются десятки других запросов — чуть меньше, чем количество ядер в системе. Производительность же всей системы может достигать 3000 запросов в секунду — так было в ходе тестов.
Вот тут был проведен нагрузочный тест на достаточно сложных запросах, которые агрегируют сотни и тысячи записей:
Не хватает сравнения производительности по сравнению с таблицей в классическом стандартном виде
Так к гадалке не ходи, обычные таблицы будут быстрее. И простора для оптимизации будет больше.
Вы правы, обычную таблицу можно идеально настроить и она изначально не несет таких накладных расходов, как унифицированная таблица конструктора.
Однако, квалифицированный админ для идеальной настройки стоит дорого, и не всем доступны IT-спецы в принципе. Нередко можно наблюдать составные индексы размером в 5-7 раз больше таблицы, а база всё равно тормозит.
Нередко можно наблюдать составные индексы размером в 5-7 раз больше таблицы, а база всё равно тормозит.
А ваша схема подобные запросы вытащит? Верится с трудом, как правило eav будет в несколько раз медленнее классической реляционной схемой.
Да, точечные запросы, а также те, которые выбирают в пределах сотен тысяч записей, работают оптимально с точки зрения индексов, потому что проиндексированы буквально все данные и их связи.
Это, безусловно, работает на порядок-два медленнее, чем идеально настроенные традиционные таблицы, но с ростом сложности системы не требует профессиональной настройки и работает с приемлемой скоростью, в чем вы можете сами убедиться.
Low-code без границ: 32 млрд квартетов и терабайты данных в конструкторе приложений