forum.lissyara.su

Доброй ночи

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

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

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

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

densan писал(а): ↑

2018-04-13 16:35:51

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

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

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

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

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

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

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

Alex Keda писал(а): ↑

2018-04-19 23:29:51

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

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

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

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

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

gurt писал(а): ↑

2018-04-20 0:15:32

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

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

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

Electronik писал(а): ↑

2018-04-20 15:12:28

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

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

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

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

Alex Keda писал(а): ↑

2018-04-21 13:20:59

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

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

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

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

snorlov писал(а): ↑

2018-04-22 19:51:43

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

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

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

xM писал(а): ↑

2018-04-24 18:50:51

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

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

gurt писал(а): ↑

2018-04-25 2:18:31

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

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

xM писал(а): ↑

2018-04-26 17:45:00

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

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

gurt писал(а): ↑

2018-04-26 18:45:51

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

http://bfy.tw/HrjC

xM писал(а): ↑

2018-04-27 14:45:51

http://bfy.tw/HrjC

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

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

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

FiL писал(а): ↑

2018-06-01 6:46:36

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

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

snorlov писал(а): ↑

2018-06-01 9:29:47

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

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

gurt писал(а): ↑

2018-06-01 13:14:22

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

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