Comments 45
Вот интересно, мы уже несколько лет решаем задачу перевода данных из бинарного потока сохраненного в файле в базу данных для визуализации-навигации, анализа, редактирования,
и, соответственно, обратную задачу: построения бинарного потока по данным заданным в базе данных. То есть заполняет и/или редактирует базу данных человек, а использует данные алгоритм формирования-генератор бинарного потока данных.
Проблема в том что данные в такой базе данных получаются 3-х мерные: таблицы, которые по определению двухмерные меняются со временем, то есть надо хранить-формировать несколько таблиц одного типа сущностей по периодам времени на протяжении полного периода потока данных. Кажется SQL не очень подходит для таких 3-х мерных данных, или мы чего то не знаем?
Проблема в том что данные в такой базе данных получаются 3-х мерные
А что вы подразумеваете под этим? Что периодически меняется набор столбцов таблиц?
Кажется SQL не очень подходит для таких 3-х мерных данных, или мы чего то не знаем?
В таком случае - зависит от того, как вы работаете с этими данными. Если вам нужны какие-то связи по этим стоблцам, целостность данных и так далее, а меняются они нечасто, то можно продолжить использовать SQL, иметь какую-то одну родительскую таблицу и дочерние под каждую новую сущность.
Если у вас сложной логики нет, а надо работать на уровне сущности, ну, вида "извлёк сущности за какой-то период, что-то с ними сделал, положил обратно", ваш пациент - noSQL.
В таком случае - зависит от того, как вы работаете с этими данными. Если вам нужны какие-то связи по этим стоблцам, целостность данных и так далее, а меняются они нечасто
Нельзя сказать что это человек работает с данными, состав данных определяется спецификацией на поток данных , набором спецификаций на подпотоки которые содержатся в общем-сумарном потоке данных. Целостность данных в потоке обеспечивается контрольными суммами пакетов в которых данные передаются.
В базе данных, вроде как данные некому сломать, туда не должны попадать противоречивые данные, вроде как, вот на этапе преобразования из потока в базу эту непротиворечивость неплохо бы проконтролировать, конечно. Опять же это не входит в функциональность SQL кажется?
Вроде как все сущности статично определены спецификациями, правда они могут отсутствовать на некоторых периодах в потоке, как это отобразить в базу данных в таком случае? Варианты конечно есть, но что выбрать однозначно непонятно.
В основном связи между данными по разным периодам, но для одной и той же таблицы нет связей по значениям, какое то время одни значения в таблице, в следующий период меняются значения в таблице, сама таблица не меняется, и в общем то нет зависимости между старыми и новыми данными.
Не важно как часто они меняются - главное что они в принципе меняются и с этими изменениями их надо сохранять и потом визуализировать, и иметь возможность редактировать.
Вот начинаешь писать и осознаешь как тут все непросто, сколько разной функциональности надо поддерживать.
Серебряной пули нет, но есть варианты
https://habr.com/ru/articles/101544/ + комменты
Apache Iceberg решает похожую задачу в аналитике больших данных.
да нет, нельзя сказать что у нас какие-то особо большие данные, таблицы максимум полей на 50 и таблиц штук 20 где-то надо сформировать из сохраненного трафика, проблема в том что нужно видеть несколько версий для некоторых из этих 20 таблиц в зависимости от позиции в трафике, и соответственно при редактировании надо иметь возвожность добавлять такие измененные таблицы для разных позиций в трафике,
то есть надо иметь возможность задавать диапазон длительности трафика на которых определены каждая из этих 20 таблиц, причем желательно независимо для каждой таблицы, как-то так.
Зато нам не нужно контролировать права пользователей, и не нужно параллельной работы пользователей. Пользователь либо человек, либо парсер потока который преобразует поток в данные базы данных, или генератор потока который преобразует данные из базы в поток. Никогда не нужно чтобы они одновременно работали. Хотя можно наверно и до этого дойти, но пока бы решить простую задачу.
Так меньший объем данных не мешает использовать те же технологии, если они решают задачу. Просто посмотрите насколько применимо к вашим схемам БД Apache Iceberg и projectnessie
Такие таблицы называются медленно меняющимся измерением. Современные SQL платформы работают с таким.
SQL про них ничего не знает, это паттерн проектирования
Знает кое-что: https://www.ispras.ru/preprints/docs/prep_30_2017.pdf https://www.youtube.com/watch?v=0nBqpZLc4xc
Но все обходятся "велосипедами", то есть, паттерном проектирования, а именно, полями start_date и end_date в таблицах с "историчностью", причем start_date входит в ключ, а для актуальных данных end_date = NULL, либо end_date = '9999-12-31'
прежде чем рассматривать как применять язык запросов, хотелось бы определиться со структурой-способом хранения данных.
У меня вот такая проблема, например:
Есть таблица сущностей на 300 или 500 или 1000 строк - 15 полей,
Сущности в ней могут меняться каждые 350 МИЛЛИсекунд (каждую треть секунды), проблема в том что в течении например 20 секунд она не меняется и для анализа на интерфейс человеку надо выводить ЦЕЛУЮ таблицу подписанную диапазоном времени для которого она действует (хотелось бы),
Если мы анализируем трафик скажем за 10 минут (час, ...) нам неплохо бы видеть просто список точек в которых произошли изменения, можно с некоторой статистикой которая убирается в строчки, которые подписывают эти моменты изменений,
Возникает вопрос как хранить такие изменения:
переписывать целую таблицу если поменялись только пара полей из 300х15?
или
хранить только сами изменения например в виде "имя поля:новое значение:время", но тогда возникает проблема когда у нас меняется например половина таблицы.
Мы в своем проекте сделали первое пока.
А вот буржуи в таких случаях пишут что надо искать компромис, вот где он этот компромис? Где его искать?
На экран у вас влезет лишь несколько десятков строк - их и синхронизируйте в реальном времени. А остальные лишь по мере прокрутки
В этом кейсе явно нужна субд с поддержкой инмемори таблиц
500 или 1000 строк это очень маленький объем, с таким можно все целиком переписывать.
для больших объемов возможен вариант - копить лог, а раз в N единиц времени обновлять всю таблицу и очищать лог.
Есть datomic, в ней можно смотреть данные в разрезе времени и отдельных транзакций. Можно перейти на события и строить агрегаты за любые периоды.
и мне кажется теперь что даже GIT как база данных в какой то степени подходит под мою задачу если таблицу хранить в текстовом виде!
Вряд ли нам все это подойдет, потому что нам нужна не просто локальная база данных, нам нужна временная база данных в памяти.
Нужна какая то библиотека которая позволяет задать, описать структуру таблиц и/или дерева объектов для сохранения и навигации по ним, и чтобы дальше наполнять эту структуру данными, а потом иметь возможность навигации по ним...
Просто в статье, в начале крупным шрифтом написано:
в любом достаточно сложном клиентском приложении программисту непременно придётся реализовывать такое множество фич для управления данными, что эта работа будет напоминать построение предметно‑ориентированной базы данных
и я на это повелся!
но потом все возвращается к общению с сервером:
Отправляем запрос от API на сервер и сохраняем его в локальной переменной
А тут главная проблема будет связана не с функциональностью базы данных, а с функциональностью для работы с сервером по сети (работа с данными на удалении).
Вот если бы вместо библиотеки для работы по сети иметь библиотеку для работы с локальной (а не удаленной!) базой данных.
Получается я что-то напутал, меня начальный посыл статьи ввел в заблуждение.
широта распространения этих расширений говорит сама за себя
А почему в таблице не ввести колонку "период времени"?
завести то можно, только этого не достаточно, потому что вместе с каждым уникальным периодом времени надо хранить еще и уникальное содержимое всей таблицы (как контейнера) которое и должно меняться в зависимости от этого периода и которые все(!) таблицы с изменяющимся содержимым надо помнить и хранить в базе данных или иметь возможность размножать при редактировании.
Как я понимаю тут происходит отправка изменений на сервер, который их к себе применяет. Т.е. фактически с клиента уходят запросы, которые сервер выполняет. А как контролировать права выполнения таких запросов? Ведь пользователь может прислать что то, что сломает сервер.
Собственно, по той же причине crdt не позволяет волшебным образом избавиться от центрального сервера. Чтобы от него избавиться нужны цифровые подписи, что относительно дорогое удовольствие.
я так понимаю нет. SQLite компилируется в WebASM и запускается на стороне браузера. Во всяком случае демка с SQL запросами работает и с отключенным инетом.
Интересно, а чем IndexedDB не подошла для кэширования данных из API на фронте?
Иногда действительно проще встроить базу данных в фронтэнд, чем пытаться самому переизобретать фичи базы данных в браузере. Я так недавно сделал c DuckDB WebAssembly.
Потенциально выигрышной структурой данных здесь представляется массив записей, отсортированных по дате, в сочетании с более сложной логикой запросов и обновления.
Потенциально выигрышной структурой данных здесь представляется B-дерево.
Статья вызывает вьенамский синдром. Кто Apollo (GraphQL) помянет - тому глаз вон.
Не стараюсь в критику - просто ИМХО - но я бы заменил всю статью на "просто не делайте так".
По мере роста сложности приложения главной проблемой на самом деле становится согласованность:
одна и та же сущность скачивается в пяти разных местах; при этом в каждом из этих мест нужен разный набор полей или вложенных объектов
а меняется эта сущность в трёх других местах
а ещё эта сущность может измениться в результате мутации в другой объект, который даже своим названием не намекает на такой сайд-эффект; иногда этот эффект ещё не существует, но появится через месяц в результате разработки совсем другой фичи.
В 80% случаев разработчик это увидит и поставит инвалидацию какой-то части кэша после выполнения мутации. Из оставшихся 20% - примерно половину в конце концов отловит тестирование. А ещё 10% - останется в приложении и будет накапливаться.
Конечно, есть разные стратегии по обеспечению согласованности, но все из них, что я видел, объединяет одно - они не работают, когда над проектом работает больше двух человек, или кто-то из них больше "творец", чем "ремесленник", и ему сложно удерживать в голове 100500 сложных вещей в один момент времени.
Данные можно и нужно кэшировать, и да, не через useState, а хотя-бы какой-нибудь tanstack-query или rtk (конкретно про SPA, не говорю тут про Server Components). Но - исключительно в рамках одной страницы. Перешёл на другую - лучше перезагрузить.
А LiveQuery и нотификации по WebSocket в этой линии времени ещё не изобрели? Вечно путаюсь в этой фронтенд-мультивселенной...
Перешёл на другую - лучше перезагрузить.
+1! Что говорит о том, что хождение между страницами - и есть нормальный, равномерный во времени, природный механизм инвалидации кеша. И сам юзер это подсознательно понимает - когда хочет увидеть самые свежие данные.
В мире clojure (clojurescript для фронта) почти сразу был сделан заход на базу https://github.com/tonsky/datascript
Ничонепонел. SQLite как-то запустили в браузере? переписали на яваскрипте? или на wasm странслировали?
...
может тогда не мелочиться и весь бэк вместе с postgres / mysql странслировать в wasm и засунуть в браузер?...
в принципе есть варианты с запуском через wasm, что конкретно в этом случаи хз, по-моему на хабре даже кто-то писал статью про это, как он сам делал
"Машина Голдберга" для фронтэнда?
Если уж так подходить, то любая программа - это либо траслятор, либо СУБД. Это абсолют и только ситхи судят абсолютами... ахем.
>Прекратите клепать базы данных
>Я устал ждать — поэтому взялся решать эту проблему в лоб. Написал софт, который назвал SQLSync. SQLSync — это оптимизированный под фронтенд стек базы данных,
:D
Чтобы ничего подобного не делать, у меня есть две отмазки:
за такое меня давно бы уволили
не каждому браузеру доступны 16 гигов оперативки
Прекратите клепать базы данных