Вот тут на ДОУ громадное количество спецов в СУБД.
А подскажите за легковесную, быструю, объектно-ориентированную СУБД, типа www.eyedb.org — на эту ее разрабы забили уже 10 лет как.
Что сейчас есть?
Уточню, туда хочется пихать различные фичи с видео и картинок, сами картинки и видео, поэтому и объектно-ориентированную смотрю.
СУБД изначально не предназначались для хранения 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, может с записью во внешний сторадж, но я тут не знаю что и сказать, не специалист.
Если сравнивать с Firebird, то эта база конечно легче, но сильно плохо использует многопоточность. Так что на любой машинке с несколькими ядрами скорость FB будет в разы выше.
но сильно плохо использует многопоточность
Мне просто класть обсчитанное в одно место и брать его оттуда и не более.
Ну будут у вас в базе пару миллионов объектов, то разница в скорости будет очень уж заметна. Это могут быть, к примеру, логи с прокси сервера за год.
Это могут быть, к примеру, логи с прокси сервера за год.
Уточню, туда хочется пихать различные фичи с видео и картинок, сами картинки и видео,
Ну и? Если картинка или видео меньше 2 Гб то проблем нет. Если больше, то лучше посмотреть что-то более серьезное, например DB2.
Картинки и мета отлично работают на FB Embedded, например в этом проекте. Пользователи на разрушение базы даже на портабле версии на флешках не жаловались.
www.tidyfavorites.com/introduction.html
Если картинка, Если больше
если бы да кабы,
например DB2.
«при разворачивании сети пицерий надо заложить риски падения метеорита!»
размеры данных непонятны, но понятно что нужно что-то простое, чтобы вместо файлопомойки из снипетов получить какое-то каталогизированное хранение.
на FB Embedded, например в этом проекте
вам что, платят что-ли за продвижение FB Embedded?
Мне просто класть обсчитанное в одно место и брать его оттуда и не более
Так тогда вообще пофиг, какая база) Точнее, непонятно зачем вообще база. А так-то да, самому быстрее и проще))
Если не нужен квери энжин для репортов и оптимизатор запросов «на лету», я бы сам написал.
Там особо ничего сложного, в этой нише все СУБД будут сильно узкоспециализированы и время на изучение и адаптацию уйдет больше чем самому все сделать.
Может быть Вам стоит посмотреть на 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.
А вам
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 и при необходимости их от туда вытаскивал бы храня линку в базе.
Формализуйте требования скажем по объему данных который надо хранить и операциям которые с ними требуется производить иначе это таки гадание. Заявленные требования описанные выше подходы решают.
Да фигня это. Нестабильно работает. Чуть лучше rocksdb, но тоже не супер-стабильно.
Что именно фигня ?
MySQL + Archive Engine
Поделитесь опытом, что именно там не работало так как я не припоминаю никаких глюков, а сам движок и контейнер довольно простые.
Mariadb10.3. Тупо падало при нагрузке около 300RPS. Гдето раз в день.
Для сравнения rocksdb только с репликацией падает и гдето раз в три месяца.
В нагрузке не использовал, а только как дамп каких-то данных которые изредка нужны и которые удалить жалко.
зачем именно СУБД?
чем не подходят популярные — Lustre, Ceph, Hadoop, ...?
Привет.
Не знаю на сколько она легковестная и доступная по цене, но что быстрая и объектно-ориентированная, то раньше это было так.
InterSystems Cache’ [www.intersystems.com/...roducts/cache/#technology]
Для работы с Media контентом, там есть BLOBs: cedocs.intersystems.com/...=GSQL_blobs_blobsandclobs
rocksdb в mariadb есть, даже собирать вроде не надо. Работает по большому счету.
Ставится из репозиториев, только что проверил. Как минимум на centos 7. могу скрипт дать если надо.
Зачем тебе rocksdb? Оно не сильно быстрее современного innodb, хорошо только если писать на SSD с включенным архивированием.
Там внутренняя организация — дерево. Размер «ячейки» выставляется настройками при старте, причем для разных уровней дерева — отдельно, как и компрессия(можно сделать без компрессии вначале с авто-компрессией по мере продвижения).
А фактическая организация — куча мелких файлов не связаных с именем таблицы.
Но по факту разница по скорости некритична с вариантом «просто в innodb». Вот компрессия хорошая, да(относительно).
Но вообще она специфическая, может, при малом объеме памяти и будет сильно быстрее. Я то тестировал с подключенным intel optane и быстрыми SSD.
Ну и есть ограничения по sql, не особо интуитивные. Там, где обычная база делает выборку по индексу rocksdb может полный поиск закатить.
Если попробывать — ставь как плагин к mysql или mariadb.
Странно, странно, у меня собиралась, и даже базу parity хорошо считывала, и даже через jni.
Почитал все комменты. Отпишу тут. Сразу скажу, что 1). не чего не смыслю в обработке видео, и 2) по комментариям слабо понял требования для хранилища, а это(требования к записи и чтению) очень важно при выборе хранилища.
Ниже предлагали Google BigTable — это плохой выбор для хранения файлов, он совсем для этого не предназначен. А ещё цена ОЧЕНЬ высока за его использование, не оправдано высокая.
Если делаете не локальное решение, то идеально было бы использовать cloud blob хранилища (Google Storage, Amazon S3, Azure Blob Storage). В GCS цена, вроде, будет где-то $27 за терабайт данных(но можно и «бесплатно» заиметь, об этом отдельно могу написать как и о преймуществах клауда), в других клаудах ± также.
Использовать «одно хранилище для всего» (и файлов и всех метаданных) — не всегда хорошая идея. Удобно, не спорю, но зачастую базы сделаны хорошо под определённые нужды. Так что, если это не просто MVP или pet-проект, то я бы рекомендовал разделять. Тем более, шардировать будет удобнее, если планируется большой объём данных.
Для хранения метаданных подойдёт не только объектно-ориентированные СУБД, а любая. Но, если не хочется «парится» со схемой, то используй MongoDB.
Ниже рекомендовали GridFS — должно подойти. Но, есть вопрос, как оно себя поведёт, если размеры файлов будут превышать ОЗУ. Советую погуглить «GridFS limitations»
Из общих советов, хотел бы сказать, что если делаете что-то серьёзное, то нужно отталкиваться от требований к записи и чтению данных: Нужно ли потоковое чтение файлов? Каких размеров одна запись? Сколько будет данных всего? Нужно ли шардирование? Формат данных? И так далее... И далее изучать лимиты подходящих баз данных.
Если же делаете что-то локальное, то лучше брать популярное и универсальное решение(как и уже предлагали ниже MongoDB+GridFS), так как будет один интерфейс и гугл будет знать большинство ответов на вопросы.
Это как бы для простейший ключ-значение. А на тяжелых значениях как поведет себя надо проверять
что именно тяжелое? Объём данных? Запросы? Она НЕ для файлов. Для хранения метаданных, для поиска по ним — более чем хороший инструмент.
нужно для себя написать что-то мне удобное и приличное самому
Я, конечно, не знаю всех требований и условий, но вероятность данного утверждения обычно очень низка. А что не так, с положить файл в FS(он в любом случае будет ханиться в FS) и в DB держать путь к файлу с другими данными?
Я не хочу делать, а хотел заюзать нечто готовое и с большего подходящее мне.
Облака сразу лесом.
Два взаимоисключяющих :) клауды сейчас подгоняют к виду «запуска в 1 клик необходимого функционала». Я их вам не впариваю, уже прочитал, что локальное решение должно будет.
Согласен. Но я бы, если стоит условие что файл больше ОЗУ, сначала бы протестировал, что бы в дальнейшем не упереться в это.
Я канешно не то чтобы спец в DB, да и вопрос абстрактный
Но объектно ориентированы все реляционные базы(SQL) и как уже писали плюшки которых не хватает в собственно базе предоставляют ORM
PS Видео в базе хранить — так себе идея, а для метаданных SQL самое оно
Я о видеобработке имею только общее представление
Но в целом тут логично задачу поделить на две:
— управление метаданными(все что в пару мегабайт вписывается), включая линки на те места где собственно видео хранится
— хранение видео(оно здоровое скорее всего и в базу пихать не нужно
Подозреваю что иметь такую базу где-то в сети вариант так себе, и интересно именно хранение для обработки на localhost
тогда я бы смотрел на два варианта:
1. условный Postgres в котором все метаданные, связи между ними и пути к локальным файлам в случае больших файлов, сами файлы — просто в файловой системе
2. в случае если таки видео не очень большие то локальный инстанс какой-то key-value или document базы и в ней хранить все, обе которые пришли в голову уже упомянули — rocksDB и mongoDB + gridFS
Что-то мне кажется (но я не уверен) что Mongo + gridfs должен хорошо зайти
По поводу идей — я понял, потому и пишу собственно
Вспомнил, хранил я как-то относительно большие файлы в GridFS, были какие-то траблы, но они скорее детскими болячками были(это было как только он появился), и оно сделанно вроде как как-раз для твоего случая(ну или около того)
Единственное что у меня в голове крутится — проблемму медленного дискового IO оно решит так себе, но должно быть заметно быстрее и удобнее чем просто FS
различные фичи с видео и картинок, сами картинки и видео, поэтому и объектно-ориентированную смотрю
Зачем объектно ориентированная бд, когда ты пихать туда ты собираешься данные?
на эту ее разрабы забили уже 10 лет как
Ну так ОРМы сочинили, и проблема на этом решилась.
Поясни.
Ныне превратить код/объекты в документы/реляционную модель и документы/реляционную модель в код/объекты можно много где с регулируемым уровнем бойлерплейта. Написать бибилиотеку которая это делает немного проще и дешевле, чем писать особо сложную базу данных выполняя все требования по надёжности, отказоустойчивости и производительности. По сему, товарищи используют бинарные сериализаторы и rocksdb/leveldb если надо терабайты и на одной машине (parity-ethereum например). Среди облачных тоже есть хранилища для этих целей и много чего ещё.
сами картинки и видео
и
различные фичи
имеют немного различную природу. Хранить целую картинку а тем более видос в базе данных которая имеет много фич — дорого. По этому вместо того чтобы сливать всё в одну кучу, можно те самые видео/картинки хранить на key/value файлопомойке (целая бигдата как раз про это — как сохранить сотни видосиков с котятами в full hd дёшево и ещё и иметь возможность с этим как то работать). Можно конечно, использовать grid fs для монги (документы с некоторыми оговорками можно поставить соответсвие объектам), но удовольствие это не дешёвое.
хочется их в одном месте держать и чтобы их легко и быстро доставать и чтобы они там заархивированном виде хранились.
Если это главный критерий, чтобы всё, и в одном месте, и при этом разнородное, то key-value хранилище с большим размером value. Например google bigtable умеет держать 256 мб в одной ячейке, и если фичи к объекту и сам объект влезает в эти лимиты, то можно вполне это дело использовать, одно но — по сети. Если по сети не нужно, есть rocksdb там 8мб ключ и 3 гб на ячейку, там действительно быстро, ещё и написано на С++. Это если выборки по этим объектам нужны простые. Если нужны сложные, нужно брать ещё одну бд и делать там «оглавление».
ОО СУБД померли лет 15 тому назад, с появлением ORM (Hibernate, JPA)
Сейчас хороший вариант это NoSql Db — их много разных, под разные цели, смотря что будешь хранить и как использовать.
Если надо простая реляционная — то HSQL db, SQLite и т п — там один архивчик
А чем тогда не подходит key-value таблицы, в которой хранить документ с метаданными — условно json-file, а сами файлы складывать в блоб хранилище? Я из клаудов работал только Ажуром, но там есть TableStorage — key-value, BlobTable — для хранения больших файлов, и есть возможность подписываться на все события связанные с изменениями данных в каждой из них. То есть можно построить event-driven систему, которая будет работать со всем этим.
Бігло глянув про HDF5, то здається мені з aaf буде не простіше =(
anonymous
Gremlin
Kostiantyn Reu
alobodaebuilder
Oleksandr Katykhin
Oleksandr Katykhin
Sergey Lysak
Alexandr Gavriluk
DNA Exp
Dmitry
Oleksandr Merkulov
Alexandr Gavriluk
Anatoliy Rentgenovich
Denis Reznik
Nikita Podgorbunskyi
Nikita Podgorbunskyi
Oleksandr Merkulov
Oleg Korol
Rostislav Nikitin
Иван Камышан
Igor Kopaniev
Igor Kopaniev
Rustam Kyrychenko
Rustam Kyrychenko
Иван Камышан
Sеrgejs Bоrуsson
Maxim Deyneka
77 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів