Так-то она работает публично лет 5. А первая инсталляция была в 2006 и до сих пор там пользуются. Спускаться на уровень ниже не приходилось с 2008 года, с версии 1.0.
Видел, поверьте. Это обычная реляционная БД, там все стандартные приемы работают: шардрование и прочее. Опыт есть в известном всем зеленом энтерпрайзе, всё будет работать. Да вот хотя бы в соседней статье посмотрите тесты: https://habr.com/ru/articles/900308/
SELECT a299.val 'Date',a299.id i1,a585.val 'Номер',a1003.val 'Приход',a286_val 'Договор', i5,a278_val 'Контрагент', i6,a303_val 'К-во', i7,a282_val 'Номенклатура', i8,a332_val 'Цена',a829_val 'НДС',a354_val 'Ставка НДС', i11,a3572_val 'Сумма',a336.val 'Пользователь',a301.val 'Создано'
FROM misa a299
LEFT JOIN misa a2891 ON a2891.up=a299.id AND a2891.t=2891
LEFT JOIN misa a585 ON a585.up=a299.id AND a585.t=585
LEFT JOIN misa a1003 ON a1003.up=a299.id AND a1003.t=1003
LEFT JOIN (misa r336 CROSS JOIN misa a336 USE INDEX (PRIMARY)) ON r336.up=a299.id AND a336.id=r336.t AND a336.t=18 AND r336.val='336'
LEFT JOIN misa a301 ON a301.up=a299.id AND a301.t=301
LEFT JOIN (SELECT r286.up,a286.val a286_val,a286.id i5,a286.id a286_id
FROM misa r286,misa a286 USE INDEX (PRIMARY)
WHERE a286.id=r286.t AND a286.t=286
) a286 ON a286.up=a299.id
LEFT JOIN (SELECT r278.up,a278.val a278_val,a278.id i6
FROM misa r278,misa a278 USE INDEX (PRIMARY)
WHERE a278.id=r278.t AND a278.t=278
) a278 ON a278.up=a286_id
LEFT JOIN (SELECT a303.up,a303.val a303_val,a303.id i7,a303.id a303_id,a332.val a332_val,a829.val a829_val,a3572.val a3572_val
FROM misa a303 /* We are an Array */
LEFT JOIN misa a332 ON a332.up=a303.id AND a332.t=332
LEFT JOIN misa a829 ON a829.up=a303.id AND a829.t=829
LEFT JOIN misa a3572 ON a3572.up=a303.id AND a3572.t=3572
WHERE a303.t=303
) a303 ON a303.up=a299.id
LEFT JOIN (SELECT r282.up,a282.val a282_val,a282.id i8
FROM misa r282,misa a282 USE INDEX (PRIMARY)
WHERE a282.id=r282.t AND a282.t=282
) a282 ON a282.up=a303_id
LEFT JOIN (SELECT r354.up,a354.val a354_val,a354.id i11
FROM misa r354,misa a354 USE INDEX (PRIMARY)
WHERE a354.id=r354.t AND a354.t=354
) a354 ON a354.up=a303_id
WHERE a299.up!=0 AND length(a299.val)!=0 AND a299.t=299 AND a299.val='20251231' AND (a2891.val IS NULL OR a2891.val IS NULL)
ORDER BY a299.val,a301.val LIMIT 25
Вовсе нет. Пример: у нас у клиента биллинговая система по стримам на музыкальных площадках, и там больше 20 млн записей статистики о стримах, взаиморсчетах и прочем.
Ведется биллинг и считаются агрегаты: по ним или общая отчетность считается, которая в пределах 10000 записей обрабатывает (тысячи треков, альбомов, артистов), или статистика по конкретному артисту, что может составлять 10-50 тысяч записей, поэтому запрашивается страницами по 5000 записей и не дает фронту тормозить.
Прямо сейчас всё просто - в случае с яблоками делается бронь, а в случае успеха - покупка. Кто первый оставил бронь, тот и купит. Бронь делается с фронта.
Хорошо бы сравнить жизнеспособность на конкретных примерах. Вот один из них: проводка документа как в 1С руками ноукодера — и эти экселеподобные, но более крутые, приемы доступны для обычного аналитики, не требуют познавания парадигмы 1С. https://rutube.ru/video/31caa1f7183a4b0ed028c3f6102b3ccf/
Он и сейчас почти такой есть, и им пользуются аналитики для разовых задач анализа. IDEAV же и построенные на нем платформы стремятся кратно ускорить написание конструкций этого языка и разработку.
Суть изобретения в преодолении предела работоспособности EAV по размеру данных и унификации хранения структур данных для того, чтобы использовать это всё в визуальном конструкторе баз данных и приложений.
Задача заметки — рассказать про возможность, которую дает подход IDEAV, на самом очевидном и популярном примере: удобство исследования баз данных аналитиком или пользователем.
О, я даже не знал про такого, спасибо! Подобные идеи много кто озвучивал и пытался воплотить, а масштабируемое решение появилось только с IDEAV. Кстати, можно покликать самому (https://integram.io) или посмотреть, как это выгладит со стороны.
На ванильных тестах, под конкретный пример, без учета переплаты за неиспользуемую мощность тарелочки и без возможности масштабирования вне её пределов – да, вполне возможно показать кратный прирост скорости. Но архитектурно здесь же никакого прорыва нет, просто жестко скомпонованная многоядерная система, не?
Что-то здесь не сходится. Как уже упоминали здесь, данных на много порядков больше, чем процессоров, поэтому их надо как-то к процессору доставить из всего массива памяти - затолкать в немногочисленные регистры, чтобы обработать. И здесь никуда бутылочное горлышко на доставку не денется, а с учетом размера тарелочки, ещё и дольше должно оказаться.
Да, нужно открыть Студию и там исправить это или повелеть агенту, он сам всё сделает. Это займет меньше 5 минут вместе с ввкладыванием на сайт, и руками будет чуть быстрее, чем агентом.
Так-то она работает публично лет 5. А первая инсталляция была в 2006 и до сих пор там пользуются. Спускаться на уровень ниже не приходилось с 2008 года, с версии 1.0.
Спасибо! Но скорее FORTH.
Видел, поверьте. Это обычная реляционная БД, там все стандартные приемы работают: шардрование и прочее. Опыт есть в известном всем зеленом энтерпрайзе, всё будет работать. Да вот хотя бы в соседней статье посмотрите тесты:
https://habr.com/ru/articles/900308/
А тут её можно покликать живьём (это старая версия сервиса, ей лет 5 уже):
https://ideav.pro/misa
Вот здесь описана система, откуда этот запрос:
https://habr.com/ru/articles/545684/
Запрос будет примерно такого плана:
У обоих не удастся - только один получит успешный ответ, если применять транзакции.
Да, все так, и не только 1С :-)
Вовсе нет. Пример: у нас у клиента биллинговая система по стримам на музыкальных площадках, и там больше 20 млн записей статистики о стримах, взаиморсчетах и прочем.
Ведется биллинг и считаются агрегаты: по ним или общая отчетность считается, которая в пределах 10000 записей обрабатывает (тысячи треков, альбомов, артистов), или статистика по конкретному артисту, что может составлять 10-50 тысяч записей, поэтому запрашивается страницами по 5000 записей и не дает фронту тормозить.
Прямо сейчас всё просто - в случае с яблоками делается бронь, а в случае успеха - покупка. Кто первый оставил бронь, тот и купит. Бронь делается с фронта.
Это будет реализовано как в обычной базе: ограничения, триггеры и прочее.
JOIN'ы доступны любые, равно как вложенные запросы и рекурсия.
Хорошо бы сравнить жизнеспособность на конкретных примерах. Вот один из них: проводка документа как в 1С руками ноукодера — и эти экселеподобные, но более крутые, приемы доступны для обычного аналитики, не требуют познавания парадигмы 1С.
https://rutube.ru/video/31caa1f7183a4b0ed028c3f6102b3ccf/
Он и сейчас почти такой есть, и им пользуются аналитики для разовых задач анализа. IDEAV же и построенные на нем платформы стремятся кратно ускорить написание конструкций этого языка и разработку.
Суть изобретения в преодолении предела работоспособности EAV по размеру данных и унификации хранения структур данных для того, чтобы использовать это всё в визуальном конструкторе баз данных и приложений.
Задача заметки — рассказать про возможность, которую дает подход IDEAV, на самом очевидном и популярном примере: удобство исследования баз данных аналитиком или пользователем.
Вот здесь есть с таймингом и планами запросов:
https://habr.com/ru/articles/414255/
О, я даже не знал про такого, спасибо!
Подобные идеи много кто озвучивал и пытался воплотить, а масштабируемое решение появилось только с IDEAV.
Кстати, можно покликать самому (https://integram.io) или посмотреть, как это выгладит со стороны.
На ванильных тестах, под конкретный пример, без учета переплаты за неиспользуемую мощность тарелочки и без возможности масштабирования вне её пределов – да, вполне возможно показать кратный прирост скорости.
Но архитектурно здесь же никакого прорыва нет, просто жестко скомпонованная многоядерная система, не?
Что-то здесь не сходится. Как уже упоминали здесь, данных на много порядков больше, чем процессоров, поэтому их надо как-то к процессору доставить из всего массива памяти - затолкать в немногочисленные регистры, чтобы обработать. И здесь никуда бутылочное горлышко на доставку не денется, а с учетом размера тарелочки, ещё и дольше должно оказаться.
Да, нужно открыть Студию и там исправить это или повелеть агенту, он сам всё сделает. Это займет меньше 5 минут вместе с ввкладыванием на сайт, и руками будет чуть быстрее, чем агентом.
Use case примерно такой, и это годится не только для программиста, но и для пытливого пользователя с архитектурным видением
https://rutube.ru/video/c85b3e7e11dc9f96f0f091d308968126/