2. Нет, ссылку на него увидеть нельзя

А почему? Это тайный проект, чтобы вступить в который нужно пройти посвящение?

а данные о реальной работе есть? Вон по тестам Kingston SSD имели больше циферок, чем Plextor, а в итоге вышло все наоборот. Я, конечно, не отрицаю, что на локалхосте может что-то очень круто и быстро работать, может быть и в продакшене тоже.

А почему?

Потому что не все хотят афишировать, чем и где они занимаются.

Потому что не все хотят афишировать, чем и где они занимаются.

Ну напиши мне в джаббер, я обещаю, что никому не скажу.
Здесь буду говорить только о технической стороне вопроса.
А то выглядит это все как-то неубедительно.

и мне в личку напиши :)

Да пока молчит, стесняется наверное =).

не верю

http://www.securityfocus.com/archive/1/520105

дырке всего пара месяцев. При этом он еще и freeware. Да и потоки его в случае проблем порушат все. В общем весьма странная поделка.

Как и.о. КО

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

** оптимизированная именно под раздачу файлов.

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

** FS это БД в ядре, с соответствующими оптимизациями в ядре же, вроде sendfile.

* Про то что «это будет не забекапить» rsync аргумент вообще мимо. Так как хитров**ые данные в FS :

** держат на отдельных разделах со своими настройками, и в случае web вообще ЕМНИП не бекапят а реплицируют.

** бекапят прямо из устройства /dev/sdaXX | /dev/xxx_vg/yyy_lv всем разделом сразу.

** и бекапят при помощи специальных утилит вроде олдового dump/rdump с раздела примонтированного в ro - утилит которые разгребают FS на низком уровне. Например просто лезут в FS на тему занятый/свободный блок, это очень быстро, а потом делают бекап занятых блоков -> со скоростью чтения. И diff считают поблочно.

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

Собственно резюмируя - если у вас даже директории вашей файлоструктуры в кеш не влезают, и вы реально приближаетесь к мульенам мульенов файлов и прочим терабайтам то, во первых, без тонких настроек в любом случае не обойтись, ну и web real-world cases в данном случае это именно хранение в файлах. И пока на тему того что «это выгодней делать в базе» было только заявление что есть хитрые приборы^Wбазы о которых мы вам не расскажем ... и они гораздо круче fs на этих кейсах.

Проблема в том что нету даже ссылок на продукты где эти упомянутые чудо-базы применяются. А уж тем более нет ссылок на саму чудо-базу, что бы ее поставить и насладится заруливанием FS.

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

Если проект Веб, то в БД конечно.

В какой БД?

Смотря что он там хочет делать. Я использую для не требовательных прожектов обычный DBM или txt )) Если что-то надо в базе делать то мне нравится DBD::SQLite. Если серьезнее, то MySQL курить или MySQL Cluster, если HA решение нужно.

или txt

Ты хранишь картинки в txt? Круто.

Если серьезнее, то MySQL курить или MySQL Cluster, если HA решение нужно.

Можно пример HA проекта, который использует MySQL для хранения/отдачи картинок?

Ой блин, слово «картинки» пропустил :D

у меня кластер не для картинок конечно сделан, все, думать больше не могу, скажу так, картинки не нужны. Стучим отбой...

когда лучше использовать БД, а когда лучше фс?

Зачем тупо файлам лишний слой абстракции?

а фс с более быстрым поиском чем логарифм бывают?

у него может быть выделенная БД на выделенном сервере только под картинки

И это в то время, когда я решаю хранить тексты, не помещающиеся в varchar (тексты статьи, например)

В постгресе строка может быть около 1Gb. Что же это тексты статей такие ацкие?

Если тебе серьезно нужны статьи больше 1Gb, сделай структуру: одной сущности поста соответствует несколько нумерованных одногигабайтных строк.

Максимальный размер таблицы постгреса ~ 32Tb, а максимальный объем базы данных - неограничен. Так что если у тебя есть статья размером >32Tb, можешь побить ее на несколько серверов -)

//Ничо ты плодовитый автор! Ваще котирую!

А какой nosql, что прошел по вашим высоким требованиям? Что думаешь о couchdb?

stevejobs

а фс с более быстрым поиском чем логарифм бывают?

наверное нет, потому-что кроме поиска нужна вставка и удаление. Т.е. нужно не одну операцию оптимизировать.

kernel

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

4.2
это специализированная БД.

1. если использовать ФС как БД, то придётся мирится с тем, что там всего один независимый индекс. By design.
2. ФС не поддерживает диапазоны, а тем более сортированные диапазоны. Т.е. если строку 13786 найти можно очень быстро, то для строк 13786..13886 это невозможно в принципе (разве что ВСЕ строчки фильтровать)
3. ФС не умеет DROP TABLE, потому строчки надо удалять по одной.
4. Размер блока данных в EXT равен 4К, потому хранить в такой БД строчки в ~50символов не экономично.

Если ВСЕ эти свойства нас устраивают, то ФС как БД нам подходит. Как в данном случае.

насчет поиска. У нас же получается он двухуровневый: сущность для управления объектом-картинкой (сайт, CMS, итп) и файл-картинка. Можно ли в сущности-картинке, условно говоря, хранить прямо ссылку на смещение относительно начала диска (предполагая что у нас есть raw-доступ, а если нету - то хотя бы на inode)? Получается, скорость доступа у нас - константа.

насчет удаления. от него можно отказаться вообще. то есть, в начале каждого «файла» ставить маркер «удалено» фиксированного размера. Тогда можно будет совместить удаление с фоновой/бэкаповой дефрагментацией или отказаться от реального удаления вообще. Получается, скорость удаления - тоже константа.

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

где ошибка? :)

stevejobs

насчет поиска. У нас же получается он двухуровневый: сущность для управления объектом-картинкой (сайт, CMS, итп) и файл-картинка. Можно ли в сущности-картинке, условно говоря, хранить прямо ссылку на смещение относительно начала диска (предполагая что у нас есть raw-доступ, а если нету - то хотя бы на inode)? Получается, скорость доступа у нас - константа.

можно. Можно даже выделить один большой файл, и писать туда все картинки, запоминая позицию. Скорость доступа к этому файлу будет практически константной (если он закопан в каталоги, где файлов очень мало, <100, а так обычно и бывает). Проблема в том, что сущности (сайт, CMS, итп) придётся как-то разрешать ситуацию имя->позиция в файле(на диске), а это тоже где-то O(log(N)), если вам нужно удаление/вставка не за O(N) (а вам - надо, а то уж сильно тормозить будет), потому смысла в этом особо нет - асимптота такая-же, а вот константа пропорциональности у драйвера ядра для EXT очевидно меньше, чем эта константа для какого-нибудь ассоциативного массива на каком-нибудь php.

stevejobs

насчет удаления. от него можно отказаться вообще. то есть, в начале каждого «файла» ставить маркер «удалено» фиксированного размера. Тогда можно будет совместить удаление с фоновой/бэкаповой дефрагментацией или отказаться от реального удаления вообще. Получается, скорость удаления - тоже константа.

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

stevejobs

где ошибка? :)

очевидно ошибка в том, что вы вынесли индекс в (сайт, CMS, итд), и решили, что там он будет обрабатываться мгновенно. Но это не так. Мало того, примерно представляю, сколько человеколет надо затратить на создание индекса, который не хуже драйвера EXT (под Over9000 архитектур естественно), только я не представляю, зачем это надо, если такой индекс у нас уже есть (и не один - ФС можно заменить, и/или настроить, например сменить размер блока, или алгоритм хеширования, или ещё что-нибудь)

А вообще ФС как БД работает значительно лучше и быстрее любой универсальной БД, но с вышеописанными ограничениями (в итоге, такая БД не подходит по всем пунктам даже для самой простейшей гостевой книги на самом примитивном сайте, если это и недостаток, то сродни недостаткам отвёртки, когда ей гвозди забивают).

В постгресе строка может быть около 1Gb. Что же это тексты статей такие ацкие?

Дело не в размере, а в способе хранения, я в последнее время и от varchar в пользу char отказываюсь, так как скорость выборки/вставки/правки - более критичный ресурс по сравнению с объёмом занимаемого дискового пространства.

А иногда даже бью таблицы на 2: в одной поля фиксированной длины(для выборки, например, количества сообщений пользователей, выборки по дате и пр.), а тексты-портянки - в другой таблице. Поиск по текстам - через поисковые движки, составляющие индексы и словари.

Проблема в том, что сущности (сайт, CMS, итп) придётся как-то разрешать ситуацию имя->позиция в файле(на диске), а это тоже где-то O(log(N))

имя и есть позиция в файле. Никакой таблицы соответствий, никакого поиска по этой таблице. Сказали, что картинка называется «+120» - просто читаем по адресу «+120».

условно говоря (img src=«+120» /) :) Этот тег напрямую транслируется в операцию чтения.

и да, пользователю нельзя писать такие тэги, по очевидным причинам. Это системное представление =)

очевидно ошибка в том, что вы вынесли индекс в (сайт, CMS, итд), и решили, что там он будет обрабатываться мгновенно. Но это не так.

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

Object Image {
    FileRef fileRef = "+120";
    CSS css = "height: 30px;"
    ForceCSS = "width: 100%;'"
    NoCSS = "colspanWidth: 30col;"
    Description = "my cool image"
    ApplyOnlyForDesign = "oxygen"
    ...
    ...
    ...
}

(поля взяты от фонаря)

Для всех остальных полей (кроме ссылки на файл) реляционная БД полностью подходит под предметную область, ты согласен? (сможет ли ext4 организовать нам b-tree по полю ApplyOnlyForDesign? :)

Никуда индекс «объектов-картинок» из БД не денешь. Зато наличием такого индекса можно воспользоваться в корыстных целях - быстрого поиска картинок по смещению.

Mysql кластир - сразу видно многолетний опыт разработки нагруженных проектов :)

мы redis используем. Точнее кластер из редисов: 2 машины и несколько инстанцев на каждом.

Никогда не пытайтесь использовать БД для хранения изображений, это плохо кончится.

Это же относится между прочим к любым базам данных. Любое решение нужно обосновывать, любое, а не «вы мне докажите, что на файлах лучше а иначе я оракл воткну по умолчанию». А то народ напроектирует сорок таблиц для простой раздельной иерархии, а потом начинает бодаться рогами в оптимизации потому, что у него лефт аутер джоин по 5 таблицам тормозит для выборки элементарных данных, и генерить индексы пачаками пока не доведет систему до того, что тормозить будет сохранение на апдейте кучи индексов, и при этом свято уверен же, что так и надо было делать, а тормозит потому, что слишком дешевый оракл взяли.

После скольки лет опыт стает многолетним? Что за усмешка, можно предположить, что Вы даже не подозревали про это и желаете меня уколоть, тем, что, якобы, я говорю абсурдные вещи.

Если ВСЕ эти свойства нас устраивают,

То есть ты пошел через жопу - пытаешься хранить реляционныё данные в нереляционной бд - и жалуешься что все черезжопно?

20k files limit solution

filename.jpg суем в /f/fi/fil/file/filen/filename.jpg и никаких проблем

А какой профит в ответе с вые-онами?

filename.jpg суем в /f/fi/fil/file/filen/filename.jpg и никаких проблем

О, вебмастера с локалхоста подтянулись.

stevejobs

имя и есть позиция в файле. Никакой таблицы соответствий, никакого поиска по этой таблице. Сказали, что картинка называется «+120» - просто читаем по адресу «+120».

а что делать для удаления +120?

stevejobs

CMS обычно управляет объектами, а не файлами.

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

stevejobs

Для всех остальных полей (кроме ссылки на файл) реляционная БД полностью подходит под предметную область, ты согласен? (сможет ли ext4 организовать нам b-tree по полю ApplyOnlyForDesign? :)

как я уже говорил, ФС может организовать поиск только по одному индексу, а именно по имени.

stevejobs

Никуда индекс «объектов-картинок» из БД не денешь. Зато наличием такого индекса можно воспользоваться в корыстных целях - быстрого поиска картинок по смещению.

ты же сам сказал, что поиск пропорционален O(1). Куда быстрее?

r

То есть ты пошел через жопу - пытаешься хранить реляционныё данные в нереляционной бд - и жалуешься что все черезжопно?

а кто тебе сказал, что картинки с именами == реляционные данные? Обоснуй пожалуйста этот любопытный вывод.

PaulAS

filename.jpg суем в /f/fi/fil/file/filen/filename.jpg и никаких проблем

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

тоже интересное мнение. Хотя для меня и не новое. Я и сам такое писал, и у других видел :-(

4.2
это специализированная БД.

На целый пост разница между «специализированной» и «упрощенной» БД которая позволила жестоко заклеймить пост жостким 4.2.

У вас по каждому пункту как ни посмотри, вы сначала описываете некое упрощение :D То есть каждый пункт упрощение , но тем не менее упрощенной БД это назвать нельзя.

Вы собственно, в своем уме?

а кто тебе сказал, что картинки с именами == реляционные данные?

А я говорю не о картинках с именами. Я говорю о твоих пунктах 1..4.

сможет ли ext4 организовать нам b-tree по полю ApplyOnlyForDesign?

Да - строки в б-дерево загнать - это рокет саянс.

kernel

На целый пост разница между «специализированной» и «упрощенной» БД которая позволила жестоко заклеймить пост жостким 4.2.
У вас по каждому пункту как ни посмотри, вы сначала описываете некое упрощение :D То есть каждый пункт упрощение , но тем не менее упрощенной БД это назвать нельзя.

По моему мнению, упрощённая БД работает примерно как и нормальная. Ну может чуть быстрее, жрёт чуть меньше ресурсов и т.д.

Так вот, ФС это НЕ СУБД общего назначения. Её так никогда никто и не проектировал. Потому СУБД она никогда и не заменит в общем случае. Это очень сильно специализированная БД, обладающая вышеперечисленными свойствами. И она как минимум на порядок лучше любой СУБД, если конечно её использовать правильно. Например она как минимум на порядок быстрее. Но только в очень специальных случаях, которые я и ограничил.

kernel

Вы собственно, в своем уме?

ну проверьте скорость при хранении BLOB'ов с картинками в вашей любимой СУБД, и скорость при хранении тех же картинок в ФС. Потом что-то там попробуйте написать, в чьём я уме.

r

А я говорю не о картинках с именами. Я говорю о твоих пунктах 1..4.

а я говорю о том, что как раз для реляционных БД не следует применять ФС. Что тут непонятного?

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

НЕ СУБД общего назначения.

Оракелгрессскуэльдб2 тоже не СУБД общего назначения - для справки. Оракелгрессскуэльдб2 - это RDBMS - _Relational_ Database Management System. Так вот перед тем как пихать что-либо туда в принципе - надо обосновать, что представление требуемых данных в реляционной форме более эффективно чем альтернативные решения. Это такой мелкий факт о котором забывают 99.9% разработчиков работающих с данными.

а я говорю о том, что как раз для реляционных БД не следует применять ФС. Что тут непонятного?

Тут все понятно. Я про то и говорю - ты начал через жопу - а потом говоришь что через жопу не подходит. Начни с обоснования за каким чертом ты собрался данные на файловой системе хранить «в терминах» RDB. Какие ты собсно таблицы собрался дропать на файловой системе и что за строки ты собрался там хранить.

r

Тут все понятно. Я про то и говорю - ты начал через жопу - а потом говоришь что через жопу не подходит. Начни с обоснования за каким чертом ты собрался данные на файловой системе хранить «в терминах» RDB.

ну просто понятные, и универсальные термины. Что не так-то?

r

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

там одна таблица == каталог.
и одни строки в ней == файлы
так понятнее?

r

Так вот перед тем как пихать что-либо туда в принципе - надо обосновать, что представление требуемых данных в реляционной форме более эффективно чем альтернативные решения. Это такой мелкий факт о котором забывают 99.9% разработчиков работающих с данными.

я плохо обосновал? Есть какие-то ограничения периметра, кроме перечисленных? Я НЕ собираюсь туда ВСЁ пихать, ограничения очень жёсткие. И про реляционную форму никто таки не говорил. Извини, что тебя сбил синтаксис.

и универсальные термины. Что не так-то?

А то что они не универсальные, а высокоспециализированные - относятся только к реляционной модели.

так понятнее?

facepalm.sql

Я про то и говорю.

я плохо обосновал?

Если ты имеешь ввиду пункты 1..4 - то они все заточены на RDBMS.