Интересно было бы глянуть на запрос к этим таблицам и основной. Там точно не будет так просто, как вы описываете. С учётом того, что запрос должен строиться автоматически, по алгоритму, это не так важно, хотя к быстродействию на больших таблицах вопросы все таки будут.
А так — да, зумеры придумали более лучший EAV, ибо пришло и их время.
Ага, SQL придумали, чтобы писать запросы к базе на английском языке. А кто их будет писать — программист или менеджер — это не так важно, и эту тему лучше не и поднимать. Для аналитиков в ИТ знание SQL часто обязательно в вакансиях.
Сложно сказать. Сессии запускались в параллель, пока загрузка ЦПУ не достигнет 50-80%. В мониторинге всё выглядело так, причем в кластере всё время что-то происходит даже если мы его не грузим.
Где, например, вы возьмёте специалистов, готовых броться с IDEAV?
IDEAV создавался как самодостаточное решение, с ним не надо бороться. Конечно, придется вникнуть в суть визуальной разработки и особенности интерфейса, но вот в код залезать не придется, если вы про это.
достаточно знать SQL, особенности конкретной СУБД и иметь некоторый опыт.
Не спорю. Однако у малого и среднего бизнеса таких людей в распоряжении нет, равно как и бюджета на них. Им нужен быстрый старт, и чтобы в течение дня-двух уже что-то можно было использовать: базу данных, отчеты, дэшборды. Весь ноукод заточен под это, и иногда можно сделать несложное приложение достаточно быстро, например, как здесь, где бэк и фронт сделаны буквально за 15 минут (хотя ролик занял часов 5): https://rutube.ru/video/c85b3e7e11dc9f96f0f091d308968126/
Знаток SQL и особенностей СУБД, а также Python и Apache будет вам 1-2 дня только «проект разворачивать». Поэтому эксель до сих пор живее всех.
Да, точечные запросы, а также те, которые выбирают в пределах сотен тысяч записей, работают оптимально с точки зрения индексов, потому что проиндексированы буквально все данные и их связи.
Это, безусловно, работает на порядок-два медленнее, чем идеально настроенные традиционные таблицы, но с ростом сложности системы не требует профессиональной настройки и работает с приемлемой скоростью, в чем вы можете сами убедиться.
Вы правы, обычную таблицу можно идеально настроить и она изначально не несет таких накладных расходов, как унифицированная таблица конструктора.
Однако, квалифицированный админ для идеальной настройки стоит дорого, и не всем доступны IT-спецы в принципе. Нередко можно наблюдать составные индексы размером в 5-7 раз больше таблицы, а база всё равно тормозит.
И я правильно понимаю, что если запрос занимает 1 секунду выполняясь на всех ядрах, то производительность системы составляет 1 запрос в секунду?
На нагруженной системе это означает, что запрос ждет своей очереди на выполнение, а параллельно выполняются десятки других запросов — чуть меньше, чем количество ядер в системе. Производительность же всей системы может достигать 3000 запросов в секунду — так было в ходе тестов. Вот тут был проведен нагрузочный тест на достаточно сложных запросах, которые агрегируют сотни и тысячи записей:
Спасибо за ваши 5 копеек! Чувствуется, мы шли одинаковыми путями время от времени.
Обычно любое удобство подразумевает плату, так и в случае ноукода в общем и IDEAV в частности. Приходится идти на некий компромисс и всё равно удается оставаться в значительном плюсе.
пропадает типизация, все значения представляют текст;индекс строится по тексту, а значит в общем случае будет неверный ( 2 < 11, но '2' > '11' );
Достаточно редко в БД используется поиск по диапазону, и тогда есть 2 варианта:
а) (по умолчанию) числовые значения преобразуются из текста в число, при этом индекс не работает, но на быстродействии это не сказывается сколько-нибудь заметно.
б) определить размерность числовому полю в метаданных, дополнять все числа нулями до этой размерности и тогда они корректно сравниваются с применением индекса: '002' < '011'
основе статистики значений в колонках таблицы, а колонка значений у нас одна и в ней полный мусор;пропадает локализация данных, если в широкой табличке кортеж "обычно" помещается в блок данных, то в случае EAV он может быть раскидан по всему сегменту;
Полностью согласен. Однако, негативный эффект от этого практически незаметен. Есть клиенты, кто пользуется такими решениями 10 лет и больше и даже не подозревают о существовании этой проблемы.
Стоит оговориться, что мы пока не работали с БД свыше 20-30ГБ, а в этой статье мы замахиваемся на терабайты, и тут нас ждет уже какое-то количество новых вызовов, к которым мы готовы, в отличие, например, от ситуации 5 лет назад.
... а вы не думали сохранить low-code генератор, но генерировать не eav - структуры, а живые, настоящие таблички и др. объекты конкретной СУБД? Имхо, можно было бы многое упростить.
Настоящие таблички требуют совсем другой уровень сопровождения. В IDEAV проиндексировано всё и это работает под капотом, не требуя оптимизации программистом. Можно создавать вообще любые структуры.
В простых табличках с ростом данных это превращается в реальную проблему, и, я так понимаю, это один из стопперов , с какими вы сталкивались.
Неоднократно задумывались, да. Это что-то другое всё равно должно быть реляционным, и лучше реляционной СУБД мы ничего не придумали. Есть мысли, как сделать РСУБД более приспособленной под эту задачу, а именно, редуцировать её движок и добавить в него немногочисленные доработrи для поддержки IDEAV.
Одна из идей — сделать все 3 индекса покрывающими на все 4 поля, что позволит вообще не хранить данные в таблице, а выбирать их исключительно из индексов. Это заметно ускорит работу базы при приемлемых накладных расходах.
Я тоже использую gigachat для небольших задач, типа написать скрипт для нагрузочного тестирования или вроде того. Но тут проблема в том, что копилоты AI не имеют архитектурного видения и не могут создать архитектурный креатив, потому что переиспользуют что есть.
Интересно было бы глянуть на запрос к этим таблицам и основной. Там точно не будет так просто, как вы описываете. С учётом того, что запрос должен строиться автоматически, по алгоритму, это не так важно, хотя к быстродействию на больших таблицах вопросы все таки будут.
А так — да, зумеры придумали более лучший EAV, ибо пришло и их время.
Ага, SQL придумали, чтобы писать запросы к базе на английском языке. А кто их будет писать — программист или менеджер — это не так важно, и эту тему лучше не и поднимать. Для аналитиков в ИТ знание SQL часто обязательно в вакансиях.
Сложно сказать. Сессии запускались в параллель, пока загрузка ЦПУ не достигнет 50-80%. В мониторинге всё выглядело так, причем в кластере всё время что-то происходит даже если мы его не грузим.
IDEAV создавался как самодостаточное решение, с ним не надо бороться. Конечно, придется вникнуть в суть визуальной разработки и особенности интерфейса, но вот в код залезать не придется, если вы про это.
Не спорю. Однако у малого и среднего бизнеса таких людей в распоряжении нет, равно как и бюджета на них. Им нужен быстрый старт, и чтобы в течение дня-двух уже что-то можно было использовать: базу данных, отчеты, дэшборды. Весь ноукод заточен под это, и иногда можно сделать несложное приложение достаточно быстро, например, как здесь, где бэк и фронт сделаны буквально за 15 минут (хотя ролик занял часов 5):
https://rutube.ru/video/c85b3e7e11dc9f96f0f091d308968126/
Знаток SQL и особенностей СУБД, а также Python и Apache будет вам 1-2 дня только «проект разворачивать». Поэтому эксель до сих пор живее всех.
Да, точечные запросы, а также те, которые выбирают в пределах сотен тысяч записей, работают оптимально с точки зрения индексов, потому что проиндексированы буквально все данные и их связи.
Это, безусловно, работает на порядок-два медленнее, чем идеально настроенные традиционные таблицы, но с ростом сложности системы не требует профессиональной настройки и работает с приемлемой скоростью, в чем вы можете сами убедиться.
Вы правы, обычную таблицу можно идеально настроить и она изначально не несет таких накладных расходов, как унифицированная таблица конструктора.
Однако, квалифицированный админ для идеальной настройки стоит дорого, и не всем доступны IT-спецы в принципе. Нередко можно наблюдать составные индексы размером в 5-7 раз больше таблицы, а база всё равно тормозит.
На нагруженной системе это означает, что запрос ждет своей очереди на выполнение, а параллельно выполняются десятки других запросов — чуть меньше, чем количество ядер в системе. Производительность же всей системы может достигать 3000 запросов в секунду — так было в ходе тестов.
Вот тут был проведен нагрузочный тест на достаточно сложных запросах, которые агрегируют сотни и тысячи записей:
https://habr.com/ru/companies/neoflex/articles/451218/
Ранее мы делали такое сравнение, и читателями оно было воспринято скептически. Материал есть здесь: https://habr.com/ru/articles/414255/
Какой программист любит кодить? Да почти никакой старше джуна не любит, наверное.
Поэтому no-code в целевом его виде, без ограничений и костылей, я считаю — это всё таки для программистов.
Современный программист не столько программирует, сколько ищет, изучает, подключает и конфигурирует.
Кстати, покликать одну из последних версий конструктора Интеграм можно здесь:
https://integram.io/login.html#reg
Спасибо за ваши 5 копеек! Чувствуется, мы шли одинаковыми путями время от времени.
Обычно любое удобство подразумевает плату, так и в случае ноукода в общем и IDEAV в частности. Приходится идти на некий компромисс и всё равно удается оставаться в значительном плюсе.
Достаточно редко в БД используется поиск по диапазону, и тогда есть 2 варианта:
а) (по умолчанию) числовые значения преобразуются из текста в число, при этом индекс не работает, но на быстродействии это не сказывается сколько-нибудь заметно.
б) определить размерность числовому полю в метаданных, дополнять все числа нулями до этой размерности и тогда они корректно сравниваются с применением индекса: '002' < '011'
Полностью согласен. Однако, негативный эффект от этого практически незаметен. Есть клиенты, кто пользуется такими решениями 10 лет и больше и даже не подозревают о существовании этой проблемы.
Стоит оговориться, что мы пока не работали с БД свыше 20-30ГБ, а в этой статье мы замахиваемся на терабайты, и тут нас ждет уже какое-то количество новых вызовов, к которым мы готовы, в отличие, например, от ситуации 5 лет назад.
Настоящие таблички требуют совсем другой уровень сопровождения. В IDEAV проиндексировано всё и это работает под капотом, не требуя оптимизации программистом. Можно создавать вообще любые структуры.
В простых табличках с ростом данных это превращается в реальную проблему, и, я так понимаю, это один из стопперов , с какими вы сталкивались.
Иллюстрация про покрывающие индексы
Неоднократно задумывались, да. Это что-то другое всё равно должно быть реляционным, и лучше реляционной СУБД мы ничего не придумали. Есть мысли, как сделать РСУБД более приспособленной под эту задачу, а именно, редуцировать её движок и добавить в него немногочисленные доработrи для поддержки IDEAV.
Одна из идей — сделать все 3 индекса покрывающими на все 4 поля, что позволит вообще не хранить данные в таблице, а выбирать их исключительно из индексов. Это заметно ускорит работу базы при приемлемых накладных расходах.
Я тоже использую gigachat для небольших задач, типа написать скрипт для нагрузочного тестирования или вроде того. Но тут проблема в том, что копилоты AI не имеют архитектурного видения и не могут создать архитектурный креатив, потому что переиспользуют что есть.
Глаз-алмаз. Так назвали базу для презентации для коллег из Сбера по их тематике - карточные операции.
Да, бывает, сочувствую. Хотя это не порок лоукода, это в другой плоскости проблема.
Вот так могут выглядеть строчки из примера в статье в базе данных.
Покликать можно здесь:
https://integram.io/