Comments 29
а можно где-нибудь онлайн NoSQL попробвать?
Может https://mongoplayground.net ? Google в первой ссылке :)
Судя по статье, любая онлайн таблица вида ключ-значение является nosql db. Можно Эксель, например, использовать
В NoSQL-базах данных нет строгой схемы данных.
Считать, что, например, иерархические СУБД не имеют строгой схемы данных -- дилетантство.
Классифицировать СУБД по поддержке языка SQL, По-моему очень опрометчиво. (Знаю работу под названием: "Реализация языка SQL в среде иерархически-сетевой СУБД ИНЕС")
Третий манифест Кристофера Дейта и Хью Дарвена, вообще, намекает, что для реляционной модели SQL -- яд!
Не очень понял, в чём проблема хранения текста, изображений и видео в реляционной БД? В статье это упоминается, но не раскрывается.
Реляционные БД предполагают хранение простых сущностей (записей) на базе отношений между различными таблицами. Из-за небольшого их веса и индексации данных, можно очень быстро извлекать данные из БД, быстро искать нужные записи и строить сложные транзакции (ну и делать подсчеты на стороне БД, опять же очень быстрые).
Хранение в таких таблиц данных большого размера раздует объем самой БД до неприличного объема, как минимум убьет производительность, как максимум прикончит саму БД.
Хмм. Допустим возьмём самый сложный кейс с видео. Сохраним видеопоток в какой ни будь постргрес в виде битовой строки. Индексацию по битовому полю, само собой, делать не будем. Можем добавить индексацию по метаданным.
В целом в постгресе ограничение в 1Гб на поле. Т.е. большие видео хранить не получится. Но, чего то экстраординарного и, уж тем более, того, что убьет БД я тут не вижу. Те же картинки и текст хранить можно вполне спокойно.
Ну и я так и не понял, в чём отличие от не реляционной БД. Большие видео, в любом случае, мы будем хранить в файловой системе.
И еще — спросим, как хранить видео в HBase (она же как-бы NoSQL, или нет?). Получим ответ — берем байтики, и храним в колонке. Со всеми теми же самыми ограничениями и проблемами. То есть, никаких преимуществ у NoSQL в этом плане нет. Они если и есть — то у специализированных решений, вешать на которые лейбл NoSQL нет никаких оснований.
Суть в том, что базы, которые не SQL могут быть очень очень разные, и описывать NOSQL базы каким-то одним примером - некорректно. Вполне может быть база, заточенная под большие файлы, или база, заточенная под множество мелких лейблов, и они будут разными.
А тогда в чем смысл термина NoSQL, если им называть вообще все подряд? Классификация же должна нести какой-то смысл?
Лично я считаю, что ответ в данном случае - эффективные маркетологи.
Не sql базы в общем-то появились очень давно, как нишевые решения, и отлично там жили.
Но с появлением bigdata и развитием технологий, появилось популярное мнение, что объекто-ориентированные базы не только простые и удобные и быстрые, но еще и универсальные.
И начался тренд noSQL, как конкурент "традиционным" SQL базам. Что их можно использовать везде.
Но на тот момент под noSQL в основном подразумевались mongoDB, Cassandra , ElasticSearch и HBase. При этом даже в этом списке можно поспорить для каких случаев какую выгоднее использовать.
PostgreSQL toastит данные более 2х кб.
Файл режется на кусочки и в колонке хранится указатель на первый из них, в отдельной таблице - сами данные, в каждом кусочке ссылка на следующий. Это долго.
В чем проблема?
В том что транзакции висят
А уж тексты-то реляционные СУБД хранят вполне прилично, с правильной индексацией, и поиском по ним. Причем уже много-много лет как.
А почему тот же кейс в носкуле не будет тормозить?
а TSDB относятся к sql или nosql? там вполне себе даже таблицы.
в зависимости от подхода к хранению и обработки данных относятся к sql и nosql
Есть ощущение, что вы на практике поработали с базами, но при этом практика была конкретного юзекейса. А академическое определение не до конца поняли. И ваше понимание различия sql и nosql баз некорректное, заточенное под ваш опыт.
На самом деле термин nosql база просто обозначает что это нереляционная база данных. То есть просто нет связей между структурами при помощи ключей в таблицах.
А про размеры или про неструктурированные данные - это общие слова, которые ничего внятного не объясняют.
Хранить большие объемы видео в nosql базах - или хранить вообще неструктурированные данные - плохая идея.
Структура в любом случае есть, просто она может быть более гибкой, не статичной, и в этом случае nosql база может дать преимущество.
TSDB это табличные базы, где праймари кей это время. Просто нет связей с другими таблицами и база заточена на быстрый инсерт большого количества метрик, а также возможно есть оптимизации и внутренние возможности для аггрегаций и работой с временными промежутками. То есть за исключением реляционных связей, выглядит как обычная скл база - таблицы (measurements), столбики (metrics). SQL она не поддерживает, но это и не то и не другое
SQL-базы данных можно сравнить с большим хранилищем файлов
Я бы наоборот, NoSQL сравнил с файлами, т.к. они как раз могут быть разного "формата". А SQL - это табличные данные.
А файловая система это носкуль или скуль БД?
Файловая система это классический пример иерархической БД. Теоретически, прикрутить к ней SQL ничего не мешает. На практике, польза очень сомнительная, т.к. SQL совершенно не заточен под обход деревьев. И писать сложно, да и реальных примеров, где это может потребоваться, немного. С деревом лучше всего обращаться как с деревом :)
Попытки натянуть SQL на файловую систему были, и немало. Одна только Microsoft все нулевые пиарила свою WinFS как светлое будущее человечества. Денег потратили много, а каких-то реальных use cases, где это могло бы пригодиться, так и не придумали.
это вообще не база данных, в силу своего определения.
базы, используемые MUMPS — к чему относятся?
MUMPS это вещь в себе :) В ней есть большинство идей (кроме, разве что, распределенности, хотя, может, уже и появилась), которые лежат в основе большинства NoSQL, но на реляционную БД она точно не похожа.
MUMPS штука очень крутая, на десятилетия опередившая свое время. И даже SQL в современных реализациях как-то использовать можно. Только кому это нужно в 2023 году? Ну, кроме поддержки тонн кода, написанного в 70-х? Мне кажется, VistA за пределами США никем не используется, а больше ничего заметного на MUMPS, кажется, и не осталось.
С каких пор между SQL и реляционной механикой стоит знак равенства?
SQL -- всего-лишь удобный стандартизированный интерфейс к данным, которые в бэкграунде могут быть чем угодно и в каком угодно относительно структурированном формате.
Сравнение SQL- и NoSQL-баз данных