ФС и есть БД.

/thread

как говорил Ганс Рейзер, «если вам приходится использовать базу данных, то у вас плохая файловая система».
и все мы знаем, что с ним случилось…

написал телеграм для госдепа гермашки??

чем больше работаю, тем больше бесит все эти ваши - мы решим ваши проблемы, не беспокойтесь. Нет, вы сами решаете свои проблемы. И для этого FS идеальна по своей сути. У вас есть папки, файлы, ссылки. Всё можно хорошо каталогизировать и поддерживать. Вы скажете нет? Да не смешите, люди и без компьютеров использовали этот подход и это работало прекрасно в больших зданиях. При этом механизм прост, не даёт отказов, работает прекрасно.

А всё это ваше дерьмо, в конечном счёте ведёт к проблемам типа как у ff, когда очень длинная история, он просто перестаёт запускаться и выжирает 100 cpu и 100% диска на этот ваш сраный DB.

текст строго в пдф

конечно! html, markdown и tex, и cxx идут лесом

картинки строго в jpg

в галерее это предложи

а вообще, можно для единообразности и текст строго в jpg

А файлы проектов андроид?

не забудь про www.linux.org.ru/tag/яр

Поддержка SQL будет?

:) у вас диск на 600 мегабайт, что база ff 100% диска ест? Никогда такого не было. И никогда не переставал запускаться фф.

ФС классная штука, но в ней нет индексов. а когда к фс добавить индексы, то получается ой — база данных. Пруф — сравнить скорость работы find и grep -r с select * from mycoollogs where message like '%ololo%';

выжирает 100 cpu и 100% диска на этот ваш сраный DB

Это любители писать в SQLite через ORM. А вообще базы данных нужны для того, чтобы решать проблемы доступности информации по сети, а не для локалхоста.

да пофиг через что писать, такого не бывает :)

См. SciDB

дак у вас есть ещё какие идеи-размышления, о судьбе того, куда должна заворачиваться данная разработка? Я хочу ФСБД, но если делать как в андроиде - получится убого. надо ещё варианты.

Ну конечно не 600, вон недавно такая фигня на соседнем компе случилась, притом что там вообще ssd, даже странно, но фокс порой так умеет. У меня было за всю историю два раза. Помогает удалить нахрен его sqllite базы.

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

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

Естественно. Однако бд часто провоцирует хранить данные плоско. Это конечно вопрос квалификации, но зачастую в бд творится примерно то же, что на десктопе многих вендопользователей - срачь из записей(файлов и ярлыков). Но никто не запрещает устраивать такой же срач и в fs конечно:)

давайте опустим кто как хранит записи. вот сейчас твиттер станет хранить записи юзеров в плоских файлах. думаете там лента будет так же быстро генерироваться? Без индексов что будет в любом биллинге. Когда у тебя много информации без индексов никуда.

Я когда-то генерировал счета клиентов из csv файлов. звонков в месяц было меньше 5 миллионов в общем. Генерация 10 инвойсов инвойсов занимала около 10 минут.

достаточно запустить ls на директории в 100 тысяч файлов и ты уже сразу понимаешь что без индексов жить не получится. А если тебе нужно 10 раз погрепать эти файлы? Структурировать?, ок у тебя 300к пользователей. Как не структурируй данные — их все равно будет много рано или поздно.

У тебя есть директория с сотней книжек по 200-500 страниц. Сколько времени тебе нужно чтобы найти в какой книжке написано про «дядю васю»? Индексы :)

ну наверное, у СУБД есть ещё какие то плюсы, кроме индексов? :)

ессно есть. Но тут хотя б в скорости доступа к данных разобраться :)

скорость она разная. подозреваю, речь идёт не о скорости копирования/переноса на другой носитель. а о какой же?

Что значит опустим? Это обычная манипуляция, мол вот эта ваша херня не подходит, потому что в неё дизель нельзя залить.

Без структурирования, да, не то что на 100 тысяч файлов, даже тысяча файлов уже в директории так себе, с точки зрения программных задержек. Однако с какого хрена эти файлы просто валятся в свалку? Структурировать да. Для этого всё есть. Для этого есть жёсткие ссылки, символьные ссылки. Думаю не надо объяснять, что если сделать папки, одну для структурирования по датам, другую по именам ну и тд и сувать в них жёсткие ссылки на файлы в той самой неструктурированной папкекуче, то всё будет работать быстро? Да, в каком-то смысле это можно будет сравнить с индексами. Но только в общем случае это будет работать намного лучше, потому как будет учитываться структура данных, ну то есть хранение будет неотделимо от структуры. В отличие от убожества в виде таблиц в бд.

Что до генерации из csv файлов, то ну и? Впечатлить захотелось, нет, я не впечатлён, вполне себе обычная задача, которую можно ускорить разными способами в зависимости от того где был затык, начиная от перегонки всех файлов в какую-нибудь tmpfs, заканчивая перегонкой всё тех же файлов в более подходящее представление в памяти и затем работой с ними. Опять же этот пример наборот контрпример, потому что csv суть та же самая база, только без индексов. Плоское дерьмо, порождающее геморой.

Ну если мерять не только индексами, то придётся уже конкретные субд с хотя бы конкретными fs на конкретной оси сравнивать. Потому что и там и там будет мульён разных плюсов. Типо возможности организовать какое-нибудь fifo на fs(да да это средство фс по факту) и насколько оно будет эффективнее подписки на изменения таблиц.

давайте опустим кто как хранит записи. вот сейчас твиттер станет хранить записи юзеров в плоских файлах. думаете там лента будет так же быстро генерироваться? Без индексов что будет в любом биллинге. Когда у тебя много информации без индексов никуда.

А чого бы и нет? Между прочим немного подумав можно и в любой нормальной линуксовой ФС организовать индексы без какой-либо программной доработки этой ФС

ну то есть хранение будет неотделимо от структуры. В отличие от убожества в виде таблиц в бд.

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

Правда конечно будут небольшие траблы, если нужно будет искать по содержимому файлов

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

Смысла в библиотеке тут будет немного, хотя может быть, кто знает. Тут надо использовать её в конкретном проекте или проектах, чтобы другие просто узнали об этом. А библиотеку ну допустим, просто с синтетическим api для непонятно чего?) Как современные бд тогда получится же, там примерно по такому принципу всё и проектировалось. Сели очень умные очкарики с математикой и очень умные бухгалтеры. Начертили всё это. А потом втащили в это то, что там быть вообще не должно(вроде процедурок, управления правами и тд), ведь без этого их стройная теория от практики бесконечно далека.

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

Имхо в ФС не хватает транзакций. Да, какая-то часть умеет, но это не слишком распространенные поделки.

Правда конечно будут небольшие траблы, если нужно будет искать по содержимому файлов

ну как бе..а а линуксовый гнутый принцип - «одна задача - одна функция» ? пусть эта либа что-то одно хорошо делает. а уже другая пусть текст ищет/индексирует.

в ней нет индексов ?!

А что такое «каталог»(ака директория)? ФС поддерживает ровно 1 тип ключа индекса(«имя файла»), только 1 для каждого экземпляра данных (из коробки, дополнительные - задача приложений, man link), небольшой набор типов данных — каталог(индекс), файл(блоб), ссылка на другое имя или (драйвер,устройство) + метаданные. Транзакции не прижились.

сравнить скорость работы find и grep -r с select * from mycoollogs where message like '%ololo%';

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

тут выше Evgueni упоминал SciDB
правда, я не увидел там имплементации ФС.

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

люди и без компьютеров использовали этот подход и это работало прекрасно в больших зданиях

Когда-то и подтирались лопухом, и болезни лечили куриным помётом. И всё это прекрасно работало.

Однако с какого хрена эти файлы просто валятся в свалку? Структурировать да. Для этого всё есть. Для этого есть жёсткие ссылки, символьные ссылки.

Структурировать надо. Но ссылки для этого подходят плохо. Они не отслеживают перемещения и переименования файлов, что, как раз, постоянный процесс при структурировании :)

Я так делаю со своими киношками. Графовая структура с симлинками из каталогов годов, режиссёров, ролей, жанров и т.п. Там, блин, половина ссылок регулярно дохлая. Конечно, данные по фильму можно сохранить в JSON-файле рядом с ним, периодически сканировать систему и вносить в симлинки изменения… Но это троллейбус из буханки и закат солнца вручную :)

Это система для хранения очень больших объёмов данных. То что эти данные имеют какую-то осмысленную структуру просто даёт некий бонус в их обработки, но нижний уровень — это распределённая ФС.

Это опять же, типо раз работать с fs, значит никаких инструментариев не использовать, а работать с db, значит всё использовать? Некорректное сравнение, мягко говоря.

Если отталкиваться вот от вашей конкретной задачи с хранением киношек, то всё достаточно неплохо решается набором perl скриптов и да, хранением различных метаданных в месте хранения самих данных, где это нужно. Мне тут родственники подобную задачу поставили для хранения рецептов и прочих документов для домашних задач, прекрасно всё решается парочкой скриптов.

Опять же, когда вы работаете с дб, вы же пишете хранимые процедуры , так ведь? Они ведь из воздуха не появляются? А сложные запросы, тоже пишете? То есть так или иначе вы программируете. Почему когда речь идёт о фс, мы сразу говорим - использовать только cp, mkdir, mv, ls и ln. А как же хотя бы sed, awk, не говоря уже о скриптах на чём угодно? Они что, не работают с fs?

мне не нужно блобы

Ну так нечего сравнивать инструмент для «поиска по маске» с инструментом для хранения блобов. Свою работу он делает достаточно(с) оптимально, а за чужую никто ничего не обещал.

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

базы данных не нужны

Ты сказал. ТС не вопрошал можно ли всегда использовать ФС вместо БД. Очевидно, в некоторых случаях можно - если ему хватит того, что оно предоставляет. Что, врочем, справедливо в отношении любой системы, в т.ч. базы данных.

причем тут ТС. Я отвечал совсем другому человеку. Читайте внимательно, перед тем как отвечать