На ванильных тестах, под конкретный пример, без учета переплаты за неиспользуемую мощность тарелочки и без возможности масштабирования вне её пределов – да, вполне возможно показать кратный прирост скорости. Но архитектурно здесь же никакого прорыва нет, просто жестко скомпонованная многоядерная система, не?
Что-то здесь не сходится. Как уже упоминали здесь, данных на много порядков больше, чем процессоров, поэтому их надо как-то к процессору доставить из всего массива памяти - затолкать в немногочисленные регистры, чтобы обработать. И здесь никуда бутылочное горлышко на доставку не денется, а с учетом размера тарелочки, ещё и дольше должно оказаться.
Да, нужно открыть Студию и там исправить это или повелеть агенту, он сам всё сделает. Это займет меньше 5 минут вместе с ввкладыванием на сайт, и руками будет чуть быстрее, чем агентом.
Есть общее решение для всех сценариев — предельная унификация данных. Затыкая дыры ради конкретных сценариев, вы строите себе ловушки на будущее и утяжеляете платформу. Ну, то есть, идете путем описанных в статье неудачливых корпораций.
Интересно было бы глянуть на запрос к этим таблицам и основной. Там точно не будет так просто, как вы описываете. С учётом того, что запрос должен строиться автоматически, по алгоритму, это не так важно, хотя к быстродействию на больших таблицах вопросы все таки будут.
А так — да, зумеры придумали более лучший 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 проиндексировано всё и это работает под капотом, не требуя оптимизации программистом. Можно создавать вообще любые структуры.
В простых табличках с ростом данных это превращается в реальную проблему, и, я так понимаю, это один из стопперов , с какими вы сталкивались.
На ванильных тестах, под конкретный пример, без учета переплаты за неиспользуемую мощность тарелочки и без возможности масштабирования вне её пределов – да, вполне возможно показать кратный прирост скорости.
Но архитектурно здесь же никакого прорыва нет, просто жестко скомпонованная многоядерная система, не?
Что-то здесь не сходится. Как уже упоминали здесь, данных на много порядков больше, чем процессоров, поэтому их надо как-то к процессору доставить из всего массива памяти - затолкать в немногочисленные регистры, чтобы обработать. И здесь никуда бутылочное горлышко на доставку не денется, а с учетом размера тарелочки, ещё и дольше должно оказаться.
Да, нужно открыть Студию и там исправить это или повелеть агенту, он сам всё сделает. Это займет меньше 5 минут вместе с ввкладыванием на сайт, и руками будет чуть быстрее, чем агентом.
Use case примерно такой, и это годится не только для программиста, но и для пытливого пользователя с архитектурным видением
https://rutube.ru/video/c85b3e7e11dc9f96f0f091d308968126/
Да, похоже, вообще не искал, а использует сообщество как экспертную систему :-)
Вот тебе пара ссылок, брат, бери сразу IDEAV, далеко пойдешь.
https://habr.com/ru/companies/neoflex/articles/433058/
https://habr.com/ru/articles/900308/
Если интересно, дам и сам код ядра.
Не думали применить предельную унификацию данных? На ваших объемах будет прекрасно работать: https://habr.com/ru/companies/neoflex/articles/433058/
Ну и масштабировать тоже есть куда, там всё просто:
https://habr.com/ru/articles/900308/
Есть общее решение для всех сценариев — предельная унификация данных. Затыкая дыры ради конкретных сценариев, вы строите себе ловушки на будущее и утяжеляете платформу. Ну, то есть, идете путем описанных в статье неудачливых корпораций.
Давайте обсудим в личке.
Интересно было бы глянуть на запрос к этим таблицам и основной. Там точно не будет так просто, как вы описываете. С учётом того, что запрос должен строиться автоматически, по алгоритму, это не так важно, хотя к быстродействию на больших таблицах вопросы все таки будут.
А так — да, зумеры придумали более лучший 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 проиндексировано всё и это работает под капотом, не требуя оптимизации программистом. Можно создавать вообще любые структуры.
В простых табличках с ростом данных это превращается в реальную проблему, и, я так понимаю, это один из стопперов , с какими вы сталкивались.