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

Простые/общие вопросы по UNIX системам. Спросите здесь, если вы новичок

Модераторы: vadim64, terminus

Правила форума
Убедительная просьба юзать теги [cоde] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

Доброй ночи

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

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2460 рублей (8 CPU, 8Gb RAM, 2x500Gb HDD, RAID 3ware 9750):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

snorlov
подполковник
Сообщения: 3645
Зарегистрирован: 2008-09-04 11:51:25
Откуда: Санкт-Петербург

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

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

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

Аватара пользователя
skeletor
майор
Сообщения: 2445
Зарегистрирован: 2007-11-16 18:22:04
Откуда: Kiev
Контактная информация:

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

Непрочитанное сообщение skeletor » 2018-04-13 10:13:44

Тогда лучше в NOSQL
"Винда съела дрова и резет здесь не фурычит."
"Все говорят, что у меня /dev/hands криво и я всё делаю через /dev/ass. А у меня этих фалов вообще нет!"

densan
ст. сержант
Сообщения: 363
Зарегистрирован: 2007-12-06 10:02:02
Откуда: Penza
Контактная информация:

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

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

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

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

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

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

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

Аватара пользователя
Alex Keda
стреляли...
Сообщения: 35071
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

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

Непрочитанное сообщение Alex Keda » 2018-04-19 23:29:51

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

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

как вариант - сложить в БД
Убей их всех! Бог потом рассортирует...

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

Непрочитанное сообщение 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
капитан
Сообщения: 1593
Зарегистрирован: 2008-11-15 17:32:56
Откуда: Минск
Контактная информация:

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

Непрочитанное сообщение Electronik » 2018-04-20 15:12:28

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

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

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

Непрочитанное сообщение 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
стреляли...
Сообщения: 35071
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

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

Непрочитанное сообщение Alex Keda » 2018-04-21 13:20:59

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

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

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

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

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

snorlov
подполковник
Сообщения: 3645
Зарегистрирован: 2008-09-04 11:51:25
Откуда: Санкт-Петербург

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

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

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

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

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

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1269
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

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

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

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

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

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

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1269
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

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

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

gurt писал(а):
2018-04-25 2:18:31
странно читать такое утверждение без ссылки на источник,
Странно вообще не читать источники ожидая что кто-решит за вас вашу задачу.
IT voodoo blog https://kostikov.co

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

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

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1269
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

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

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

gurt писал(а):
2018-04-26 18:45:51
так о каком источнике идёт речь?
http://bfy.tw/HrjC
IT voodoo blog https://kostikov.co

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

xM писал(а):
2018-04-27 14:45:51
http://bfy.tw/HrjC
что за ссылка? есть "более понятные" ресурсы?

FiL
ст. лейтенант
Сообщения: 1364
Зарегистрирован: 2010-02-05 0:21:40

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

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

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

snorlov
подполковник
Сообщения: 3645
Зарегистрирован: 2008-09-04 11:51:25
Откуда: Санкт-Петербург

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

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

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

gurt
рядовой
Сообщения: 40
Зарегистрирован: 2009-02-11 19:34:54

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

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

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

FiL
ст. лейтенант
Сообщения: 1364
Зарегистрирован: 2010-02-05 0:21:40

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

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

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

FiL
ст. лейтенант
Сообщения: 1364
Зарегистрирован: 2010-02-05 0:21:40

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

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

gurt писал(а):
2018-06-01 13:14:22
на сколько близко функция чтения со смещением в исполнении к командам "ассемблера"?
бля буду, не помню я уже как файлы читаются на ассемблере. Напиши код из 3 строчек на C, оттранслируй и посмотри.