Неоднократно задумывались, да. Это что-то другое всё равно должно быть реляционным, и лучше реляционной СУБД мы ничего не придумали. Есть мысли, как сделать РСУБД более приспособленной под эту задачу, а именно, редуцировать её движок и добавить в него немногочисленные доработrи для поддержки IDEAV.
Одна из идей — сделать все 3 индекса покрывающими на все 4 поля, что позволит вообще не хранить данные в таблице, а выбирать их исключительно из индексов. Это заметно ускорит работу базы при приемлемых накладных расходах.
Я тоже использую gigachat для небольших задач, типа написать скрипт для нагрузочного тестирования или вроде того. Но тут проблема в том, что копилоты AI не имеют архитектурного видения и не могут создать архитектурный креатив, потому что переиспользуют что есть.
Интересно, автор слышал про Квинтетную модель данных? Это как раз самодостаточная, предельно унифицированная структура, применяемая на практике, в отличие от теории здесь.
FPGA использует конкретные механизмы, конкретные полупроводниковые решения и стандартные коммутации. Мы же применим свои приемы коммутации и оркестрирования, не ограничиваясь существующими решениями в этой области. Наше решение не будет основано на переконифгурировании FPGA хитрым образом, хотя первый прототип вполне себе может быть собран на существующей элементной базе с гигантскими накладными расходами, как это успешно делает наша квинтетная модель данных в обычной реляционной СУБД.
Я пытался объяснить это в статье: это будет единое поле самых простых исполнителей, даже, я бы сказал, поле кирпичиков, из которых эти исполнители строятся. Рабочий фрагмент, который делает полезную работу, -- это комбинация кирпичиков, создающая простых исполнителей. Исполнитель работает так: 1. Получает задачу 2. Конфигурируется по очень простым правилам для её выполнения, задействуя соседние поля при необходимости, 3. Выполняет задачу 4. Передает результат заказчику задачи 5. Если пришла новая задача, а исполнитель занят, он передаёт её далее, причем это происходит прозрачно для исполнителя, он не прерывает работу Пока состав поля и его исполнителей я объяснить не могу, потому что это не готово. Но вы обязательно узнаете о прогрессе, как он будет.
Функционально похоже, но архитектурно и физически будет выполнено по-другому. Конфигурироваться эти фрагменты будут автономно и самостоятельно, они сами будут принимать решение сообразно задаче, а не получать извне готовую конфигурацию.
У нас софт работает хорошо именно потому что это no-code, в котором толковые разработчики когда-то заранее продумали и запрограммировали простые действия, из которых всё собирается.
Вот здесь в моем комментарии приведен пример мониторинга одного из наших серверов. Там зарегистрировано 1500+ баз клиентов, ежемесячно активны около 150 клиентов, у которых под 300 пользователей суммарно, из которых в пиковые часы работают 30-60 одновременно. Вот они прекрасно параллелятся как между базами, то есть, работают полностью независимо, так и внутри одной базы, когда работают с несвязанными напрямую сущностями.
И им не нужно даже показывать прогресс-бар, потому что даже работая с одной таблицей в БД, они не конфликтуют, ожидая запрос 10-30 мс.
Анимация используется для развлечения пользователя, пока он ждет выполнения. Она же не делает работы сама и никак не влияет на скорость выполнения работы, результат которой вы ожидаете. Работа делается где-то на другом компе/сервере.
Иллюстрация про покрывающие индексы
Неоднократно задумывались, да. Это что-то другое всё равно должно быть реляционным, и лучше реляционной СУБД мы ничего не придумали. Есть мысли, как сделать РСУБД более приспособленной под эту задачу, а именно, редуцировать её движок и добавить в него немногочисленные доработrи для поддержки IDEAV.
Одна из идей — сделать все 3 индекса покрывающими на все 4 поля, что позволит вообще не хранить данные в таблице, а выбирать их исключительно из индексов. Это заметно ускорит работу базы при приемлемых накладных расходах.
Я тоже использую gigachat для небольших задач, типа написать скрипт для нагрузочного тестирования или вроде того. Но тут проблема в том, что копилоты AI не имеют архитектурного видения и не могут создать архитектурный креатив, потому что переиспользуют что есть.
Глаз-алмаз. Так назвали базу для презентации для коллег из Сбера по их тематике - карточные операции.
Да, бывает, сочувствую. Хотя это не порок лоукода, это в другой плоскости проблема.
Вот так могут выглядеть строчки из примера в статье в базе данных.
Покликать можно здесь:
https://integram.io/
https://habr.com/ru/articles/465161/
Интересно, автор слышал про Квинтетную модель данных? Это как раз самодостаточная, предельно унифицированная структура, применяемая на практике, в отличие от теории здесь.
Подход следует поменять радикально, иначе -- да, стандартным путем идти шансов нет.
FPGA использует конкретные механизмы, конкретные полупроводниковые решения и стандартные коммутации. Мы же применим свои приемы коммутации и оркестрирования, не ограничиваясь существующими решениями в этой области.
Наше решение не будет основано на переконифгурировании FPGA хитрым образом, хотя первый прототип вполне себе может быть собран на существующей элементной базе с гигантскими накладными расходами, как это успешно делает наша квинтетная модель данных в обычной реляционной СУБД.
Я пытался объяснить это в статье: это будет единое поле самых простых исполнителей, даже, я бы сказал, поле кирпичиков, из которых эти исполнители строятся.
Рабочий фрагмент, который делает полезную работу, -- это комбинация кирпичиков, создающая простых исполнителей. Исполнитель работает так:
1. Получает задачу
2. Конфигурируется по очень простым правилам для её выполнения, задействуя соседние поля при необходимости,
3. Выполняет задачу
4. Передает результат заказчику задачи
5. Если пришла новая задача, а исполнитель занят, он передаёт её далее, причем это происходит прозрачно для исполнителя, он не прерывает работу
Пока состав поля и его исполнителей я объяснить не могу, потому что это не готово. Но вы обязательно узнаете о прогрессе, как он будет.
Так это почти то же, что в прошлой вашей ссылке.
Нет, концептуально всё иначе.
Функционально похоже, но архитектурно и физически будет выполнено по-другому. Конфигурироваться эти фрагменты будут автономно и самостоятельно, они сами будут принимать решение сообразно задаче, а не получать извне готовую конфигурацию.
Да, динамически конфигурируемые
В исходном комментарии я жалуюсь, что на элементарное действие нужно столько накладных расходов, что даже нужен прогресс-бар, чтобы юзер не заскучал
Прогресс-бар на фронте, с бэком и его распределенными вычислениями не связан. Или я не так понял?
Если тема про клиентскую станцию и рендеринг аяксовской крутилки, то это другая тема.
У нас софт работает хорошо именно потому что это no-code, в котором толковые разработчики когда-то заранее продумали и запрограммировали простые действия, из которых всё собирается.
Вот здесь в моем комментарии приведен пример мониторинга одного из наших серверов. Там зарегистрировано 1500+ баз клиентов, ежемесячно активны около 150 клиентов, у которых под 300 пользователей суммарно, из которых в пиковые часы работают 30-60 одновременно. Вот они прекрасно параллелятся как между базами, то есть, работают полностью независимо, так и внутри одной базы, когда работают с несвязанными напрямую сущностями.
И им не нужно даже показывать прогресс-бар, потому что даже работая с одной таблицей в БД, они не конфликтуют, ожидая запрос 10-30 мс.
Анимация используется для развлечения пользователя, пока он ждет выполнения. Она же не делает работы сама и никак не влияет на скорость выполнения работы, результат которой вы ожидаете. Работа делается где-то на другом компе/сервере.