Найти - Пользователи
Полная версия: Иерархическая база данных
Начало » Python для экспертов » Иерархическая база данных
1 2 3 4 5 6 7
clopomor
http://apsw.googlecode.com/svn/publish/vfs.html
clopomor
http://fossil.wanderinghorse.net/repos/whefs/index.cgi/wiki/whefs але біндити треба буде самому,+ під віндовсом неперевірено
clopomor
http://www.scalingweb.com/embedded_file_system.php на С++/QT4
Lexander
ZZZ
Ну он вообще-то для этого и создан. Не знаю, как оно работает в SQLite, но вот в моём любимом PostgreSQL оно работает замечательно. Проверено.
Я не про хранение в BLOB, а про получение файла, если в поле он Гб размера, то ты и полчишь все поле целиком - т.е. именно то, чего ты опасаешься.
ZZZ
Нет, Lexander, совсем нет. Я не полезу сейчас в доку, то в двух словах я описал выше. Select'ом ты получаешь id объекта в DB, который открываешь (что-то типа blob_open(id, “rw”)). Потом ты спокойно пишешь туда и оно сразу пишется в базу (про систему кешей забудем). И также читается.
Фактически работает с файлом в DB.
По крайней мере это верно для Постгри. И судя по всему для SQLite из Си.
ZZZ
clopomor… Это интересно. Спасибо.
Начал с itools…
andreytata
Это однозначно “bsddb”. Родной питоновский сишный модуль. Изначально создавался для разработки файловых систем. Могуч и оч-быстр. исходник примерно 80 файлов на плайн С. Нормальный питоновский интерфейс предоставляется модулем “shelve”. Примерно в 800 раз быстрее чем хранить в файловой системе. Но есть ограничения - мультизадачное использование несколько затруднено - нужно быть экспертом. Резервное копирование - не лишняя предосторожность. На поразительное быстродействие этого решения мы обратили внимание почти случайно - нужно было поднимать множество маленьких файликов с участками 3D ландшафта для рендерения в реальном времени для MMO игрушки и хранить на стороне клиента уже посещенные участки на пару десятков километров в каждую сторону от его активных камер. Ну и стирать давно не посещаемые участки на клиенте.

ЗЫ: Но все равно посоветовал бы хранить только индексы, и мелкие файлы, а большие файлы разместить на другом (FTP) серваке, и хранить в базе только инфу о них. Так весь сервис скорость явить сможет не детскую. :)
ZAN
ZZZ
Я только за! :-)
Но как?
http://wiki.osdev.org/Loopback_Device#Formatting_the_partition
Хотя, как я понимаю, вариант с монтированием петлевого устройство не подойдет.
ZZZ
andreytata
Но все равно посоветовал бы хранить только индексы, и мелкие файлы, а большие файлы разместить на другом (FTP) серваке, и хранить в базе только инфу о них.
Эта замечательная идея совершенно не влазиет в концепцию.
Юзеры должны мочь создавать эти пакеты и перекидываться ими без участия сервера.
При попадании пакета на сервер, надо получить его метаинфу и (!) он может быть подписан… Тар всё-таки тормоз…
Покапал я всё это и понял. Нужно писать самому. В общем там ничего сложного. Если кому-то это интересно – пишите, выложу.
andreytata
1. Это естественно не сложно совсем. Только вынужден предупредить, что ЭТО уже очень многораз написано - и Вы начинаете заново писать файловую систему. Во времена моей юности каждый писал собственный файловый система - но в современных условиях это уже перебор. Ещё один мега-NTFS конечно не повредит, но “bsddb” содержит быструю и качественную основу “fs”. Сперва Реализуйте функциональность Вашего сервиса, используя “bsddb” через “shelve” потом в процессе эксплуатации сервиса сформулируйте десять отличий “ТОГО ЧТО ВАМ НАДА” от “bsddb” и напрягите ГУГЛ - сабж 100% имеется в наличии, как одина из монтируемых файловых систем в многочисленных UNIX-ах. Тогда останется только АДАПТИРОВАТЬ найденый “fs” к интерфейсу “shelve” т.е. “anydbm” по имеющимся в поставке Питона образцам, в коде сервиса после этого менять ничего не прийдется. Если всё работает и так, то у Вас останется время на дополнительный перфекционизм уже после начала эксплуатации ВАШЕГО продукта.

2. Обдумайте вопрос гранулярности сервиса. Когда 10000 клиентов обслуживаентся одновременно через сокеты, а один из них зажал весь сервис ибо вливает немерянного размера файл ( в реале он ВСЁЕДИНО вливает немерянное количество маленьких буфферков, и закончит слив всего сабжа за пол-часа - или за 10 лет - зависит только от того, насколько древняя модема на его на чукотская телефонная линия.). Может тогда и самодельный FS станет не нужен.

:)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB