PHP fwdays conference — Creator of PHPUnit, JetBrains, Yii & more, Kyiv | Online

Объектно-ориентированные СУБД

Вот тут на ДОУ громадное количество спецов в СУБД.

А подскажите за легковесную, быструю, объектно-ориентированную СУБД, типа www.eyedb.org — на эту ее разрабы забили уже 10 лет как.
Что сейчас есть?

Уточню, туда хочется пихать различные фичи с видео и картинок, сами картинки и видео, поэтому и объектно-ориентированную смотрю.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Почитал я тут, посмотрел на эти БД и оказалось проще и быстрее написать на плюсах свою либку (лесапедик), что делает только нужную мне функциональность.

велкам в клуб им Думанского

СУБД изначально не предназначались для хранения LOB. Тем более если речь идет о гигабайтных обьектах.
Какая смысловая нагрузка того что LOB хранится в базе ? Вам нужна транзакционность для записи чтения видео ?!

Если мы говорим о терабайтах то

Вот что навскидку будет cons
— Чтение / запись через интерфейс/api базы по определению медленней чем напрямую с файловой системой
— Масштабировать базу дороже и трудней чем файловую систему с блобами
— Бэкап базы будет неотделим от данных.
— Миграция в другие СУБД — будешь выковыривать блобы
— Перестроение таблиц, ребилды кластерных индексов может быть операцией на сутки ( так было MS SQL >10TB XML )
— Функционал СУБД зависит от LOB сильно. Например HA может не поддерживать LOB, In- Memory так само.

ИМХО Правильных вариант блобы в отдельном сторедже, метаданные — в RDBMS/NoSQL.
Например AWS: S3 + DynamoDB/Aurora

Вам нужна транзакционность для записи чтения видео ?!

Нет.

Нє. Не цікава тема. Давай краще пиши про Вайтішників та Еміграцію.

ОО фичи не очень хорошо обычно интегрируются в реляционных СУБД, и поддержка больших двоичных объектов тоже, мягко говоря, не очень. Но вот если прям хочется пихать в базу картинки и видео, то как вариант, делить объекты самому на чанки фиксированного размера и считывать их в память, одновременно объединяя. Для эффективного доступа желательно чтобы строка помещалась в блок, стандартный размер 8к. Если использовать (к примеру) PostgreSQL, то это может быть bytea, опять же размер значения ограничен 1Г и все, что превышает так называемый TOAST_TUPLE_THRESHOLD (по умолчанию для размера блока/страницы 8к этот граничный размер 2к), будет TOASTed, то есть, разбито на чанки и перемещено в отдельный «сторадж». Естественно, это будет очень сильно влиять на эффективность чтений.
Возможно, есть какие-то похожие расширения, но я сходу ничего не нашел. Можно попытаться перекомпилировать самому постгрес с бОльшим размером блока/страницы и бОльшим TOAST_TUPLE_THRESHOLD и наверно TOAST_TUPLE_TARGET. Не факт, что при этом не полезут неожиданные баги.
Любые ЛОБы в большинстве реляционных баз будут работать хуже, будут обеспечивать менее эффективный доступ и потребуется намного больше усилий для кодирования всех необходимых операций.

Это понятно. Почему и спросил, что сейчас в мире есть и юзается.

В новой версии, оказывается, можно задавать TOAST_TUPLE_TARGET при создании таблицы.
www.postgresql.org/...​ocs/12/storage-toast.html
Если что, ты наверно будешь первопроходцем)
Только мне не очень понятно, как данные «подавать» стриминговому сервису, чтобы это было эффективно. Это должно происходить в рамках одного процесса, логично предположить. Еще лучше, если все данные уже загружены в память, иначе получается лишний слой доступа к данным (storage -> postgres -> cache buffer -> client process -> cashing in memory), то для этого тогда логичнее использовать какую-то in-memory database, может с записью во внешний сторадж, но я тут не знаю что и сказать, не специалист.

Какой сервис? Мне просто класть обсчитанное в одно место и брать его оттуда и не более. Причем, чтобы паковалось, распаковывалось, довешивало коды коррекции и работало быстро.
И похоже самому такое написать, как и в 90-х, быстрее и проще, чем возиться с базами.

Если сравнивать с Firebird, то эта база конечно легче, но сильно плохо использует многопоточность. Так что на любой машинке с несколькими ядрами скорость FB будет в разы выше.

но сильно плохо использует многопоточность
Мне просто класть обсчитанное в одно место и брать его оттуда и не более.

Ну будут у вас в базе пару миллионов объектов, то разница в скорости будет очень уж заметна. Это могут быть, к примеру, логи с прокси сервера за год.

Это могут быть, к примеру, логи с прокси сервера за год.
Уточню, туда хочется пихать различные фичи с видео и картинок, сами картинки и видео,

Ну и? Если картинка или видео меньше 2 Гб то проблем нет. Если больше, то лучше посмотреть что-то более серьезное, например DB2.

Картинки и мета отлично работают на FB Embedded, например в этом проекте. Пользователи на разрушение базы даже на портабле версии на флешках не жаловались.
www.tidyfavorites.com/introduction.html

Если картинка, Если больше

если бы да кабы,

например DB2.

«при разворачивании сети пицерий надо заложить риски падения метеорита!»

размеры данных непонятны, но понятно что нужно что-то простое, чтобы вместо файлопомойки из снипетов получить какое-то каталогизированное хранение.

на FB Embedded, например в этом проекте

вам что, платят что-ли за продвижение FB Embedded?

Мне просто класть обсчитанное в одно место и брать его оттуда и не более

Так тогда вообще пофиг, какая база) Точнее, непонятно зачем вообще база. А так-то да, самому быстрее и проще))

Почитав написанное, пришел к этому же выводу. Добавил нужное мне сжатие и коды коррекции.

Если не нужен квери энжин для репортов и оптимизатор запросов «на лету», я бы сам написал.
Там особо ничего сложного, в этой нише все СУБД будут сильно узкоспециализированы и время на изучение и адаптацию уйдет больше чем самому все сделать.

Intersystems Caché — но легковесной ее назвать никак нельзя (из-за ценовой политики).

Может быть Вам стоит посмотреть на PostgreSQL ?
Там есть встроенный ф-л для хранения больших объектов и работает это довольно быстро
( www.postgresql.org/...​docs/12/largeobjects.html )

Из именно OODBMS лично видел хороший продукт на ObjectStore ( ignitetech.com/objectstore ), ребята знакомые делали, но он немалых денег стоит

Ну что-то таки прийдется катать ручками, потому как обьектные базы не любят большие обьекты.
У тебя же гигабайты, как я понимаю?
Проще всего в key-value запихнуть/порезать или в blob в обычной базе.

Уточню, туда хочется пихать различные фичи с видео и картинок, сами картинки и видео, поэтому и объектно-ориентированную смотрю.

Вам отлично подойдет Firebird с сохранением всего этого в Blob(до 4 Гб) в виде xml. Она реляционная, но её будет легко использовать для этого. Писать по сути придется только сериализацию объектов в xml и код сохранения и загрузки xml из таблиц.

Фишка Фаерберд простота подключения в том числе и как локальную БД Firebird Embedded, версионник как PostgreSql или Oracle, реально способен работать с базами терабайтного размера, хорошо использует многопоточность ну и надежность базы одни из самых высоких среди всех серверов БД. Но это реляционная база, хотя позволяет сохранять большие данные в blob.

Але все ж таки, там просто тип BLOB, і немає можливості зберігати файли десь окремо, як filestream чи bfile в ms sql та oracle.

А вам 2-4 Гб для сохранения одного файла мало? Если да, то там и нужно брать Оракл и нечто серверное с 64 ядрами и дисковым интерфейсом SAS.
firebirdsql.org/...​-datatypes-bnrytypes.html

А чем вам эта табличка не понравилась?
en.wikipedia.org/...​tabase_management_systems

Видел. Из опенсурного там что-то все слишком сложным показалось мне.

такой контент хранят на диске и отдают через CDN

туда хочется пихать различные фичи с видео и картинок, сами картинки и видео

по описанию, отлично подходит NTFS :) ну или родной аналог для Linux

Можно попробовать такую связку MySQL + Archive Engine + JSON data type. Получаем архивное хранилище упакованное и по JSON можно делать поиск. Либо Postgres + Inheritadet tables храним бинарь в родителе, а все строковые данные в таблицах потомках. Это если кровь из носу надо в базе все это хранить, но я бы бинари хранил на чем-то вроде S3 и при необходимости их от туда вытаскивал бы храня линку в базе.

Извини, но еще можно с дискетой в Китай съездить и послать почтой взад.

Я уже понял, что всё возвращается к 90-м и мне проще солнышко таки ручками на С с классами закатить.

Формализуйте требования скажем по объему данных который надо хранить и операциям которые с ними требуется производить иначе это таки гадание. Заявленные требования описанные выше подходы решают.

Да фигня это. Нестабильно работает. Чуть лучше rocksdb, но тоже не супер-стабильно.

Поделитесь опытом, что именно там не работало так как я не припоминаю никаких глюков, а сам движок и контейнер довольно простые.

Mariadb10.3. Тупо падало при нагрузке около 300RPS. Гдето раз в день.
Для сравнения rocksdb только с репликацией падает и гдето раз в три месяца.

В нагрузке не использовал, а только как дамп каких-то данных которые изредка нужны и которые удалить жалко.

зачем именно СУБД?
чем не подходят популярные — Lustre, Ceph, Hadoop, ...?

Привет.
Не знаю на сколько она легковестная и доступная по цене, но что быстрая и объектно-ориентированная, то раньше это было так.
InterSystems Cache’ [www.intersystems.com/...​roducts/cache/#technology]
Для работы с Media контентом, там есть BLOBs: cedocs.intersystems.com/...​=GSQL_blobs_blobsandclobs

Попытка сборки rocksdb (специально снял типа релиз v6.6.4, master тот вообще еще на компиляции посыпался). Ожидаемый результат нынче.
Какая прелесть нынче с поделиями от мордокниг, гуглов и подобных:

Scanning dependencies of target db_stress
[ 97%] Building CXX object tools/CMakeFiles/db_stress.dir/db_stress.cc.o
[ 98%] Linking CXX executable db_stress
CMakeFiles/db_stress.dir/db_stress.cc.o: In function `main':
db_stress.cc:(.text.startup+0x1): undefined reference to `rocksdb::db_stress_tool(int, char**)'
collect2: error: ld returned 1 exit status

Интересно уже, хоть на собираемость сейчас хоть кто-то код проверяет?

Нет слов уже...

rocksdb в mariadb есть, даже собирать вроде не надо. Работает по большому счету.

Ставится из репозиториев, только что проверил. Как минимум на centos 7. могу скрипт дать если надо.
Зачем тебе rocksdb? Оно не сильно быстрее современного innodb, хорошо только если писать на SSD с включенным архивированием.

Там внутренняя организация — дерево. Размер «ячейки» выставляется настройками при старте, причем для разных уровней дерева — отдельно, как и компрессия(можно сделать без компрессии вначале с авто-компрессией по мере продвижения).
А фактическая организация — куча мелких файлов не связаных с именем таблицы.

Но по факту разница по скорости некритична с вариантом «просто в innodb». Вот компрессия хорошая, да(относительно).

Но вообще она специфическая, может, при малом объеме памяти и будет сильно быстрее. Я то тестировал с подключенным intel optane и быстрыми SSD.
Ну и есть ограничения по sql, не особо интуитивные. Там, где обычная база делает выборку по индексу rocksdb может полный поиск закатить.
Если попробывать — ставь как плагин к mysql или mariadb.

Странно, странно, у меня собиралась, и даже базу parity хорошо считывала, и даже через jni.

Во. Это и говорит многое. Сегодня собирается, завтра не собирается, послезавтра собирается, ...
Классический признак говнокода и говноразрабов.
И объясню тебе, это тест

db_stress

не собрался. Но юзать такое случайно работающее обычно себе дороже.

Почитал все комменты. Отпишу тут. Сразу скажу, что 1). не чего не смыслю в обработке видео, и 2) по комментариям слабо понял требования для хранилища, а это(требования к записи и чтению) очень важно при выборе хранилища.

Ниже предлагали Google BigTable — это плохой выбор для хранения файлов, он совсем для этого не предназначен. А ещё цена ОЧЕНЬ высока за его использование, не оправдано высокая.

Если делаете не локальное решение, то идеально было бы использовать cloud blob хранилища (Google Storage, Amazon S3, Azure Blob Storage). В GCS цена, вроде, будет где-то $27 за терабайт данных(но можно и «бесплатно» заиметь, об этом отдельно могу написать как и о преймуществах клауда), в других клаудах ± также.

Использовать «одно хранилище для всего» (и файлов и всех метаданных) — не всегда хорошая идея. Удобно, не спорю, но зачастую базы сделаны хорошо под определённые нужды. Так что, если это не просто MVP или pet-проект, то я бы рекомендовал разделять. Тем более, шардировать будет удобнее, если планируется большой объём данных.

Для хранения метаданных подойдёт не только объектно-ориентированные СУБД, а любая. Но, если не хочется «парится» со схемой, то используй MongoDB.

Ниже рекомендовали GridFS — должно подойти. Но, есть вопрос, как оно себя поведёт, если размеры файлов будут превышать ОЗУ. Советую погуглить «GridFS limitations»

Из общих советов, хотел бы сказать, что если делаете что-то серьёзное, то нужно отталкиваться от требований к записи и чтению данных: Нужно ли потоковое чтение файлов? Каких размеров одна запись? Сколько будет данных всего? Нужно ли шардирование? Формат данных? И так далее... И далее изучать лимиты подходящих баз данных.
Если же делаете что-то локальное, то лучше брать популярное и универсальное решение(как и уже предлагали ниже MongoDB+GridFS), так как будет один интерфейс и гугл будет знать большинство ответов на вопросы.

Я не хочу делать, а хотел заюзать нечто готовое и с большего подходящее мне.
Облака сразу лесом.

Ниже рекомендовали GridFS — должно подойти. Но, есть вопрос, как оно себя поведёт, если размеры файлов будут превышать ОЗУ. Советую погуглить «GridFS limitations»

Значит не подходит.

RocksDB до сих пор (уже море версий у них) не смогли сделать на мордокниге ее устойчивую компиляцию и сборку. Но, вдруг, код там приличный внутри и грамотный?

то используй MongoDB

Это как бы для простейший ключ-значение. А на тяжелых значениях как поведет себя надо проверять.

Поиграюсь еще с RocksDB немного, по описанию, как бы подходит мне. На крайняк починю там чего, если там внутрях более ни менее.

Но уже 70% на т о что нужно для себя написать что-то мне удобное и приличное самому. Мы вернулись в 90-е, когда каждый вынужден был писать свои собственные велосипеды.
Крутые из 90-х стали монстрами, типа Оракла и их продукты мне нафиг не упали.
И все, ничего другого и нет.

Напиши фасад, тобто адаптер, в своєму коді, щоб абстрагуватися від місця збереження. Патерни, йопта.
А, в принципі, в субд, які файли зберігають не просто в блобах, все одно специфічні апі для читання/запису з позиції в файлі, в MS SQL Server FILESTREAMах прямо через віндові ReadFile, тобто все одно те саме, що fopen/fread/fwrite

Нет, слов. рука-в-морде. Я же написал, что не хочу писать кода много, хотел воспользоваться уже написанным и готовым.

Это как бы для простейший ключ-значение. А на тяжелых значениях как поведет себя надо проверять

что именно тяжелое? Объём данных? Запросы? Она НЕ для файлов. Для хранения метаданных, для поиска по ним — более чем хороший инструмент.

нужно для себя написать что-то мне удобное и приличное самому

Я, конечно, не знаю всех требований и условий, но вероятность данного утверждения обычно очень низка. А что не так, с положить файл в FS(он в любом случае будет ханиться в FS) и в DB держать путь к файлу с другими данными?

Я не хочу делать, а хотел заюзать нечто готовое и с большего подходящее мне.
Облака сразу лесом.

Два взаимоисключяющих :) клауды сейчас подгоняют к виду «запуска в 1 клик необходимого функционала». Я их вам не впариваю, уже прочитал, что локальное решение должно будет.

Нормально має повести, файл же, ніби, не документ, а набір документів-chunk’ов, seek- доступ є.

Согласен. Но я бы, если стоит условие что файл больше ОЗУ, сначала бы протестировал, что бы в дальнейшем не упереться в это.

Я канешно не то чтобы спец в DB, да и вопрос абстрактный
Но объектно ориентированы все реляционные базы(SQL) и как уже писали плюшки которых не хватает в собственно базе предоставляют ORM
PS Видео в базе хранить — так себе идея, а для метаданных SQL самое оно

Ну вот пример panoptic сегментация и видео, как их лучше связать и хранить, чтобы доступ в кадрам и сегментации был быстрее 100 fps для FulHD, например.

Я о видеобработке имею только общее представление
Но в целом тут логично задачу поделить на две:
— управление метаданными(все что в пару мегабайт вписывается), включая линки на те места где собственно видео хранится
— хранение видео(оно здоровое скорее всего и в базу пихать не нужно
Подозреваю что иметь такую базу где-то в сети вариант так себе, и интересно именно хранение для обработки на localhost
тогда я бы смотрел на два варианта:
1. условный Postgres в котором все метаданные, связи между ними и пути к локальным файлам в случае больших файлов, сами файлы — просто в файловой системе
2. в случае если таки видео не очень большие то локальный инстанс какой-то key-value или document базы и в ней хранить все, обе которые пришли в голову уже упомянули — rocksDB и mongoDB + gridFS

Все большое, но в локале. А закатывать солнце ручками через файловую систему осточертело (да еще и битики иногда в ней теряются).
Вторая большая проблема файловых систем — это много мелких файлов, это тоже напрягает.

Поэтому и спрашиваю, что сейчас в мире в этом плане есть (и не оракла-подобное).

Как, пример, jpg (FullHD) прочитать и декодировать — это уже максимум 60 fps в идеальной ситуации (труба-жипег либа). А так, если много еще всякого то к 30 fps быстро сваливаешься.
А оно тут 30, там 30 и еще в 10 местах и вот уже на секунду счет пошел.

Что-то мне кажется (но я не уверен) что Mongo + gridfs должен хорошо зайти

Я и не спорю, больше собираю идеи и пользуемые сейчас решения. После выберу то, что мне зайдет.

По поводу идей — я понял, потому и пишу собственно
Вспомнил, хранил я как-то относительно большие файлы в GridFS, были какие-то траблы, но они скорее детскими болячками были(это было как только он появился), и оно сделанно вроде как как-раз для твоего случая(ну или около того)
Единственное что у меня в голове крутится — проблемму медленного дискового IO оно решит так себе, но должно быть заметно быстрее и удобнее чем просто FS

различные фичи с видео и картинок, сами картинки и видео, поэтому и объектно-ориентированную смотрю

Зачем объектно ориентированная бд, когда ты пихать туда ты собираешься данные?

на эту ее разрабы забили уже 10 лет как

 Ну так ОРМы сочинили, и проблема на этом решилась.

Зачем объектно ориентированная бд, когда ты пихать туда ты собираешься данные?

Выше написал.

Ну так ОРМы сочинили, и проблема на этом решилась.

Поясни.

Поясни.

Ныне превратить код/объекты в документы/реляционную модель и документы/реляционную модель в код/объекты можно много где с регулируемым уровнем бойлерплейта. Написать бибилиотеку которая это делает немного проще и дешевле, чем писать особо сложную базу данных выполняя все требования по надёжности, отказоустойчивости и производительности. По сему, товарищи используют бинарные сериализаторы и rocksdb/leveldb если надо терабайты и на одной машине (parity-ethereum например). Среди облачных тоже есть хранилища для этих целей и много чего ещё.

сами картинки и видео

и

различные фичи

имеют немного различную природу. Хранить целую картинку а тем более видос в базе данных которая имеет много фич — дорого. По этому вместо того чтобы сливать всё в одну кучу, можно те самые видео/картинки хранить на key/value файлопомойке (целая бигдата как раз про это — как сохранить сотни видосиков с котятами в full hd дёшево и ещё и иметь возможность с этим как то работать). Можно конечно, использовать grid fs для монги (документы с некоторыми оговорками можно поставить соответсвие объектам), но удовольствие это не дешёвое.

Ясно.
Но вот мне надоело уже закатывать солнце ручками в файловой системе.
Вот и решил спросить, а нет ли чего для оного. Дело в том, что помимо картинок, фичи разные бывают (по сути блобы, тензоры разных размерностей, разреженные и не очень, но часто еще и текст нужен или что-то подобное) и хочется их в одном месте держать и чтобы их легко и быстро доставать и чтобы они там заархивированном виде хранились.
Вот как, например, связать pаnoptic сегментацию с видео и id треков объектов там.

Как бы OO базы для этого разумны, но я не знаю. Поэтому и спрашиваю.

хочется их в одном месте держать и чтобы их легко и быстро доставать и чтобы они там заархивированном виде хранились.

Если это главный критерий, чтобы всё, и в одном месте, и при этом разнородное, то key-value хранилище с большим размером value. Например google bigtable умеет держать 256 мб в одной ячейке, и если фичи к объекту и сам объект влезает в эти лимиты, то можно вполне это дело использовать, одно но — по сети. Если по сети не нужно, есть rocksdb там 8мб ключ и 3 гб на ячейку, там действительно быстро, ещё и написано на С++. Это если выборки по этим объектам нужны простые. Если нужны сложные, нужно брать ещё одну бд и делать там «оглавление».

О спасибо за совет, обязательно посмотрю. Но может еще кто идей каких накидает. Я в БД никакой совеем, поэтому и спрашиваю.

ОО СУБД померли лет 15 тому назад, с появлением ORM (Hibernate, JPA)
Сейчас хороший вариант это NoSql Db — их много разных, под разные цели, смотря что будешь хранить и как использовать.

Если надо простая реляционная — то HSQL db, SQLite и т п — там один архивчик

Тут, мабуть, не субд, а ліби якісь, проекти на гітхабі пошукати можна. Які це вміють.

Что именно?

pаnoptic сегментацию с видео и id треков объектов там

Это я и сам умею.
Мне интересно узнать, как это хранить и быстро доставать из хранилища.

А чем тогда не подходит key-value таблицы, в которой хранить документ с метаданными — условно json-file, а сами файлы складывать в блоб хранилище? Я из клаудов работал только Ажуром, но там есть TableStorage — key-value, BlobTable — для хранения больших файлов, и есть возможность подписываться на все события связанные с изменениями данных в каждой из них. То есть можно построить event-driven систему, которая будет работать со всем этим.

То есть можно построить event-driven систему

Во-во. Закатывать солнышко ручками надоело. Ну и если я в БД никакой, то однозначно сделаю кривее, чем те, кто не одну собаку на этом съели.
Облака сразу лесом — дорогие, геморройные — это для дядь богатых.

Это я больше для себя ищу, а не для дяди. Для дяди любое говно, которое он скажет. Его деньги — его проблемы.

Интересно, поразбираюсь, не знал о таком.
Чисто как файловый формат HDF5, но он уродлив и неудобен в юзании (чтобы им пользоваться, там громадное количество кода писать надо, чтобы его разбирать).

Бігло глянув про HDF5, то здається мені з aaf буде не простіше =(

Подписаться на комментарии