LINUX.ORG.RU

Ответ на: комментарий от special-k

Запихнуть картинку в кликхаус - это надо иметь достаточно подвижное представление о том, для чего нужны колоночные БД.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от dimuska139

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

pfg ★★★★★
()
Ответ на: комментарий от dimuska139

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

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

pfg ★★★★★
()
Ответ на: комментарий от dimuska139

Чтобы не связываться с правами доступа для пользователей еще и на уровне ФС, когда в полный рост используются БДшные пользователи?

Конечно смысл теряется, если пользователи на уровне приложения, а в БД ходят всегда под одним именем.

Toxo2 ★★★
()
Ответ на: комментарий от Anoxemian

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

pfg ★★★★★
()
Ответ на: комментарий от Anoxemian

пример кеша тайловой карты в несколько сотен тысяч тайликов, каждый тайлик ищется по цифрам z x y.
самый простой вариант - тайлики лежат в фс по адресу z/x/y.jpg и в папках собирается десятки тысяч файлов, получения файла из такой большой папки происходит очень медленно, ибо поиск по несортированномй списку имеет сложность O(N).
есть и более сложные варианты, когда в каждой папке лежит не более тысячи файлов. получается быстрее, сложность хз.
вариант2: все тайлики записываются в sqlitedb и на столбцы z x y накладывается индекс. поиск отдельного тайлика происходит очень быстро, ибо поиск идет по двоичному сортированному дереву O(log N)
на практике это очень заметно :)

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от pfg

ибо поиск по несортированномй списку имеет сложность O(N).

this. Это качество очень древних ФС, сейчас в проде нет фс, которые бы не реализовывали какие-нибудь b-tree/hash и прочее. Т.е. поиск уже О(logn). Ну и если без поиска, то и вовсе О(1) должно быть. Если учесть инженерный оверхед самой БД, которая располагается на фс, то логичнее в БД работать с ссылками на объекты фс. Что в 99% случаев и происходит. Не?

Anoxemian ★★★★★
()
Ответ на: комментарий от Tigger

Ну вот у меня есть бд проекта, в которой, к счастью, не хранятся картинки. А картинок в этом проекте на 500+ Гб. Я представляю, какие проблемы были бы с бэкапами, например, если б картинки хранились в БД.

dimuska139 ★★
()