Хранение большого числа маленьких файлов

gurt · Непрочитанное сообщение **gurt** » 2018-04-13 6:17:58

Доброй ночи

есть несколько вопросов по поводу хранения данных
одна из задач — сохранить около 4х триллионов байт
если не учитывать потребности файловых систем, то всё +/- помещается на небольшой диск
может быть есть схожий опыт?

Хостинг HostFood.ru · **Хостинг HostFood.ru**

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

snorlov · Непрочитанное сообщение **snorlov** » 2018-04-13 8:46:52

Может все засунуть в sql-ную базу...

skeletor

Тогда лучше в NOSQL

densan · Непрочитанное сообщение **densan** » 2018-04-13 16:35:51

Помню на freebsd 8 с UFS при хранении видеоархива системы видеонаблюдения Zoneminder уперся в предел количества файлов в одном каталоге. Где то на этом форуме я обсуждал эту проблему.

gurt · Непрочитанное сообщение **gurt** » 2018-04-18 19:34:02

densan писал(а): ↑
2018-04-13 16:35:51
Помню на freebsd 8 с UFS при хранении видеоархива системы видеонаблюдения Zoneminder уперся в предел количества файлов в одном каталоге. Где то на этом форуме я обсуждал эту проблему.

это ограничение некоторых файловых систем. Число i-нодов превысило лимит. ZFS не содержит такого лимита в отличии от некоторых других файловых систем.

В таком случае продублирую вопрос — сколько реального места на диске может занять данный объём данных, если необходимо хранить данные двух видов адрес->данные и данные->данные. Порядок размерности списка [данные] указан в шапке.

Может быть лучше отказаться от файловой системы (хотя бы для первого случая) и производить запись на диск "напрямую"?

Alex Keda

вы так и не рассказали зачем это
может есть какой-то менее велосипедный способ

а вообще, следует делать как вам удобней и что вы лучше знаете
если способны написать свою ФС, или класть в raw и отслеживать где что (что уже недалеко от своей ФС) - то пишите

как вариант - сложить в БД

gurt · Непрочитанное сообщение **gurt** » 2018-04-20 0:15:32

Alex Keda писал(а): ↑
2018-04-19 23:29:51
вы так и не рассказали зачем это
может есть какой-то менее велосипедный способ

а вообще, следует делать как вам удобней и что вы лучше знаете
если способны написать свою ФС, или класть в raw и отслеживать где что (что уже недалеко от своей ФС) - то пишите

как вариант - сложить в БД

зачем? сбор, хранение, обработка, представление

не вижу большой разницы между БД и ФС в контексте данного вопроса. По сути вопрос прежний — какой объём будет занимать полностью заполненное хранилище в зависимости от выбора метода хранения, если размер поля —42 бита, размер адреса — 42 бита. Возможно часть адреса можно "запихать" в номер физического диска/машины(интерфейса), но вряд ли такая экономия даст ощутимый результат и будет иметь смысл. Кроме хранилища адрес—поле, необходимо как минимум ещё одно хранилище: поле 42 бита — поле 42 бита. Первое хранилище имеет связь 1:1, второе 1:n, где n может быть от 0 до 2^42

Electronik

gurt писал(а): ↑
2018-04-20 0:15:32
зачем? сбор, хранение, обработка, представление

не вижу большой разницы между БД и ФС в контексте данного вопроса.

затем что каждый файл будет увеличивать inode на +1. а если хранить в БД, то тогда только файл БД будет занимать inode. конечно можно отформатировать ФС с бОльшим кол-вом inode, но в какой то момент вы всё равно столкнётесь с тем что они закончились при таком кол-ве файлов.

gurt · Непрочитанное сообщение **gurt** » 2018-04-20 17:54:59

Electronik писал(а): ↑
2018-04-20 15:12:28
затем что каждый файл будет увеличивать inode на +1. а если хранить в БД, то тогда только файл БД будет занимать inode. конечно можно отформатировать ФС с бОльшим кол-вом inode, но в какой то момент вы всё равно столкнётесь с тем что они закончились при таком кол-ве файлов.

о какой файловой системе идёт речь? уже упоминал про ZFS, там этот лимит достаточно высоко. Плюс лимит i-node увеличивается, если разносить данные по разным дискам, о чём тоже написал выше.

основной вопрос был — подсчёт необходимого места на диске (с учётом служебной информации (i-node)). странно, что нигде в сети ещё нет такого калькулятора

Alex Keda

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

gurt · Непрочитанное сообщение **gurt** » 2018-04-21 14:30:54

Alex Keda писал(а): ↑
2018-04-21 13:20:59
врятли кто-то хранит стока файлов такого малого размера в файловой системе
с этим будут вечные проблемы.

проблемы какого рода сулит данный метод? по сути данные можно представлять не в виде файлов, а в виде секторов на диске, где содержание сектора — вторая часть кортежа, а адрес — первая. Предложение писать всё через базу видится странным, так как у СУБД свои узкие места и прямой доступ к ФС происходит через управляющее приложение, а удобства, которые оно может предоставить (выборки, ключи или тд) в данном случае не требуются, так как запись/чтение будет исключительно по ключу (имени файла, либо по указателю на сектор диска). Плюс СУБД скорее всего будет сложнее "разрезать", если представлять все записи как одну таблицу

gurt · Непрочитанное сообщение **gurt** » 2018-04-21 14:37:16

под адресом сектора я подразумеваю отступ в битах по формуле отступ = длина поля * порядковый номер сектора

snorlov · Непрочитанное сообщение **snorlov** » 2018-04-22 19:51:43

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

gurt · Непрочитанное сообщение **gurt** » 2018-04-23 3:03:50

snorlov писал(а): ↑
2018-04-22 19:51:43
gurt, вы все равно по существу создаете свою файловую систему, крайне не гибкое и не устойчивое получается решение, вам ведь наверняка потребуются бекапы и другие фишки... Да и перенос на другое железо тоже будет представлять определенный геморрой, уйдет к примеру разработчик...

в чём "не гибкость" решения? в чём сложность переноса? ответ по методичке из ольгино что ли? в чём сложность бэкапа директории (если использовать для разметки файловую систему, например zfs?

xM · Непрочитанное сообщение xM » 2018-04-24 18:50:51

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

gurt · Непрочитанное сообщение **gurt** » 2018-04-25 2:18:31

xM писал(а): ↑
2018-04-24 18:50:51
gurt, не морочьте всем голову. Вам выше уже указали правильный путь решения задачи, а именно NOSQL.
Если не верите, можете почитать материалы конференций по HiLoad где такие задачи попадаются регулярно.
Использовать файловую систему в данном случае будет затратно по всем параметрам.

странно читать такое утверждение без ссылки на источник, да и noSQL решения бывают различные

xM · Непрочитанное сообщение xM » 2018-04-26 17:45:00

gurt писал(а): ↑
2018-04-25 2:18:31
странно читать такое утверждение без ссылки на источник,

Странно вообще не читать источники ожидая что кто-решит за вас вашу задачу.

gurt · Непрочитанное сообщение **gurt** » 2018-04-26 18:45:51

xM писал(а): ↑
2018-04-26 17:45:00
Странно вообще не читать источники ожидая что кто-решит за вас вашу задачу.

так о каком источнике идёт речь?

xM · Непрочитанное сообщение xM » 2018-04-27 14:45:51

gurt писал(а): ↑
2018-04-26 18:45:51
так о каком источнике идёт речь?

http://bfy.tw/HrjC

gurt · Непрочитанное сообщение **gurt** » 2018-04-27 15:48:08

xM писал(а): ↑
2018-04-27 14:45:51
http://bfy.tw/HrjC

что за ссылка? есть "более понятные" ресурсы?

FiL · Непрочитанное сообщение **FiL** » 2018-06-01 6:46:36

Если данные жестко структуированы (длина поля всегда постоянна), то вообще не ясно нафига база или тем более прямой доступ к диску и подобные накладные расходы. Просто делается один файл. И читается-пишется по нужному смещению.

snorlov · Непрочитанное сообщение **snorlov** » 2018-06-01 9:29:47

FiL,
Все это так, но наверняка придется помимо чтения добавлять, модифицировать, удалять, оптимизировать элемент (элементы) данных...

gurt · Непрочитанное сообщение **gurt** » 2018-06-01 13:14:22

FiL писал(а): ↑
2018-06-01 6:46:36
Если данные жестко структуированы (длина поля всегда постоянна), то вообще не ясно нафига база или тем более прямой доступ к диску и подобные накладные расходы. Просто делается один файл. И читается-пишется по нужному смещению.

на сколько близко функция чтения со смещением в исполнении к командам "ассемблера"?

FiL · Непрочитанное сообщение **FiL** » 2018-06-01 23:09:15

snorlov писал(а): ↑
2018-06-01 9:29:47
Все это так, но наверняка придется помимо чтения добавлять, модифицировать, удалять, оптимизировать элемент (элементы) данных...

И что? Как это влияет? Я не очень понимаю что есть "оптимизировать", но все остальное вполне себе делается. Удаление, конечно, проблематичнее. Но не проблематичнее, чем напрямую в сектора писать.

FiL · Непрочитанное сообщение **FiL** » 2018-06-01 23:11:48

gurt писал(а): ↑
2018-06-01 13:14:22
на сколько близко функция чтения со смещением в исполнении к командам "ассемблера"?

бля буду, не помню я уже как файлы читаются на ассемблере. Напиши код из 3 строчек на C, оттранслируй и посмотри.

forum.lissyara.su